Scorning Standards
Published 19 years, 9 months pastSo in the last week, we had relaunches of Feedster and allmusic.com, and both sites were straight out of the Nineties: “this site best viewed on…”, browser blockers, and general lack of standards awareness. Scott Johnson’s response in the case of Feedster is, in effect, “we don’t have the resources to support all browsers”.
Yes, you do. It actually costs less to support all browsers.
What costs more is obsessing over making a design “look the same in all browsers”, which is in any case impossible. Your site can’t possibly look the same on a cell phone as it does on my Cinema Display, and it’s not going to look the same in Mosaic 1.0 as it does in IE/Win. Remember Mosaic? It didn’t support tables. A table-driven layout will completely and totally shatter in Mosaic. I wonder if Feedster has a blocking message for Mosaic.
The point is that if you properly structure your content, then you can make it available to everyone. You can set things up so that in more current browsers, the site will look pretty. In older browsers, it won’t. If the user really wants to get your content but your styles confuse it, then the user can disable styles (all the older browsers, and many newer ones, let you do that via the preferences). If you identify a particularly problematic browser—whether it’s IE5/Mac or Netscape 4 or Opera 3.6 or whatever—then you can use JS to withhold the CSS from the browser. Users of those browsers get the content. You can throw in a message telling them why the site looks plain, if you like, but the important thing is that they get the content.
For a site like Feedster, there’s really no excuse. The main page is a search form that looks a whole lot like Google, except with more stuff on it. After that, you get a list of search results. The results will be just as useful with an unstyled presentation as with all the CSS in the world applied. So to say that it would cost $1,500 to support IE/Mac, or anything else, is misleading at best. It might cost $1,500 to figure out how to hack around a browser’s limitations in order to make the page “look the same”. It would have cost $750 less to not take half an hour to implement a browser blocker and set up the blocker page, and just let all browsers in. It would maybe have taken $275 worth of time to write a detector that withholds the style sheet from “unsupported” browsers, or else adds in a style sheet for the browsers you “support”.
As for allmusic.com, Tim Murtaugh created a more standards-compliant version of the main page in two hours. Of course, it may not have consistent layout in multiple browsers, but another six hours could probably fix that. I wish they would, because I use allmusic.com a lot in preparing for my radio show. (And did I mention that the station has a new design for its site? I had nothing to do with it.) I won’t stop using it, of course, because they have good biographical information. but I wish they’d done better. It would have been little enough effort to do so.
Comments (10)
Pingback ::
gregorybowers.com: talk talk » Now taking freelance work
[…] ased site for your business or group: A Web Design Horror Story, from Blake Scarbrough Eric Meyer on why a standards-based […]
If I were to assist Feedster somehow by modifying their public pages to be more standards-compliant, what would be the major target? Ideally full XHTML compliance is wonderful, but are there any gapingly obvious, necessary fixes that must go in immediately?
(cc: by email requested)
I’d like to point that it’s often not about making the site ‘look identical across browsers’. Yes, most of the CSS bugs only cause a couple of misalignments or couple-pixel shifts. However, many can render your site unusable by not displaying certain elements or by displaying things on top of eachother.
In that case, you’re forced to litter your CSS code with a forest of slashes, asterisks and quotes which confuse the parsers and make sure that rule #4 is not parsed by Mac/IE, that rule #7 is not parsed by Konqueror, rule #8 is only for Netscape 4, etc.
We had a problem in Drupal with Mac/IE where fieldsets with a certain positional style would not be displayed at all, which meant that administrators could not edit certain properties. Removing the styles made the form in question a lot less usable (basically it had to do with inline/floated fieldsets which were positioned next to eachother). We do not wish to litter our CSS so now, Mac/IE is still broken.
Besides, even if you properly structure your content and you’re lucky enough to get all browsers to display everything in a visible position, the end result will probably be unusable (from a usability point of view) on at least one or two browser flavors. If you’re lucky, they’ll be minor and/or outdated browsers. If it’s IE, you’re pretty much forced to go through the extra trouble, but for other browser it’s often not worth it.
While I agree that it would be great to have 100% browser support, it is exceedingly hard. IE/Mac is really pretty bad in the way it screws things up — I see more hacks for mac IE than any other browser.
But, I do agree that it’s a bit silly to use detector pages, but then again, a) it’s telling people to upgrade to better browsers and b) it means that Joe isn’t going to have a hate for the site because it totally screws up.
To fix the screwups is a horrible challenger, either doing what Steven says and have a slash filled mess or having mutliple stylesheets which are a total pain to manage.
I have a real problem with people not supporting FireFox and Safari, but I think we should drop Netscape 4, IE4 and IE for Mac support. They make up less than 1-2% of the total and to be honest I’d rather have any efforts supporting those going into supporting standards compliant browsers
Trackback ::
Milan Negovan
Look-The-Same Obsession
Eric Meyer shared some very interesting thoughts in his recent post, Scorning Standards. With so many versions of different user agents (browsers) out there it’s not necessary to obsess over getting your design to look the same in all of them. You nee…
How much does it cost to pinpoint the rendering inconsistencies in IE5/Mac? If you’re not a CSS veteran, it can take a day or two but once you have a good grasp of the technology involved, you can overcome the differences in a couple of hours and use new Tantek’s IE5/Mac band pass filter to author a well-organized style sheet. As a Web developer, I met fewer problems with CSS compliance in IE5/Mac than with IE5 or IE6 for Windows. It all depends on the kind of styling you try to apply and the structure of your document.
IMHO, writing:
/*\*/
@import “not4ie5mac.css”;
/*/
@import “ie5mac.css”;
/**/
… is a far better practice and cost fewer bucks than writing a script that screens out browsers (and user agents can be spoofed). I’m still using OS 9 at work (even though I’m proficient with Mac OS X underlying operating system) and I have no choice but using IE5/Mac. If a site denies me the access, I won’t come back using another platform and/or browser unless I have a very good reason to do it…
Actually Micahel, there is a pretty decent version of Mozilla (1.2.1) available for OS 9.
Scroll down this page to Mozilla 1.2.1 – Released December 2, 2002.
Seems to work well in my limited testing, and is much less buggy from a display perspective than IE 5.1.
Personally I have to disagree that filters are better than server side detection for serving up custom CSS. I even add extra divs in my HTML to avoid IE box-model issues, because I think it’s important that CSS be concise and straightforward. All these CSS hacks make assumptions about combinations of bugs/features that strike me as pretty fragile when looking into the long term future (who knows what bugs could inadvertently show up in future highly standards-compliant browsers?). The only thing I do is to use @import to avoid NS4 problems by default.
Usually everything is functional across browsers (if not always pretty), but if something is broken horribly I think it is much better practice to write a server-side filter to strip the stylesheet for that browser. I know it’s a hassle if you aren’t a server-side programmer, but if you are in an environment where all pages are parsed by a preprocessor anyway, then it is much more elegant.
Trackback ::
talk talk
It Must LOOK the Same!
Some thoughts on a post by Eric Meyer, and the state of web designers.
Pingback ::
The Clue Stick - The Web Standards Project
[…] nt form
After viewing their browser-restricted redesigns, Eric Meyer swings the clue stick at […]