Discuss: Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8
by Aaron Gustafson
- Editorial Comments
42 MS Marketing strikes again ...
Having just read the comments at http://blogs.msdn.com/ie/archive/2008/01/21/compatibility-and-ie8.aspx, which are similarly negative to the ones here, it occurred to me that this decision reeks of MS Marketing.
This isn’t a decision to help the end user, or web developer, which is how it’s being sold. This is a damage limitation strategy by MS Marketing and it’s another ‘divide and conquer’ mechanism that the mighty MS is so fond of.
Opera, Mozilla, Safari don’t ask for special treatment when they release a new, improved browser – but then they’ve adhered as closely as possible to W3C standards, so the impact is usually minimal.
MS/IE on the other hand steals more time and resources with every release – doctype switches, CSS hacks, conditional comments for 5.5, 6, 7 and now they’re giving us meta switching. Where does it end?!
We all accept that the web is an evolving entity, and most of us have come to recognise that adherence to a strict set of standards is the absolute best way to ensure future compatibility. Everyone apart from Microsoft and now, sadly, WaSP.
“Web design – 10% creativity, 90% Microsoft Internet Explorer”.
posted at 04:39 pm on January 22, 2008 by David One
43
First off, let me say that I too shared the reservations many of you are expressing. In fact, it took me nearly two months to realize that this was the best way to move the web forward while preserving our investments thus far.
In response to a few questions/statements:
I am fearful of the possibility that companies stop thinking about how to offer improved accessibility, usability, and functionality buy building a site that is IE7 compliant and then leaving it for the next 10 years, bugs and all.
God, I hope that’s not the case. But think about a site built for the current field of browsers, perhaps something critical like an online banking application. Let’s say that a new browser version launches 3 months after the application is brought online and the team has coded to web standards, has used unobtrusive JavaScript, and everything else that is considered a best practice right now. If that browser has a single bug that affects a critical part of the application, the team has to scramble to fix the break as soon as they hear about it from a user (or several hundred). With version targeting, the team can test the new browser version internally before updating the meta element (or the HTTP header) to add support for that new browser. And no users experience problems, no bosses freak out, and customer service isn’t fielding endless calls they have no idea how to respond to.
I think that’s a pretty good trade-off for adding a standards compliant meta element to documents.
I can’t see Opera (or whoever) in 5 years time delivering an Opera 15 with 5 different rendering engines for versions from 10 to 14!
I am not a browser vendor nor have I ever made a browser, so I don’t know what percentage of browser code is specifically devoted to rendering and scripting support, but I can say that it would seem reasonable to me that browsers may retire certain rendering modes as time passes. Broswers will have the ability to read the rendering modes of pages and report on that. If, over time, certain rendering modes start to take up a smaller and smaller piece of the content pie, it may be justifiable to end support for them. But, again, I’m not a browser maker.
On a related note, computers (including those that drive mobile devices) are becoming exponentially faster and storage is much cheaper than it has ever been. If maintaining support for a legacy rendering and/or scripting engine adds an additional 5-10% to the size of the app, I don’t see that being a huge problem. That said, I am as concerned as anyone with code bloat and hope that knowing these engines will need to exist well into the future will provide the impetus needed to keep developers honest and their code clean.
There’s a big case of weasel words in this article. While it’s fair to say that IE8 in standards mode renders Acid2 correctly, that’s completely not equivalent to ‘passing Acid2’. Passing Acid2 requires the browser to render http://www.webstandards.org/files/acid2/test.html correctly, and I don’t see any meta tags on there.
An astute observation, Robyn it’s true that the ACID2 test doesn’t have the meta required to trigger IE8 to use the latest rendering mode, so IE8 does not technically pass the test. But it is also possible to use an HTTP header to accomplish the same thing as the meta element. So, with the X-UA-Compatible HTTP header applied, IE8 would, from what I understand, pass the ACID2 test.
Can I ask if you were paid by Microsoft for this effort,
and if so how much?
As Jeffrey said, I received no money for my work on this project. In fact, the one time I did fly out to Microsoft for a discussion of IE8, I paid my own way.
I am sorry, but this can only be described as madness. We are talking about browser sniffing and code forking here, are we not?
Actually, no. This implies no code forking whatsoever. Version targeting simply lets browsers know what browser version the site was built against. It does not require or endorse browser sniffing or code forking. Nothing we have been doing, to date, would change, except we would have to include the meta element to tell IE (and perhaps, eventually, other browsers) we are targeting a particular version of that browser. We will be able to continue using progressive enhancement techniques as we have been for the last few years, the only difference being that we will be able to introduce support for new browser versions on our timetable instead of the browser vendor’s.
posted at 04:45 pm on January 22, 2008 by Aaron Gustafson
44 Bad Idea
I have to agree with the majority of posters here, that this is a really bad idea. Do we really want to return to the days of “Designed for Browser X” (albeit in a programmatic form)? If a document claims to follow a particular standard, the user agent should do its best to respect that. How do we explain to amateur designers who are trying to follow the standards why they need to add some additional bit of code to make IE work ‘properly’? If IE and various authoring tools have made a mess of things previously that’s their lookout.
Authoring tools can be upgraded, and if IE7 really “broke the web”, I’d expect people who got burned then to have fixed things in a much more future-proof way, or at least to be much more aware of the issue when IE8 launches.
Moreover, any designer worth their salt will have their site working in Firefox etc. these days. So surely a standards-compliant next version of IE would behave pretty much as Firefox et al. does now, and hence not break that much anyway. (You’d need to rename the trigger string in IE conditionals so things like >IE6 aren’t triggered, but that’s no big problem.) Even if IE8 does break things, all the designer has to do is ensure the main standards version is sent unaltered to IE8 and that should fix most issues…
posted at 04:53 pm on January 22, 2008 by Robert Whittaker
45
In his comment (posted while I was writing my last one), David One preposed the article was making the following statements:
1. we’re imposing on browser-makers to provide increasingly bloated applications to service obsolete rendering standards
2. we’re encouraging web developers to take the easy route and produce sites that favour a particular browser – so much easier than coding to W3C standards … hey! We can all go back to using Front Page Express!
On the first point, I am not im complete disagreement with you, but would like to bring up the fact that browsers may not implement a new rendering or scripting engine between releases, so IE9 may be the same as IE8, meaning no extra bloat would be added to the application. The same goes for any browser.
And as I pointed out in my previous comment, I think the trade-off is worth it.
On the second point, I couldn’t disagree more. No one (not even Microsoft) is saying “too hell with standards.” I plan to continue advocating, as I have for years, building sites to web standards, using CSS layouts and such. This is just another tool to allow developers to control the evolution of the sites we build and make sure they stand the test of time.
posted at 04:56 pm on January 22, 2008 by Aaron Gustafson
46 Scramble to fix breakages
You know, I’d hope my online banking site has developers who will get beta versions of upcoming browsers and fix any major bugs and issues before the site goes live. Surely that’s what you should be expecting as a client?
Regarding my comment about Acid2 and meta elements, my comment still holds. For the moment at least the webstandardsproject.org server isn’t sending any IE-specific headers, so it still won’t pass the test. Fair enough, the server might be altered in the future to add these, but then there’s the whole irony of the ‘webstandards’ server implementing non-standard code to work around the non-standard bugs of a non-standards-compliant browser.
posted at 04:57 pm on January 22, 2008 by Robin Whittleton
47 Very bad idea
The idea is basically desastrous. It simply resembles those old nasty “optimized for browser XY” messages. Not at all a good idea.
If there is a need of adding some kind of compatibility information, there would be a way to do this with minimal efford and without specifying a specific browser but a specific standard.
So already known is the old <meta http-equiv=“content-type” content=“text/html; charset=ISO-8859-1”>. There do exist similar constructs for Script (<meta http-equiv=“Content-Script-Type” content=“text/javascript”>) and style (<meta http-equiv=“Content-Style-Type” content=“text/css” />). All could be expanded by a version info required, added optionally with a separating semicolon, as with the charset in the content-type property. This might be a minimum requirement or an exact requirement, which is up to the browser to decide. This specifies the version of the required standard, not the required browser, which would be much more useful.
posted at 05:05 pm on January 22, 2008 by Siegfried Gipp
48 The view from Mozilla...
One Mozilla dev gives initial thoughts:
http://weblogs.mozillazine.org/roc/archives/2008/01/post_2.html
http://weblogs.mozillazine.org/roc/archives/2008/01/slipping_the_ba.html
I’m looking forward to the response from Håkon (http://people.opera.com/howcome/), whom I suspect will be even more damning.
Finally, this is what Microsoft wrote in 1998:
“Microsoft has a deep commitment to working with the W3C on HTML and CSS…We are still committed to complete implementations of the Recommendations of the W3C in this area (CSS and HTML and the DOM).”
10 years ago they were claiming deep commitment to W3C, and yet they’re still trying introduce more junk code to avoid adherence to those standards.
If it were funny, it’d be a joke.
posted at 05:07 pm on January 22, 2008 by David One
49 Here we go again. Another hack
Why are we, again, having to fix the web for Microsoft. Shouldn’t Microsoft be fixing itself for the standard web? Why are we treating Microsoft as a charity case?
posted at 05:09 pm on January 22, 2008 by howard fine
50 Re: scrambling to fix breakages
If such a scenario happens when, say, Firefox 3 is released, the only people scrambling to fix breakages would be the Mozilla team.
The people making the website would—quite rightly—blame Mozilla for Mozilla’s bug and there’d be a Firefox 3.0.1 within two weeks. Simultaneously, thousands of other websites would be fixed.
The only people this idea will benefit is browser makers who can’t be bothered to fix their own bugs in a timely fashion.
posted at 05:13 pm on January 22, 2008 by Greg Nicholson
Got something to say?
Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.
Create a new account or sign in below if you’d like to leave a comment.
Subscribe to this article's comments: RSS (what’s this?)
41 Totally confused
I am totally and utterly confused.
When creating websites I take the tactic of “build for the best and test for the rest”. I do not know if Firefox is the best, but that’s the one I built initially for. And having been in this work for a couple of years already I manage to create sites that at first not completely fail in the rest. And with a few tweaks I make things work.
I take Web Standards as my starting point.
If a new browser (version) comes along I might test if it is relevant for the site or target users. When something breaks, I fix it.
But now a new concept is introduced. When I am done with building the site and it is fully tested. I must mark it with all the compatible browser versions (what about the combination of browser version and OS?) and I have to do that really careful so as not to miss a browser or version.
When a new browser (version) comes along I have to test it to see if does a good backwards compatible test (does IE 11 renders correctly as IE 10?) and test again to see if IE !! renders correctly as it self?
And finally I will have to make a change to the META tag.
Confusing and unnecessary extra work to say the least.
posted at 04:33 pm on January 22, 2008 by Rob Hofker