Web standards won’t get you into heaven

Brian Dillard, Monday, February 4, 2008 @ 12:17 pm

The endless hand-wringing over browser version targeting in IE8 illustrates what's wrong with the web standards community. For every sane, rational discussion about the practicalities of future-proofing the web, we get a couple knee-jerk anti-Microsoft screeds and at least one accusation that A List Apart - the standard-bearer of web standards - has somehow sold out by signing on to Redmond's plan.

First, a little background: Howls of protest echoed across the 'net a few weeks ago when Microsoft announced that Internet Explorer 8 would implement a new type of meta tag to enable both forward and backward compatibility in web pages. Once IE8 is out, users will be able to target rendering of their pages to a specific version of IE so that changes to the rendering engine of IE9 (or IE10 ...) won't subsequently "break" those pages. Basically, from IE8, onward, Explorer will include multiple rendering engines and display individual pages based on the browser version targeted by this new meta tag. The markup will look something like this:

<meta http-equiv="X-UA-Compatible" content="IE=8" />

I have no interest in debating whether or not it's "semantic" and "standards compliant" to include the name and version number of a specific user-agent in my markup. That's already been debated to death (on the 200,000+ pages Google currently reports for the keywords "IE8 meta tag"). What I want to know is this: Will Microsoft's move make my job as a web developer easier or harder? At this point, the jury's still out, but I think the answer is probably "easier."

Given that even the best browsers' WC3 implementations are incomplete and buggy, content authored at any given time will always be informed by its creation date. The markup, CSS and other code will be optimized, hacked and filtered according to the current user-agent status quo. Living, breathing web sites will no doubt continue to upgrade their code to take advantage of newer browsers and the emerging standards they support. But version targeting will allow these sites to choose when to "flip the switch" between one generation and the next. Instead of rushing out to rewrite their entire site to coincide with the launch of a new browser, site owners will be able to do so only as the new browser gains market share and its quirks and bugs have been tackled by the early adopters. As for sites that live on more as historical artifacts than going concerns, they will continue to render as intended in something approaching perpetuity.

The bottom line here is that "write once, render forever" is a myth. The release of new browsers has always "broken" existing sites in subtle or seismic ways for over a decade now. Web standards may have encouraged us to write markup that won't degrade over time, but the CSS that controls the display of that markup has needed constant maintenance with each new release from every major vendor. (And don't get me started about the JavaScript.) The real win for the standards movement hasn't been the creation of future-proof websites, it's been the creation of decent interoperability in the present. Sure, every browser has its bugs and quirks, but the differences today are much less pronounced than they were a decade ago. Today, thanks to web standards, we can write markup and CSS and JavaScript that, with a little duct tape and caulking, works across all of the current browsers - and we can do so efficiently enough that it's worth the extra effort.

That's not how fanatics see it, however. The standards-at-all-costs dogma elevates a hopeless ideal - that strict compliance with web standards will make the Web a better place - into a litmus test for Internet virtue. If you don't apply abstract notions of semantic/standards purity to all of your code and content, then there's something morally wrong with you. It's this weird sort of neo-Puritanism, like being a vegetarian or a Mac person - or a copy editor. (And I say this as a former copy editor and ex-vegetarian who's typing this on a brand-new MacBook.)

When I listen to the standardistas hammer on, I can't help but think of newspaper editors who blindly rewrite every article into the house style at the expense of style and readability. Just as blind adherence to the AP stylebook encourages copy that's poorly written in a perfectly uniform way, blind adherence to web standards encourages a schematic checklist of development practices that may or may not be appropriate to the project at hand. What this industry really needs is careful consideration by individual developers as to how they should spend their limited resources to build cool stuff. Web standards should be a tool - a means to an end.

With browser vendors tripping all over themselves to implement draft modules from the CSS3, HTML5 and XHTML2 specifications, the first wave of web standards is drawing to a close. We no longer have the holy gospel of finalized, well-established specs to buttress our neo-theological arguments. Rather then measure virtue by our adherence to abstract ideals, we should look at emerging standards - both official and de facto - with a practical rather than a spiritual eye.

agile ajax

Comments: 5 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   What I want to know is this: Will Microsoft’s move make my job as a web developer easier or harder? At this point, the jury’s still out, but I think the answer is probably “yes.”

   Uhh… what were the choices again? “Yes” easier, or “yes” harder?

   Comment by David Golightly, Monday, February 4, 2008 @ 12:57 pm

2. 

   Oops. Corrected. Hey, I _said_ I was an EX-copy editor. At any rate, it’s “yes, easier.”

   Comment by Brian Dillard, Monday, February 4, 2008 @ 1:44 pm

3. 

   I think it’s a bit of a broad generalization to group the entire argument against this idea as ‘blind faith’ in standards. Sure, some of the noisier comments are lacking in substance, but there are some very valid points to consider as well.
   Most of the anger is in backlash to the proposed default behavior, not the idea of version targeting as a whole. I understand that some sites will want this fix, and for them it’s probably the only reasonable short-term solution. But I find it very hard to believe that anyone with a website will have trouble adding a meta tag to lock their own site into a back version of IE. Opting into this is the key issue here. Going back to all my sites and adding a tag to tell IE to keep using its latest engine just seems backwards.
   Also, lets not pretend that this is anything other than an IE issue. You state that sites regularly break when browser versions come out (”The release of new browsers has always “broken” existing sites in subtle or seismic ways for over a decade now”), but this isn’t really a big problem with Safari, Firefox, Opera, etc (which have all had plenty of releases). Even with IE: most sites that we built with conditional comments to work in IE6 rendered almost perfectly without them when IE7 came out. This is a great case for using standards as a future-ready practice.
   I don’t think many people are arguing against emerging standards. Just certain aspects of this proposal, that’s all.

   Good blog by the way. I’m a regular reader.

   Comment by SJ, Monday, February 4, 2008 @ 3:42 pm

4. 

   @Brian Dillard: “What I want to know is this: Will Microsoft’s move make my job as a web developer easier or harder? At this point, the jury’s still out, but I think the answer is probably ‘easier’.”

   Correct, but not for the reason you think.

   Standards-compliant browsers now have a big enough market share that they can no longer be ignored by developers. In Europe alone, Firefox has a 28% market share. Therefore, developers have to design their pages to conform to standards to get the best, most reliable rendering in these browsers.

   Internet Explorer 7 as well cannot be ignored. Heck, we can’t even ignore IE6 yet. Therefore, we must continue to design web pages to have a gracefully degraded fallback on IE7.

   But that’s not the case with IE8. So long as we use a known, non-HTML5 doctype, it will (supposedly) render any page like IE7. Thus, once I’ve designed a standards-compliant HTML 4.01 page with conditional HTML and CSS tweaks for IE7, I’m done. I don’t have to change my development model at all.

   @Brian Dillard: “[...] even the best browsers’ WC3 implementations are incomplete and buggy [...]“

   All major non-IE browsers render standards-compliant pages almost identically. I personally test my pages in Mozilla Firefox, then Opera, then Safari, and finally Internet Explorer. Once I’ve developed the initial layout in Firefox, it only takes at most few minutes to tweak it for Opera, and then I always get Safari for free after that. But when I get to Internet Explorer, I spend several hours reworking the site to render properly. I’ve actually run into a situation where I had to introduce frames into a frameless layout solely to get it to render properly in IE.

   To be fair, there are a few edge cases where standards could be better supported across competing browsers. (In some cases, the specified behavior is universally deemed impractical by all vendors.) However, it’s misleading to suggest that, because browsers which support the vast majority of today’s Web standards don’t support them _perfectly_, we should excuse a browser that only supports about 60% to 70% of those same standards. There’s a difference between approaching a law of diminishing returns in your standards implementation and resting on the laurels of your market share.

   As for “buggy”, I don’t think recent release versions of most browsers have any significant stability problems. Updates to browsers that break existing standards-compliant content are the exception, not the rule, and new releases by contrast usually fix pages that were broken in previous versions rather than the other way around. In fact, Microsoft’s competition not only tend to have few security-related bugs for their browsers, but they usually have less severe security flaws that are patched faster.

   @Brian Dillard: “Just as blind adherence to the AP stylebook encourages copy that’s poorly written in a perfectly uniform way, blind adherence to web standards encourages a schematic checklist of development practices that may or may not be appropriate to the project at hand.”

   I’d say there’s a world of difference between blindly violating established conventions and standards and deliberately breaking with those standards to achieve a specific effect. There are situations where you might need to deviate from a standard.(For instance, if I include the |autocomplete| attribute in a login page, my page may not validate, but I may put it in anyways due to security concerns.) However, this does not excuse people from ignoring best practices and standards for convenience sake. Ideas such as separation of semantic content, presentation and behavior are designed to save time in the long run, and ignoring them for short-term benefit usually ends up costing you later.

   @Brian Dillard: “With browser vendors tripping all over themselves to implement draft modules from the CSS3, HTML5 and XHTML2 specifications, the first wave of web standards is drawing to a close. We no longer have the holy gospel of finalized, well-established specs to buttress our neo-theological arguments.”

   This is mainly standards-supporter-basing FUD. Let’s take CSS first. Most new CSS properties in non-IE browsers are first implemented as experimental vendor extensions (such as “-webkit-border-radius” and and “-moz-border-radius”), then implemented under their proper names once the spec reaches maturity. This simple practice would allow Microsoft to implement CSS3 experimentally first, then properly later, without breaking compatibility with existing pages.

   Note that most web developers would be ecstatic if Microsoft just implemented CSS 2.1 in IE8, so CSS3 is very cart-before-the-horse. In fact, CSS Level 2 Revision 1 (CSS 2.1) is a rewrite of CSS 2.0 to reflect how CSS 2 was actually supported in browsers (including Internet Explorer), so Microsoft will have little more to do than emulate the existing support of their competition.

   Most of HTML5 is actually dedicated to documenting the _existing_ behavior of various browsers, including IE. What new elements it does introduce are either well supported in non-IE browsers or have well-understood presentations. Unlike HTML 4.01, HTML5 is much more detailed on how a browser is to handle various elements, and is specifically designed to be used as a reference for implementing new browsers. Furthermore, HTML5 was designed from the very beginning to gracefully degrade when viewed in legacy browsers, thus minimizing breakage. In other words, HTML5 was designed from the ground up to be implementable by Microsoft. The HTML WG even has Chris Wilson as a co-chair.

   As for XHTML 2, Microsoft would have to support XHTML 1.0 first, so it’s a red herring.

   @Brian Dillard: “Rather then measure virtue by our adherence to abstract ideals, we should look at emerging standards - both official and de facto - with a practical rather than a spiritual eye.”

   We’re talking about extra work, disk space and bandwidth purely to get a (hopefully) standards-compliant rendering of what was supposed to be a standards-compliant page in the first place. Granted, there’s a lot of IE-specific content out there, but there are better ways of handling the situation. For instance, they could have limited the default IE7 rendering behavior to Quirks Mode and Limited Quirks Mode (”Almost Standards Mode”). This alone would catch the vast majority of IE-specific content without forcing most standards-compliant pages into a lesser rendering mode.

   Another way to handle it would be to restrict the IE7-by-default behavior to specific zones such as “Local intranet”.

   At this point, though, I really don’t care if it defaults to IE7 rendering. It’s looking more and more like IE8 will disappoint when it comes to standards compliance, so I’d rather have my content render in a legacy IE rendering mode than waste my valuable time supporting yet another substandard rendering mode that will be obsolete when the next version comes out.

   Comment by Matthew Raymond, Tuesday, February 5, 2008 @ 11:39 am

5. 

   Seems to me that you’re one of those people who just wants to do the minimum amount of work to get the job done on time and as easily as possible. I personally wouldn’t enjoy working with you at all (not that anyone asked my opinion) based on what I’ve read here.

   “The endless hand-wringing over browser version targeting in IE8 illustrates what’s wrong with the web standards community.” - You

   What, exactly, is wrong with the standards community? Microsoft, a corporation who’s actions reverberate loudly throughout the online community and inevitably impact every facet of a developer’s daily life is proposing a solution to a problem which will effect a *huge* majority of the development community. It is incredibly important that people have an opinion and make there voices heard (as you have in your post). Some people may “squable” over certain technicalities, but if they don’t then who will? You? Nope

   “…A List Apart - the standard-bearer of web standards…” - You

   Sorry, “standard-bearer of web standards” = http://w3.org

   “…First, a little background: Howls of protest echoed…” - You

   Sounds like there’s an opinion on whether the meta tags are a good idea or not buried in there… Also, people weren’t howling, they were expressing there opinion just like you are now

   “…Basically, from IE8, onward, Explorer will include multiple rendering engines and display individual pages based on the browser version targeted by this new meta tag…”

   Hence the debate, or as you call it “endless hand-wringing”; Is there a need to include a meta tag for any other browser in order to render a document correctly? Should there be? Should we just write gracefully degrading markup and CSS? Should we just use the standard doctypes and deal with the rendering problems as we have in the past (hacks/conditional comments/browser sniffing/etc)? Whichever you vote for doesn’t concern me much, but the fact that you are a self proclaimed website developer who is essentially “dissing” the development community because they are contributing there opinions in an attempt to better the future of web development while touting the following paradigm:

   “What I want to know is this: Will Microsoft’s move make my job as a web developer easier or harder?”

   … is what pushes my buttons the most. I would say thank you for your “Howls of protest” over the way the development community has reacted to the proposed small and subtle changes that WASP and Microsoft have proposed. We appreciate your strong and unwavering opinion and participation in the web development community. Your understanding of the standards process and how it affects all tiers of the online community makes you… Whatever, you get my point.

   Wasting my breath,

   Good post though, fortified my position regarding so-called web developers who don’t have opinions on developments that have large repercussions on the web development community so long as it makes things easier for them

   Comment by Anonymous, Tuesday, February 5, 2008 @ 5:11 pm

Leave a comment