Breaking the web
When Dean Hachamovitch demonstrated in December that the forthcoming Internet Explorer 8 browser passed the Acid2 test in standards mode, there were calls for Microsoft to clarify if “standards mode” was the default setting for IE8. Last week it was announced on A List Apart and the Internet Explorer blog that IE8 will render pages using an IE7-level rendering engine by default, and that web developers must opt-in to take advantage of the new Acid2-compliant rendering mode.
The mechanism for triggering the new standards mode is a meta declaration specifying which rendering engine IE8 should use:
<meta http-equiv="X-UA-Compatible" content="IE=8" />This X-UA-Compatible instruction tells IE8 to render the page using the new advanced mode. If the tag is omitted altogether, IE8 will render the page exactly the same as IE7 would.
During the past week I have read a number of articles and blog posts about the proposed version targeting changes in IE8, and while I am warming to the idea, I still have nagging doubts whether Microsoft’s implementation is the best approach to take.
The future of web standards in Internet Explorer
Microsoft’s stated reason for introducing version targeting is to avoid a repeat of the backwards compatibility issues experienced when IE7 was launched. Although IE7 was embraced by the web standards community as a bold step forwards, it was seen by many within Microsoft as somewhat of a failure. Sites that previously worked in IE6 unexpectedly “broke” in IE7, and Microsoft want to avoid making the same mistake when IE8 is released.
The mantra of the IE development team has always been “don’t break the web”, and version targeting is their way of making backwards compatibility a reality in IE8: the browser upgrade process will be painless for end users, there won’t be hordes of angry web developers hollering that their sites are “broken” in IE8, and inside Microsoft support for web standards will no longer be seen to occur at the expense of customer satisfaction. This last point is particularly significant for the future of web standards in Internet Explorer.
It seems fairly clear that those on Microsoft’s IE development team who advocate for web standards have had to fight every step of the way. I’m sure that there are loud voices within Microsoft who couldn’t give a damn about web standards, and whose greater concern is that when they release a new version of Internet Explorer existing websites continue to render as expected. As Jeffrey Zeldman points out, the inclusion of version targeting in IE8 will smooth the path for standards advocates within the IE team :
“Microsoft won’t be inundated with complaints which, in the hands of the wrong director of marketing, could lead to the firing of standards-oriented browser engineers on the IE team. The wholesale firing of standards-oriented developers would jerk IE off the web standards path just when it has achieved sure footing.”
But the proposed changes to Internet Explorer are not without their pitfalls, I suspect.
Frozen in time
One problem I see with the proposed version targeting mechanism is the potential harm it will do to the adoption of web standards. By the time IE8 is released, standards-aware developers will will be intimately familiar with the X-UA-Compatible instruction, and will be in a position to make an informed decision about which rendering mode they support. But what of the legion of web designers and developers who have a less sophisticated understanding of web standards?
However much confusion may have been caused when IE7 “broke” websites that had previously rendered as expected, at least it forced web developers to acknowledge that the times were changing and they needed to change their methods to keep up. By contrast, if IE8 defaults to using the outdated IE7 rendering engine it is reasonable to assume that many web authors will remain blithely unaware that their sites may not, in fact, be fully compatible with the new standards-compliant browser. There will be no motivation to hone their craft, since in the absence of an X-UA-Compatible directive flawed pages will render just fine.
What about IE9?
Another nagging doubt I have concerns future versions of Internet Explorer. We know that IE8 will use the IE7 rendering engine by default, but what of IE9? IE10? IE11? Will these new versions also default to IE7 rendering mode, which seems to only way for Microsoft to truly adhere to the “don’t break the web” rule? Or will IE9 instead default to IE8 rendering mode, IE10 to IE9 rendering mode, and so on? If that is the case, all that X-UA-Compatible will achieve is to break the web later, rather than sooner.
If we assume that from IE8 onwards all versions of Internet Explorer will use the IE7 rendering engine by default, the implication is that web authors need never improve their scripting skill set, a prospect I find quite alarming. The only motivation to upskill would come from browser vendors who don’t implement X-UA-Compatible (Mozilla and Apple for example), since their browsers will always render a page using the most current implementation of web standards, drawing attention to any scripting deficiencies.
Opting out
On balance I think that version targeting with X-UA-Compatible is a positive, maybe even necessary step for Microsoft to take. As a means of ensuring that future browser releases don’t “break” intranets and public-facing websites, the X-UA-Compatible instruction is perhaps the only viable solution. It also allows the IE team to continue to implement web standards in their browser without fear of angering the corporate customer base on which Microsoft depends.
But the fact that IE8’s new standards mode will be opt-in seems somewhat counter productive. The message it sends to web developers is that adhering to web standards is optional, rather than necessary. The implementation of web standards in browsers may be far from perfect, and it’s a pain when new browsers break existing websites, but this instability also provides a motivation for us to continually improve the way we build websites.
Might it not be possible to require authors to opt-out of the new rendering mode instead of opt-in? If this were the case, sites that break in IE8 could still be fixed extremely quickly using the X-UA-Compatible instruction:
<meta http-equiv="X-UA-Compatible" content="IE=7" />There would be no need for developers to spend painful hours or days debugging sites that break in IE8. This single line of code would force IE out of its advanced rendering mode and into IE7 rendering mode, fixing any compatibility issues instantly and permanently.
Then again, perhaps like Eric Meyer I will come to fully appreciate Microsoft’s implementation of version targeting. God knows we’ve had enough browser sniffing, code forking and CSS hacks in our industry’s short history, and just maybe this could be a way to leave that mess behind for good.
5 thoughts on “Breaking the web”
Comments are closed.
On one hand, I agree with your idea of opting out instead of opting in. If we had to choose to be excluded from the new render mode, it would encourage more people to revisit their sites and improve them. However, with opt out as the default setting of the browser, once the new version of the browser is released it ensures that your website will remain unchanged until you have the time to return to your site and verify its performance in the new browser. Sounds pretty appealing, doesn’t it? The problem is, in reality how many people will revisit those sites and update them for the new browser? How many will take the easy way out and allow it to continue being rendered in version 7? I would say the majority will take the lazy route.
I think the best option would be to utilize the opt in code, with opt out as the default, but only offer a single step backwards in browser versions. In other words, version 8 features an auto opt out rendering in version 7, version 9 will opt out to 8, 10 to 9, 11 to 10, etc. That way, the designer is forced to update their site to the newer version, but have a respectable time span to accomplish this task. It would continue to ensure progression in the field, but will alleviate the problem of waking up to a deluge of clients wanting their websites fixed now!
Any thoughts?
@Greg – I hope that if version targeting is implement in its proposed form (defaults to IE7 rendering mode), that future versions of IE also fall back only one version, as you are suggesting.
As you point out, this approach would give web authors additional time to fix their sites. However, if an author has not learned of the version targeting changes by the time IE8 is released, why should we assume they will be aware of them by the time IE9 is launched? My suspicion is that many legacy sites won’t be upgraded until they break. That may be when IE9 is released, or if Microsoft take the “freezing” approach, it may happen many versions from now.
Chris Wilson from the IE team has indicated that rather than IE becoming bloated with multiple rendering engines, he sees that eventually the problem will go away. From an interview with Sitepoint:
I’m not sure if we can infer from Chris’ statement whether IE7 will be the default rendering engine in IE9+, or not…
I just don’t see Chris’ statement being overly logical. Even with the hope that the differences between browsers will become less severe, it won’t change the fact that many websites will be stuck at version 7 rendering many versions from now. Plus, if the changes between 8 and 9 are “internally ‘breaking changes'”, then there will be more versions for IE to allow websites to be stuck at.
This is precisely the part of this idea I have difficulties with. If the developer is not forced to update their website for the current, or last previous as I am suggesting, version of the browser, then there will be some websites stuck at 7, 8, 9 ,10, etc. until the changes are not “internally ‘breaking changes'”. The only result will be browser that have to be able to render all previous versions until the versions that feature only slight differences like Chris mentions.
I think your last comment hit the nail on the head with, “My suspicion is that many legacy sites won’t be upgraded until they break.” It would solve the problem for many to allow one previous version to automatically opt out to, but will force an update deadline. This will allow plenty of time for the developers who are aware of the problem to get their sites up to speed. For all the others that won’t be aware of the problem until their site breaks, they need that push to move forward. Otherwise, they are precisely the people that will be holding us at version 7 when the current version is 20.
I believe it all comes down to progression of the field. If some people are sitting behind at IE7 and CSS 2, what difficulties will that cause when we’ve reached CSS 4 or 5? It just doesn’t seem like we’re doing ourselves or anyone else any favors by allowing developers, even inexperienced ones, to freeze in the development of their skills and work. We need to look and move forward, not back.
@Greg
That statement fairly well sums up my concerns too.
Although, I also find myself considering the approach that Adobe (and formerly Macromedia) have taken with Flash. The Flash Player does support a great many (maybe all?) legacy versions of Flash, meaning that if you built a Flash site many years back (I have sites going back almost a decade) they still work today. I am very grateful I have never had to rework these sites, since during that time Flash has had 3 radical revisions to its programming language, and I would literally have to start from scratch! While there there are no doubt some Flash developers “stuck in the past” as far as their programming skills go, I don’t think there is any evidence that backwards compatibility has been a roadblock for the Flash development community as a whole.
Suggesting that we specify specific browser versions in the code is an attack on smaller browsers and enables (and encourages) browsers to vary how they implement standards.
The solution is to specify which HTML / CSS / etc standard we coded for, and, horror of horrors, the browser could interpret correctly? (Maybe a variable for whether you want a browser to “do its best” if it doesn’t fully support the standard you specified.) This plus new HTML and CSS specs that tie up ambiguous loose ends would address the browser compatibility issues that currently double the time required for web projects.