This website is, sadly, defunct. But! Ethan’s new website is here for you to use.

Unstoppable Robot Ninja

The site navigation:

Code Happy

As a technical editor at A List Apart, I’ve been fortunate enough to have a draft of Aaron Gustafson‘s latest article sitting on my laptop for the past couple weeks. While I wasn’t involved with editing the article, I have been thinking quite a bit about since it went into production. While Eric’s made some sort of peace with the proposed “version targeting” mechanism, I’m still feeling as uneasy about it as I did when I first read the piece.

Damned uneasy.

I'm convinced the premise for version targeting is supremely flawed. If I’m reading Aaron’s article correctly, the argument for it is predicated on a logical fallacy:

  1. The DOCTYPE switch is used on invalid pages.
  2. Some invalid pages are broken.
  3. Therefore, the DOCTYPE switch is broken.

IE7 didn’t, as Chris Wilson suggested, “break the web,” and neither did DOCTYPE switching. It’s like Drew said: this myth of broken sites isn’t enough to justify a new paradigm for developing websites, and breaking the promise of forward compatibility. DOCTYPE switching isn’t broken: it’s the publishing processes and software that allow us to publish invalid, untested HTML to the web.

And here’s the important bit: None of this is Microsoft’s responsibility. Nor Firefox’s. Nor Opera’s. The burden is upon developers and designers to comply, test, and validate. As it stands, version targeting won’t improve the quality of our code, or improve the current state of future proofing. Rather, it’s a software patch intended to fix broken human behavior. We need to fix the problem at hand, and a new meta element isn’t the answer.

I have other problems with this approach (ranging from implementation, to wondering exactly who will maintain a registry of user agent acronyms, to the WaSP’s involvement in this whole thing), but there’s already a fair bit of discussion along these lines. And frankly, I still need to think more about this: two weeks hasn’t been enough to really flesh out all my concerns. And hell, maybe I’ll come around on this whole issue—I don’t know.

But I do know that at the moment, I’m still uneasy.

This is a blog entry posted on day 11185 in the Journal.

12 comments posted.

12 Comments

  1. Eric Meyer says:

    I think there’s one inaccurate meme that needs to be addressed: the idea that lots of site breakage occurring in IE7 is a myth. Unless of course you want to claim that the IE team is flat-out lying about what they experienced.

    No, my sites didn’t break, and yours probably didn’t either, but you and I are not even close to being representative of all web development.

  2. David Storey says:

    And web sites break in other browsers due to those sites relying on broken IE behaviour that we (other browser vendors) can’t replicate. Should IE be given a get out of jail card to avoid trying to fix these issues, while we are still saddled with the problem? This is a problem created by Microsoft, and exaggerated by their illegal monopoly, which got web developers to code for IE’s broken problems in the first place.

    I work damn hard trying to fix these issues, and we have far less resources, money, marketing and developer good will to throw at the problem. will a site fix an issue if Opera contacts them with the problem and solution? Sometimes they do (but less likely if they know that broken behaviour will never break IE). Will the same site fix it if Microsoft contacts them? If they value their site revenue then sure as hell they will.

    MS created this mess. They should fix it.

  3. Brad Dielman says:

    I echo your uneasiness. I agree with your point about the core of the problem being on the part of the developer.

    I don’t see why we have to rely on a poorly implemented fix (IE7 rendering by default) to compensate for a developer’s inability to keep up with current best practices.

  4. The Robot says:

    Eric, you’re probably right. But whether it was 99% of their users or 0.9%, I still think the reasoning for the targeting mechanism is flawed.

    An “opt-in” approach to improved rendering might be the best solution we can get from Microsoft. I still don’t think, however, that it’s a good one.

  5. Travis Schmeisser says:

    GREAT comments. I think this point of view is an important point. I’m in the same boat as you and you’ve only put me farther to that side. I see Eric’s side from his article, but still very uneasy.

  6. Ian Muir says:

    “And here’s the important bit: None of this is Microsoft’s responsibility. Nor Firefox’s. Nor Opera’s. The burden is upon developers and designers to comply, test, and validate.”

    HELLS YES!

    I’m personally sick and tired of people complaining. Browser issues are a fact of the industry. If you can’t handle it, please stick to print design.

    @David: Does IE really have a get of jail free card? It seems to me that they’re usually target number one.

  7. Nicholas Stimpson says:

    It’s simply not true that IE7 only broke invalid and untested HTML. My web site was fully and carefully validated and thoroughly tested. It worked in Firefox and Opera 9 as well as IE6. Yet it broke in IE7. OK it only took me 1 or maybe 2 evenings to find a CSS combination that worked in IE7 as well as the others but they all needed retesting to ensure that I hadn’t broken the rendering on any of the browsers.

    It was frankly a waste of time that I could have used more productively. How much easier and safer it would have been to have been able to add <meta http-equiv=“X-UA-Compatible” content=“IE=6” /> and have IE7 render the pages as if they were IE6. I could have been certain then, that my change wouldn’t break the rendering in any other browser.

  8. The Robot says:

    Nicholas, I don’t think I suggested that the IE7 upgrade was a flawless one; I worked on a number of sites that required modifications (however minor) after the upgrade. The “myth” I mentioned was Microsoft’s fallacy that the breakage is so very widespread. And if we’ve been diligent in keeping our code up to standards, then the upgrade from IE7 should be less painful.

  9. Adrien McNamarra says:

    Indeed, in general pursuit after Microsotf’s flaws and voice of scepticism towards the new IE8 we tend to forget that much of the problems occured due to ignorance an lazyness of web designers themselves. I’m also curious how the proper browser name acronyms will be listed and who will be in charge of it.

  10. James says:

    And it’s not like they’re not introducing new doctype switches – <!doctype html> will trigger super-standards mode.

  11. Andrea Creviola says:

    The very idea of making older documents readable only be rendering them in a single IE rendering mode is ridiculous. This is already the case with older Word documets and Microsoft seems to follow the same old solutions.

  12. Howard Davies says:

    It’s sad but true that many web developers are unable or not eager to keep up with the most recent standards and tendencies. I agree with you that many problems arise simply form ignorance of our own not community and we can’t blame everything on browser vendors. I’m still not sure what to think about the solution with the doctype switch, primariliy because not much information has been so far released by Microsoft. Perhaps temporariliy it will work, but eventually designers will have to come up with a better idea.

This was Ethan Marcotte’s Unstoppable Robot Ninja.

You are welcome.

Design and content © 2020 Ethan Marcotte. All rights reserved.

Photo copyright © Marvel Comics.

Skip to the navigation, or skip to main content.