What’s Best for Web Standards?

Posted January 30th, 2008 by Mike Cherim

This page tested in... Firefox v87.0.1, Opera v110.1, Safari v91.6, oh, and, Internet Explorer v7 I’ve been reading the various facts and opinions (links at the end of the article) and the pros and cons about the plan proposed by Microsoft that will make “DOCTYPE Switch” obsolete beginning with the up-and-coming Internet Explorer 8 (IE8). This news has angered some standards-compliant web developers, while others are finally seeing light at the end of a seemingly endless tunnel — a tunnel filled with various IE versions of past and present partially blocking the way. Immediately I was against the idea, but I do see the good side of it, too, what with never having to deal with IE version fussing and constant updating again. And if other browser developers jump on board with this idea we will never have to update our sites again (yeah, sure, ha ha). Like a good sales pitch it has appeal. But maybe this is a surface sheen.

Can We Live with This?

I have one primary concern over the long-term viability of this plan:

Does this clever plan allow for the adoption of new user agent and web building technologies? How, for instance, are legacy rendering engines supposed to handle new elements and style selectors on new pages as they come to be? Will web developers have to make multiple pages, one with legacy elements and another for current technologies? If so, this defeats the whole purpose. No meta tag is going to address this, and, as such, this seems at best to be a temporary way to address the real issue of old sites in need of revamping. It seems to me that if we want to stay current, we will have to continue feeding page edits to the change monster.

Is this Really Needed?

If IE8 is going to embrace web standards, why is this even needed? I mean standards-compliant sites should be just fine without having to do a thing. This is being done so older sites don’t break — and soon we’ll all have older sites. I have updated some of my sites up to five times as new technologies have entered the scene and I learn how to do things better. The web is fast moving and it needs to keep moving. This plan allows for stagnation of the web and will bring the web as a whole no closer to web standards than it is now if I’m reading into this correctly. Had Microsoft bitten the bullet when they developed IE7 and made it fully compliant (I was disappointed they did not), there would have been a bunch of angry developers and site owners who would have been forced to make the leap to fix their stuff, but by now that would have blown over, the web wouldn’t be broken as it is, and there would be a lot more standards-compliant sites out there.

Full Compliance is Necessary

The web and its technologies are fast moving. This movement needs to continue, but standards need to come first (not by patting someone on the head and them it’ll be okay to remain as is and do nothing). Without web standards, no fix will be viable in the long term. To the best of my knowledge, there is no mature industry in the world that doesn’t have some sort of standards. Without standards, in fact, an industry, any industry, will more than likely be unable to grow up to its fullest potential. This has been proven time and time again throughout history. Granted the web is quite new relatively speaking, so it’s understandable that methodologies on many levels haven’t yet coalesced into a single body moving in one direction. But the web isn’t so new that non-compliance is excusable. And now, what with plans like Microsoft’s on the table, I think the hole may be getting dug deeper because once a developer is ready to update a site, backwards compatibility will not be served and forward compatibility (for IE) will not exist.

Selfishness on My Part?

I may sound cold and uncaring about all those older sites out there that will break, and all the pains non-complaint developers will be faced with as they scramble to play catch-up. I’m not, though. I do feel bad for those folks. The changes won’t affect me nearly so so it might sound like selfishness on my part, but it’s not. I am in this position because I have been developing to web standards all along. I chose to work preemptively. It’s not my fault those who will be hit the hardest have rested on their laurels all this time. But isn’t it about time the gap is closed — instead of being propped open forever. Eventually the feces will hit the rotary oscillator (the shit will hit the fan). This plan seems like an infamous MS Patch more than anything else, and patches are never permanent.

Some Worthy Arguments

There are some good arguments for both sides of this. Here are some related posts and articles that will shed more light on this subject and offer diverse points of view. For me, I’m roughly 90% against and 10% for, but I still have to weigh all points of view before I am 100% either way.

15 Responses to: “What’s Best for Web Standards?”

  1. Elliott responds:
    Posted: January 31st, 2008 at 12:47 am

    Oh, sure Mike, thanks a lot!

    I was getting ready to go to bed and you had to bring this up. Now I have to start reading some of the great links from the other guru’s out there on this topic. Thanks for adding to my insomnia!

    Hey, by the way, nice text box! :)

  2. Georg responds:
    Posted: January 31st, 2008 at 7:56 am

    The problem with the way the announced IE/win version targeting works is that once implemented it can never be taken out again. And yet, it probably has to be taken out, or be stopped at a certain version-stage, one day. Having to deal with rendering-differences between documents created, and frozen, for a few dozen different versions, may become too much even for MSIE.

    The new HTML 5 doctype will eventually make the IE/win version targeting a non-issue for new sites, but many old sites will not be upgraded and still must be supported if one is to avoid “breaking the web” as is the argument now. May take quite a while before someone says: “enough is enough”, but it will have to be said - one day.

    The “mode” problem itself started the day deviations between W3C standards and what’s now known as “quirks modes” made mode-switching necessary. W3C standards came too late and didn’t build on what was already de-facto standards - IE/win standards. If W3C standards had expanded de-facto standards, then the doctype switching would not have been needed in the first place, and old browsers had just ignored what they didn’t understand, instead of having to change the way they rendered what they understand.

    Future standards are supposed to build on existing W3C standards and de-facto standards within “standard mode”. Thus, slowly but steadily differences between de-facto standards and W3C standards will disappear in new browser-versions - if browsers at least try to adhere to W3C standards, so we will get back to the old “quirks mode” vs. “standard mode” switching. We may even get rid of that switch too, one day.

    I don’t think version targeting is a good idea, but if it is implemented then I don’t think it will create any real problems for clued web designers. I have a feeling it won’t be very helpful for the not so clued web designers though, and that may end up making version targeting a future problem - for Microsoft.

  3. David R. responds:
    Posted: January 31st, 2008 at 1:51 pm

    If you’re barely stumbling upon the version targeting news, I’ve written a neutral article over at WPDFD on this that attempts to explain what version targeting is without expressing opinion or debate.

    Personally, I’m for version targeting. I just think it would be best if IE8 behaved as IE8 by default, rather than defaulting to IE7. I do like that version targeting gives users almost absolute control over how their page is rendered (in IE, of course), but I don’t like that by defaulting to IE7, progressive enhancement takes a hit.

  4. Jermayn Parker responds:
    Posted: January 31st, 2008 at 7:59 pm

    Is it just me or do we have no life ranting and reading about this non stop for weeks on end??
    Im kinder over this!!

  5. Sri responds:
    Posted: February 2nd, 2008 at 2:23 am

    My initial reaction was also completely against it, but then some of the “don’t break the web” arguments for it do make sense - in principle. It’s how it seems to be implemented that I still have a problem with.

    Why opt-in, and not opt-out? (eg. have a meta tag that tells IE8 to use quirks mode, rather than one to use standards mode). Do we really care if abandoned sites break in the newer standards version? By that I mean sites where there isn’t anyone to even just paste in that meta tag on each page to fix them after they break. Archivists would care I guess… not too many heritage/preservation groups out there for websites though (unlike say, architecture).

    But really, I think that an equivalent result can be had by merely using a more granular implementation of doctype switching - and be done passively to boot. For example:

    1. No doctype/old doctype (pre-HTML4) : IE6 / “quirks mode” (which is no change from current behaviour)
    2. Older but still “current” doctype (HTML4): IE7 “quasi-standard” mode
    3. Newer doctypes (XHTML1, HTML5 (if available when IE8 is released)): IE8 strict standards

    They could even be more granular than that, differentiating between Strict and Transitional doctypes, where you could have HTML4 Strict be rendered as IE8, but HTML4 Transitional as IE7. Perhaps similarly for xhtml with strict docs are rendered by the IE8 engine, and transitional pages by IE7.

    That addresses (IMO) the problem cases that get brought up where people had been putting in doctypes even though they weren’t adhering to them when coding the site (often the blame was really on the tool, not the developer). The vast majority of those sites would surely have used a transitional doctype, as a strict type would’ve broken them immediately. And very few developers would’ve used any XHTML type if they didn’t follow standards as it’s still new and not that widely used just yet.

    Also, they could do some things with user-controlled settings. Have IE8 standards mode be the default, except for the obvious quirks mode cases (no doctype, or out-of-date doctype, like HTML3), but give the user a “compatibility mode” button they can toggle to render a page that appears broken because it wasn’t coded to standards despite having a current doctype. Also being able to tag a bookmark with a “compatibiliy mode” flag (automatically turning it on when navigated to) would go a long way towards dealing with those intranet sites that don’t play nice with any newer browsers.

    Lastly, how about the idea of just date-stamping pages? A browser can use a “designed on” date (if present) to determine what was its current version was at the time & render accordingly. Benefit: when a new browser version comes out, developers don’t have to revisit their sites to update the targeting info.

  6. Georg responds:
    Posted: February 2nd, 2008 at 9:06 am

    I wonder what IE8 will make out of this, and how its new version targeting will affect it. Since IE6 can be “forced” to imitate most of what other browsers can do - visually that is, regardless of mode, and IE7 is just a patched up IE6, I can imagine all sorts of ways to mess up IE8 in IE7 mode :-)

  7. Stevie D responds:
    Posted: February 7th, 2008 at 8:38 am

    Does this clever plan allow for the adoption of new user agent and web building technologies? How, for instance, are legacy rendering engines supposed to handle new elements and style selectors on new pages as they come to be? Will web developers have to make multiple pages, one with legacy elements and another for current technologies?

    That’s a bit of a red herring - I don’t think the <meta> tag has anything to do with that. That’s an HTML5 issue, which is competely different.

    I assume that IE8 will support HTML5. But IE7 won’t. So if you want to use the newer features of HTML5 - or any other new features that are added - you will have to decide whether to (i) maintain a separate version for IE7 and other older browsers, (ii) let older browsers ignore the new features, or (iii) [and I think this is possible] use a script to replace the unknown elements with known elements in older browsers.

    But you would have to do all that regardless of how IE8 renders a page with/without a doctype or meta tag.

  8. Anthony responds:
    Posted: February 8th, 2008 at 4:53 am

    My main concern on this topic is that other browsers are ok, its Microsoft that need the fix to a problem they have caused, it was ie6’s box model interpretation that used to cause the most hassle amongst other bugs and ie7 was a massive improvement, if they just improved ie7 a little more they would have a great ie8 browser! I don’t understand why we have to keep allowing sites to render in ie6 or in the future ie7 - I think we should let go of out of date technologies and move things forward for the better rather than worry about legacy code from ten years ago, for which, lets be honest if any company cares about their online profile should be updating regularly anyway.

  9. Sri responds:
    Posted: March 4th, 2008 at 12:00 pm

    FYI. Microsoft has relented & have now announced that IE8 will in fact default to it’s native standards mode, instead of IE7’s version of it.

    Link to Internet Explorer team blog

  10. Sri responds:
    Posted: March 4th, 2008 at 1:35 pm

    Yeah - that was a D’oh moment on my part (I typo’d the quotes on the link… opened with a single, & closed with a double… sigh).

    Let me try again… (cross-fingers)

    That link was to this post on ArsTechnica.com

  11. Max responds:
    Posted: March 31st, 2008 at 11:19 am

    Ie8 in my openion is more compatible and also Firefox but the best option for IE8 is good for CSS uses.

  12. Sir Lemons responds:
    Posted: May 23rd, 2008 at 10:07 pm

    I believe Microsoft is on the right track making IE more standards compliant. I use IE8 as my main browser and I usually have it emulating IE7 as some popular sites do not render properly as they believe all versions of IE are hopeless and therefore they add styling and scripts designed only for versions prior to IE8. I am sure to have the full version as soon as it is released, which is, unfortunately, expected to be in another 18-24 months.

Sorry. Comments are closed.

Note: This is the end of the usable page. The image(s) below are preloaded for performance only.