W3C home > Mailing lists > Public > public-html@w3.org > January 2008

Re: Versioning and html[5]

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>
Message-ID: <op.t5hvbvqqa3v5gv@hr-opera.oslo.opera.com>

[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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:29 UTC