Re: HTML version issue summary?

Matthew Raymond schrieb:
> Dão Gottwald wrote:
>> Matthew Raymond schrieb:
>>> Jeff Schiller wrote:
>>>> I guess the theory here is that Microsoft has the farthest to go to
>>>> "get it right"?  Therefore, in the first version of IE that supports
>>>> any form of HTML5, the web authors better _really_ be sure that they
>>>> want to trigger HTML5 processing in IE (above and beyond the standard
>>>> DOCTYPE/version attribute mechanism)?
>>>    If support for HTML5 is so bad in IE that HTML 4.01 rendering is
>>> preferable, I think most people would rather use HTML 4.01. However, I
>>> just don't envision a scenario where IE's handling of HTML5 is so bad
>>> that you want IE to treat compliant HTML5 documents as HTML 4.01.
>> You could use the proprietary opt-in then.
>> Thing is, IE.next will handle HTML5 documents significantly worse than 
>> IE.next+1.
> 
>    That doesn't mean that fallback to HTML 4.01 in IE.Next is better
> than HTML5 support in IE.Next.

It's better for those who depend on various bugs in IE's rendering 
modes, possibly without knowing it.

>> If IE.next uses the HTML5 doctype as an opt-in, that will
>> render that doctype useless for IE.next+1 as a trigger for real 
>> standards rendering. That's similar to the current situation. We want to 
>> avoid that.
> 
>    Exactly. So long as Microsoft is using doctypes and versions to do
> the switching on, the spec is nothing more than a set of guidelines for
> them, because as soon as another version comes out, the bugs for the
> previous version are locked in forever.

That's why I want them to do not more than one more switch, namely on 
<!DOCTYPE html>. The initial implementation for that mode must not be 
broken.

> We need to do what we can to
> encourage the use of explicit switches for bug compatibility and allow
> standards-compliant markup to receive the best possible treatment the
> any particular version of their browser can provide.

That won't work as long as IE is too extensively broken. Too many sites 
depend too deeply on its bugs, and many of them won't bother opting into 
bug-frozen modes. It's out of question that Microsoft won't break those 
kind of sites.

>>> It
>>> would be market share suicide. Think about it: Why would anyone depend
>>> on a product from a company that can't support standards even when their
>>> head browser developer is the chair of the working group that developed
>>> the standard in question?
>> Um.
>> 1. Nobody wants Microsoft to not support standards. We want them to do
>>     it in a sane, future-proof way.
>> 2. You're ignoring that Dave proposed to support opt-ins to the new but
>>     not yet finished rendering mode.
> 
>    I was my understanding that Dave was proposing that IE.Next use HTML
> 4.01 rendering for HTML5 if there wasn't an explicit IE-proprietary
> opt-in switch. I fail to see how that's future-proof, since that switch
> will be tied to bug compatibility with that version, and removing it for
> the IE.Next+1 would mean cutting off legacy IE users.

It's future-proof as there's a clear migration path to <!DOCTYPE html>, 
without any more opt-ins.
Legacy IE versions with broken rendering engines are unable to render 
standards-compliant sites correctly. True. There's no way to avoid that.

>> 3. People did depend on broken IE versions for years. Go figure.
> 
>    The |bugmode| attribute would solve this problem. You insert one
> little attribute and the pages works in every browser that supports that
> bug compatibility mode for all time. Authors could add |bugmode| to
> their markup preemptively, and the fallback for user agents that don't
> support the mode you specify would be the best available standards-based
> rendering.

As stated above, "[...] many of them won't bother opting into bug-frozen 
modes."

--Dao

Received on Thursday, 26 April 2007 07:51:15 UTC