Microsoft listens
Wednesday, 5. March 2008, 19:01:13
Posts tagged with "X-UA-Compatible"
X-UA-Incompatible
Wednesday, 6. February 2008, 13:27:45
If you can't stand any more X-UA-Compatible debate, apologies for fuelling it. It's just that several people arguing for the merits of the proposal - including very high profile supporters like Eric Meyer and PPK assume that the versioning META tag won't affect other browsers. The theory goes that Opera, Mozilla, Safari, Konqueror, iCab et al will keep doing whatever they are doing and only IE8, 9, 10 will have to add multiple modes.
This assumption is WRONG, WRONG, WRONG.
Opera had to follow Mozilla and add an almost-standards mode (which wasn't so bad actually since Eric and Mozilla defined very clearly what the mode was about). If META X-UA-Compatible gets used on the web, we WILL encounter pages that apply CSS meant for a very specific quirk in IE8, and we will have to do something about it. And if Microsoft has taken this shortcut without documenting the IE6/7/8/9 quirks it covers, we're left to figure that out with time-consuming testing. The cost of being compatible is again placed on IE's competitors.
Today at least the HTML standard is being actively developed. CSS development is less open so I don't know what happens - if anything at all - but we have a situation where Microsoft could use fresh implementation experience to improve the specs, tell us what is compatible with the web and what isn't.
A small story to show what I mean by that: the CSS "display" property used to have the values "none", "inline" and "block" (maybe others, I'll simplify). At some point the CSS group decided to also add values like table-row and table-cell.
The problem was those styles also worked "in reverse", so a "TD style='display:block'" would not be a table cell anymore - it would become a block element, and thus mess up most of the table it was a part of! And because several important existing sites were hiding TDs or TRs by setting style.display='none' and showing them again by setting display back to 'block', Opera ran into serious problems. Sites like allmusic.com broke in very ugly ways. (Besides, they weren't exactly quick to fix it when we pointed it out to them..)
In this situation, it would have been sweet to be able to go back to the working group and say: "look, we had some problems supporting this spec-in-progress, could you consider changing 'display: table-row' to for example 'table-display: row'?" What if Mozilla instead of implementing almost-standards-mode could have discussed whether the standard could resolve the dilemma?
Microsoft has this window of opportunity with HTML5. It probably has it with CSS3. So please join the collaboration - detail by detail - instead of ramming a maddening number of X-UA-Compatible modes down our throats.
This assumption is WRONG, WRONG, WRONG.
Opera had to follow Mozilla and add an almost-standards mode (which wasn't so bad actually since Eric and Mozilla defined very clearly what the mode was about). If META X-UA-Compatible gets used on the web, we WILL encounter pages that apply CSS meant for a very specific quirk in IE8, and we will have to do something about it. And if Microsoft has taken this shortcut without documenting the IE6/7/8/9 quirks it covers, we're left to figure that out with time-consuming testing. The cost of being compatible is again placed on IE's competitors.
Today at least the HTML standard is being actively developed. CSS development is less open so I don't know what happens - if anything at all - but we have a situation where Microsoft could use fresh implementation experience to improve the specs, tell us what is compatible with the web and what isn't.
A small story to show what I mean by that: the CSS "display" property used to have the values "none", "inline" and "block" (maybe others, I'll simplify). At some point the CSS group decided to also add values like table-row and table-cell.
The problem was those styles also worked "in reverse", so a "TD style='display:block'" would not be a table cell anymore - it would become a block element, and thus mess up most of the table it was a part of! And because several important existing sites were hiding TDs or TRs by setting style.display='none' and showing them again by setting display back to 'block', Opera ran into serious problems. Sites like allmusic.com broke in very ugly ways. (Besides, they weren't exactly quick to fix it when we pointed it out to them..)
In this situation, it would have been sweet to be able to go back to the working group and say: "look, we had some problems supporting this spec-in-progress, could you consider changing 'display: table-row' to for example 'table-display: row'?" What if Mozilla instead of implementing almost-standards-mode could have discussed whether the standard could resolve the dilemma?
Microsoft has this window of opportunity with HTML5. It probably has it with CSS3. So please join the collaboration - detail by detail - instead of ramming a maddening number of X-UA-Compatible modes down our throats.
Suggestions for Chris Wilson
Wednesday, 23. January 2008, 07:07:17
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:
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
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.
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.
Hallvord R. M. Steen
debugging debuggers..
Latest comments
Nice work, your blog have interest it's good. ahhh...if you inte ...
Have you used Vital's script?Yes Any idea how they compare in t ...
fearphage: thanks, I was not aware of Vital's JS beautifier. Fun ...
Doesn't Opera have an internal function->string pretty-printer D ...
This is certainly one of the things that I think Dragonfly needs ...
Not to belittle your work but we actually had this already (sort ...
Tags
Recent visitors
A proud member of the My Opera community. | Help | Disclaimer