Suggestions for Chris Wilson

How would Chris Wilson feel if people stopped writing him open letters?

I'm nowhere near Brendan's league but here's another "Dear Chris", this time on the proposed <meta http-equiv="X-UA-Compatible" content="IE=8" /> versioning for HTML5.

First: I know you're stuck between a rock and a hard place, between thousands of web developers shouting and swearing at you for not implementing the standards better and millions of web sites that might break if you do. Moreover, knowing first-hand the problems Opera ran into when implementing WebForms 2 I don't doubt for a moment that your compatibility concerns are real.

The proposed META tag sort of shifts maintenance and backwards compatibility concerns from website authors to browser developers, which can be a good thing. However, there are problems with such wholesale version targetting:

  • Browsers will have to support an unmanageable and confusing mess of different rendering modes (and the PocketIE team will hate you for the bloat).
  • Because the META tag affects every part of the page, progressively enhancing such pages with new CSS features will be harder.

The way the web currently works is partial versioning: using JavaScript object detection, conditional comments (IE-only), CSS hacks or special keywords to "opt in to" specific layout or scripting properties. Can we build on and extend that? Enhance feature detection rather than opt-in hard-coded rendering mode?

Some examples of what that might look like..

-moz-box-sizing equivalents for opting in to specific interpretations of given CSS properties

if( 'borderRadius' in element.currentStyle )
@supports-multiple-backgrounds{ div.mosaic{ bacground: URL(bg1.png) top left no-repeat; bacground: URL(bg2.png) bottom right no-repeat } }

I'd like markup or CSS to express "if you support css3-column-layout, fetch that stylesheet, else use this XSL transformation to build a TABLE".. So, feature-based versioning built right into the standard itself instead of added as a META hack and an afterthought. Please consider making the opt-in mechanisms feature-based rather than rendering-engine-version-based!

How can you do it? Well, the IE team may have forgotten what it takes to play catch-up with a different UA implementation (you had some experience back in the NS4 days though) but Opera QA can remind you ;). You could apply the same skills to align the new standard and the new rendering engine with the web:

The web and the spec would benefit enourmously if your team sat down to do the detailed analysis work – hunting through the sites that break, figuring out the main problems, suggesting ways the still-in-progress HTML5 standard could change to make real compatibility possible. It's slow but you can make a public comittment and draw huge grassroot support from web developers. I bet you would get help doing evangelism and outreach for sites that serve you "error correcting" CSS you can't possibly work with in standars mode. You can release IE8 beta versions but delay the final until site compatibility problems are resolved..

We at Opera doing this right now, spending hours analysing IE quirks to figure out how to be compatible with the specs, the web, and the IEs. It's slow. It takes manhours and manyears. But it's what it takes to do it right..

Software is 100% detail. Quality is 100% attention to detail. And the detail called X-UA-Compatible should be replaced with something better. Thanks for your attention.

Advertisements

8 thoughts on “Suggestions for Chris Wilson

  1. Feature based CSS versioning has been argued over and dismissed on many occasions on www-style. The problem is that browser manufacturers will lie or bend the truth to get their feature-complete-but-buggy implementation in.

  2. Robin_reala: has IE8's backwards compatibility woes been considered in such discussions?Feature-complete-but-buggy implementations are a fact of life, unfortunately. Feature based versioning isn't going to fix that for you, I admit that, but it may make it cleaner to opt-out of the buggy previous implementation. Much cleaner and better than CSS hacks, wouldn't you agree?

  3. The link between BE's open letter and this new MS thingy is made clear by John Resig. They oppose ES4 because they say you need two engines, and now they actually propose different versions of their rendering engine.What about MS includes something like ua.ini, where they have a list of sites that require the old IE behaviour? Best of both worlds, no? MS solves the mess they created themselves, while everyone else can happily code to standards and even forget about opt-ins/opt-outs.

  4. Chris says <!DOCTYPE html> will trigger IE8 mode without the need for the meta switch. But, he didn't explicitly say that <!DOCTYPE html> would be equivalent to IE=edge. So, in IE9, the meta might be required, but hopefully not.I'd just throw an IE=Edge header at IE for the whole site (to always get the latest and greatest, which is what I expect), but Hixie mentions that would eventually just cause MS to create yet another method of switching.

  5. The entire IE problem is IE, as is known by everybody. Given that, how do you solve it? By creating a new IE. But then all kinds of _intranet_ pages break. A browser developer cannot detect whether such a page was meant for IE or for Opera (chances are it was IE-targetted due to market share). Now MS has determined the upgrade costs for page devs too high. So the problem is stated easily:1 every exiting page must work as it did in IE7.2 every new page must work by IE8 rules** This is, pages developed by hand or by tools older than the IE8 release date.Point 2 is needed because IE7 is broken. Point 1 is needed because browser vendors are scared for pages to break, see firechicken, which is/was a kind of feature-complete-but-buggy implementation.Both arguments will also hold for IE8, Opera 9.5, Firefox 3, …How to solve the mess? No more vague specs, no more bad implementations and no more bug-dependent sites. This is all very unlikely to happen. The truth is the only real (and badly documented) reference for authors are the browsers themselves. That's why the choice for browser targetting may not be so bad, for browsers with enough market share.The problem for Opera: almost no page will include an Opera target, and the sites will not be updated for new browser versions, because it isn't necessary. This means Opera would have to spend hours analysing IE quirks.I am an Opera user, and I believe is Firefox is not on the right track, and the current IE is broken. However, at the moment I believe the browser targeting is the best option to move forward.Extra: feature based css won't work, because, if it existed a lot of years ago, IE6 would claim to support the css 2 box model and new switches would have to be invented for the firefox box model (firefox 2 + acid2, anyone) and then opera would need yet another switch, leading to browser sniffing like it occured (and still occurs) in javascript.On that account, edge should be removed. Even CSS 2.1 might still change a little and therefor no current browser can be a definitive implementation and no author can code to the spec and be certain his/her page is edge. They will test it (probably in firefox) and conclude it is edge. Edge is _impossible_. You are predicting the future when you use it. You will need to change your page in the future and you will test it in some of the future browsers. It isn't much of an effort to update the numbers.In the end we should ask ourselves: how can we make web time a reality again, without ever breaking older pages.

  6. @reinaut: sounds quite odd to upgrade everything else and not the intranet. If someone wants to rely on outdated intranet software, they can feel free to rely on outdated browsers. If they upgrade all their other computers to use the latest and greatest OS, they can upgrade their intranet as well. Letting specialized intranet applications hold back the entire web is a silly idea.

    The problem for Opera

    Nope, not just for Opera. For everyone else. Especially mobile browsers.http://weblogs.mozillazine.org/roc/archives/2008/01/post_2.htmlhttp://webkit.org/blog/155/versioning-compatibility-and-standards/

    how can we make web time a reality again, without ever breaking older pages

    Probably Can't be done. It might be painful, but it's necessary.

  7. Another idea I've been thinking about: how about the inverse of Dean Edwards IE7.js? A file to downgrade from IE8 to IE7 upon detecting some switch. Is it possible? This means no double engine problem. If it is js, then maybe it can easily be converted to Firefox and Opera too. It would also show that current javascript is capable enough, a point they want to make. Like Opera has to analyse IE quirks already, now IE8 must do it, and we might use it. But then we have to force them to use an open technology for their downgrading. Is it possible? A bad idea?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s