- From: Hallvord R. M. Steen <hallvord@opera.com>
- Date: Fri, 25 Jan 2008 17:41:45 +0100
- To: "Chris Wilson" <Chris.Wilson@microsoft.com>, Smylers <Smylers@stripey.com>, "public-html@w3.org" <public-html@w3.org>
[I have not had time to follow this discussion much across lists and blogs, apologies if I'm just re-iterating..] >> http://www.alistapart.com/articles/beyonddoctype > > Indeed. Aaron thinks it would be useful in other browsers. >> It's also unclear what a user-agent that isn't any of the 3 named there >> (such as one written from scratch) should do on encountering the above >> declaration. Presumably it should try to emulate the behaviour of IE8 >> and Firefox 3, even though those behaviours aren't specced anywhere? > No; it should give whatever it chooses to give as its default behavior. If the META X-UA-COMPATIBLE catches on and many pages start relying on IE8 (or 7) quirks, other UAs may have no choice but implementing "IE8 mode", "IE7 mode" etc.. You have not been terribly good at documenting your quirks in the past (partly natural since some of them are bugs you aren't fully aware of yourselves). Chaos and insane attempts at reverse engineering follows. >>> The alternative is to write the spec in such a way that implementing >>> it does not cause significant breakage. Given that I want to write a >>> spec that describes how to render the content in _all_ of IE's modes >>> -- quirks, today's standards, tomorrow's standards -- > > That spec is not the HTML5 spec, or the CSS 2.1 spec, as they do not > capture all the "idiosyncrasies" of IE6. Granted, implementing anything - even if perfectly according to the spec - likely changes the rendering or behaviour of something out there. Yet, instead of the simple "switch" you propose is it not possible to go through one "idiosyncracy" at a time and see how sites use them and whether solutions can be found? I expect you've done a bit of post-release analysis of the breakage that IE7 caused. For example, I guess that some of the broken sites were caused by fixes in the CSS parser that changed the interpretation of CSS hacks while the layout engine did not fix the issues the CSS hacks worked around. Is that correct? If so, what if you had decided to keep some of the CSS parser bugs alive to keep those CSS hacks targetting IE6 working in IE7? In case you haven't seen this.. http://my.opera.com/hallvors/blog/2008/01/23/suggestions-for-chris-wilson > I do not expect Firefox to replicate our IE6 overflow behavior in > "standards mode" in the future; indeed, I expect there's lots of content > out there already that expects them to follow the spec, whilst > simultaneously that same content probably expects IE to not follow the > spec. This is the core of our problem - single content that expects > different behavior from different browsers today. Some detailed examples from analysis of IE7 problems would probably be interesting - showing how these sites target specific styling or scripting at IE6. The devil is always in the detail.. -- Hallvord R. M. Steen Core QA JavaScript tester, Opera Software http://www.opera.com/ Opera - simply the best Internet experience
Received on Friday, 25 January 2008 16:41:23 UTC