Re: Versioning and html[5]

Hi Chris,

Thanks for writing such a detailed essay expounding Microsoft's point  
of view on this. To respond properly will probably require some  
mulling over and a lengthy reply, but I wanted to touch on a few  
minor points.

On Apr 12, 2007, at 9:40 AM, Chris Wilson wrote:
> Microsoft has always firmly backed compatibility – in its formats  
> (e.g. Office formats), operating systems (Win32 APIs), and browsers.
It's worth noting that Microsoft's approach to compatibility is not  
the only one that works. Apple has pretty strong commitments to  
compatibility, but a Mac OS X system of today will not be able to run  
68k System 7 app. The period in which the evolutionary compat  
breakage was one in which Apple gained market share rather than  
losing it. And making something of a break with the past (while still  
providing "mostly compatible" APIs and a transition strategy) is  
widely credited with enabling the security, usability and rapid  
innovation of Mac OS X.


> I note, for example, that the WHATWG HTML5 removes a few key  
> attributes from the <object> element that were in HTML 4.01 –  
> namely, classid and codebase – that are heavily used by ActiveX in  
> IE.  (And y’all seem to get quite upset when we add proprietary  
> features and attributes.)
As others have mentioned, the fact that these aren't specified would  
not render IE non-conformant if it continued to support them.  
Furthermore, HTML 4.01 defines them in a way that is contrary to how  
they work in IE, so omitting them from the spec is probably better.


> This DOES NOT (in my opinion) give us (the WG) the license to break  
> compatibility with current standards like HTML 4.01 – like XHTML 2  
> did, or even like XHTML 1.1 – unless that standard does not  
> represent current practice in browsers, in which case we have a  
> decision to make.  In fact, Maciej (in a private mail exchange with  
> me) said: “The problem with versioning is that it encourages  
> breaking of existing content in new specs, so you either have to  
> ignore the spec or build a mode switch.”  I understand why you  
> might say that – the temptation might be there – but we’ll have to  
> hold the line against that “encouragement”.  I don’t want to break  
> backward compatibility in the spec; that is separate, to me, from  
> backward compatibility in implementation.
You've suggested yourself that you'd prefer that spec not try to  
define certain IE behaviors that web content relies on, so you have  
already fallen prey to this temptation.

> As for the details of version, I have to object strongly to the  
> idea that the DOCTYPE for HTML5 should just be:
>
> <!DOCTYPE html>
[...]

>  In short, I’m not that positive that HTML 5 will be the time we  
> get it right for all time.  I would suggest that we use
>
> <!DOCTYPE html5>
As mentioned elsewhere, this is not workable because it will trigger  
the quirks mode of current versions of Safari and Firefox (adding up  
to around 20% of browser use share and growing). If HTML6 needs to  
add a version switch, it could do:

<!DOCTYPE html>
<html version=6>...

But I would oppose adding version=5 as a requirement to the current  
spec, because that prejudges the issue of whether HTML6 will need a  
new version. Not having an explicit mention of the version in HTML5  
leaves this issue to be addressed at the time HTM6 comes out, where  
surely a more informed decision can be made.

On Apr 12, 2007, at 2:59 PM, Chris Wilson wrote:
> No.  But until the actual deployment of the new doctype reaches any  
> critical mass (e.g. if it's <0.5% of the web, as "standards mode"  
> was when we released IE6), we can change behavior without  
> significant risk of breaking actual content on the web.

So you'd be willing to break compatibility with content using a new  
doctype as long as the deployment of that doctype is less than 0.5%  
of the web. Great! How about breaking less than half the content  
shipped with a doctype that is 1% of the web? Or less than 0.5% of  
the content of 100% of the web? These all seem like they would have  
the same scope of effect on users and web developers, so if you are  
willing to do the first, you should be willing to do either of the  
other two.

And I think 0.5% of web content is a ballpark figure that developers  
of other browsers could probably agree on. Personally I think it's a  
little high, we should aim to break less content than that. And we  
should factor in popularity of sites as well as sheer number. But it  
seems like a good starting point.


The next item is something of a red herring, since it is a CSS example:

On Apr 12, 2007, at 3:32 PM, Chris Wilson wrote:
>>> In short, no, because I don't think half the web misuses floating  
>>> - but
>>> let's say 1% of the web does misuse float - that's a significant
>>> blocking problem for us,
>>
>> I presume that it is a serious blocking problem for other browser  
>> vendors
>> too.
>
> No, I think they've successfully ignored that compatibility problem.

You'd be wrong to assume that other browser vendors would ignore a  
problem that breaks 1% of the web. We'd consider any such problems  
extremely serious. But for Safari/WebKit at least, we are not getting  
the big stream of incoming float bugs that would be expected if our  
more correct handling of floats broke 1% of the web.

My guess on why IE might be in more of a pickle is that people have  
come to depend on some IE bugs / limitations (often selectors hacks,  
let's call them type H) to work around other IE bugs / limitations  
that are actually affecting their content C. Fixing such things in  
the wrong order in the face of etrenched content leads to trouble.  
You can't fix a type H bug if there might be widely used workarounds  
to class C bugs that depend on it.

Regards,
Maicje

Received on Friday, 13 April 2007 08:49:40 UTC