RE: Versioning and html[5]

On Fri, 13 Apr 2007, Chris Wilson wrote:
> > 
> > The current spec is not finished, correct. I would hope that when it 
> > is finished it is strictly compatible with legacy content that works 
> > in IE7 (as a superset in some areas and probably a subset in others -- 
> > e.g. I would't plan on describing HTML+Time or the binary-level APIs 
> > of ActiveX, and at the same time, we do plan on adding new features).
> 
> OK.  If you don't describe HTML+TIME, then you're not strictly 
> compatible with what IE7 supports today.

By "compatible" I don't mean "an exact description of". And I'm not 
interested in being compatible with IE7, I'm interested in being 
compatible with the content that assumes IE7. There's a big difference. 
For example, there are only some 30 sites on the Web that use <t:video> 
[1], and most of those are sample pages, so other browsers don't have to 
support <t:video>; interoperability isn't required for <t:video>. Thus the 
spec doesn't have to define how it works. (I'm not saying you should drop 
support for it, or that the spec should disallow you to support it.)

The spec I'm saying we need (and that the WHATWG has been working towards, 
though the work is far from complete) would not cover *everything* IE7 
does, and it would cover things that IE7 *doesn't* do, but for what it 
*does* cover, it would be specified in such a way that if implemented 
exactly as specced, legacy content would be handled as expected by the 
original author.

[1] Based on a study of several billion pages covering millions of sites, 
done in March 2007.


> > You misunderstand. I mean, if you implement the spec without 
> > versioning and find something breaks the Web, then we should change 
> > the spec. To know when something breaks the Web, you have to tell us. 
> > To tell us, you have to know. To know, you have to implement it 
> > without versioning. Then, *before* you ship with that change, we fix 
> > the spec and you fix the implementation so that the spec and the 
> > implementation are both compatible with legacy content. Thus, you can 
> > implement the spec, without versioning, and not break any legacy 
> > content.
> 
> We cannot "fix the implementation" after we've shipped it once.

Please reread the paragraph I wrote. I clearly stated that these would be 
changes *before* shipping.


On Fri, 13 Apr 2007, Chris Wilson wrote:
> >>
> >> versioning will still tell you that your browser isn't new enough to
> >> handle, say, that 3d canvas element that gets added in html6.
> >
> > I don't understand this. Could you elaborate with an example?
> 
> We're running on the presumption that everyone will always have the 
> latest browser.  That's not true.  It would be useful for IE to be able 
> to identify, for example, that we are unlikely to be able to handle 
> canvas content.

I don't understand your example. Wouldn't it be better to simply have the 
browser do graceful fallback? (That's how <canvas> is designed to work.)

What do you expect the user experience to be for what you describe?


> Hmm.  No, I'm saying ("we" means Microsoft in this list):
>
> 1) for compatibility reasons, we will have to freeze bugs in place in 
> default behavior.
>
> 2) because I want to move the implemented platform forward, of course we 
> will fix bugs and add features - but they will have to be under an 
> opt-in switch.

I understand this so far. I don't think it's the right thing to do, but 
that's not the point. I understand that you think it is right and why you 
think it is right.


> 3) Whenever a new HTML version is "shipped," we can automatically say 
> for that version, we'll mask out all our old crappy behavior (that you 
> used to have to put an opt-in in every document to avoid).

I don't understand why you think steps 1 and 2 have any bearing on the 
version of the HTML spec. Imagine if we weren't doing HTML5 -- surely 
you'd still have to do versionning, right? Are you suggesting that in the 
entire time before HTML5 is finished (at least a decade or more -- 
consider that HTML4 still hasn't reached the level of interoperability 
that we are aiming for with HTML5, so we know that it will take at least a 
decade), you will only freeze bugs once?

Surely you cannot promise that.

What would you do if you need a new opt-in switch before HTML6 is started?


> >If you want the W3C spec to have a version switch, then the spec must 
> >define how browsers must act *in all the versions that the switch 
> >supports*. That means that if you want a switch (or the lack of a 
> >switch) to imply that IE7 behaviour must happen, *we absolutely must 
> >specify exactly what IE7 does* so that other browsers can implement it 
> >too.
> 
> That sounds like you want to be on the "suggest features to IE and then 
> document what they implement path," then.

We're currently on a path of "spec feature, get implementation experience, 
fix spec to match implementation experience, iterate", which as far as I 
can tell is the same thing (though not necessarily only with IE).

Yes, I am suggesting that.


> >Maybe it would help, however, if instead of assuming that compliance to 
> >HTML5 will mean broken pages, we worked on the assumption that 
> >implementing HTML5 correctly will mean all pages work. That's what the 
> >other browser vendors want, it's what the WHATWG set out to do three 
> >years ago and has been doing ever since, it's what authors want.
> 
> You could start, then, by not ripping out the pieces we rely on, like 
> classid and codebase.

This is a fallacy, as discussed here:

   http://lists.w3.org/Archives/Public/public-html/2007Apr/0632.html


> "All pages" include pages that exist today that are designed for IE, and 
> explicitly, to us, it includes pages that rely on IE-isms like ActiveX, 
> scrollbar-color, and HTML+TIME (which is a profile of SMIL, BTW, it's 
> not some random proprietary thing we invented).

Pages that use a *superset* of the features defined in the spec are not a 
problem, since the spec isn't incompatible with them, it just doesn't 
describe how to handle them.


> >Where HTML5 does break pages, we need to fix the spec. If this means 
> >getElementById() changes to look for 'name' attributes, sobeit.
> 
> I think that's a mistake, but okay.

You think it's a mistake to make the spec be such that implementing the 
spec is all that is needed to handle existing content?

That is, you think that browsers actually *should* have to implement 
something that is incompatible with the spec in order to render legacy 
content?

If this is really what you think, what do you think the point of the spec 
is? Just a guide or influence?


> >Sometimes it may be that IE's behaviour *can* change because few enough 
> >pages depend on some edge case that it's ok to change it.
> 
> I'm saying the default answer to that question is no.  We have a 
> different set of constraints.

I agree that the default answer should be "no".


> I'm happy to have competition in the browser space.

You are proposing a path that will lead to it being nearly impossible to 
compete in this space, very similar to the path that has led to it being 
nearly impossible to compete in the word processing space.


> If you want to do this, I'm happy to provide resources to help you 
> investigate why IE does anything that it does, so that you can write a 
> spec that matches precisely that.

Great!


> I'm not really convinced that's the best basis for an HTML specification 
> that will stand the test of time - it seems like you're working toward a 
> world where instead of just swearing at IE's wackiness, web developers 
> will swear at the wackiness of the spec and everyone's implementation.

Authors want consistency across implementations more than they want an 
ideal spec that isn't implemented anywhere.



If you need versionning, then I would request that you use a versionning 
flag that isn't part of the language. You could have an attribute such as 
has been proposed:

   <html tested-on="2008-02-10">

...which gives the date that the content was written on, with the 
assumption it was written to the latest browsers. Then your browser would 
look at the date, and see which range it fell in relative to when your 
rendering engine bugs were frozen. So for instance if IE8 was frozen on
2007-11-20, and IE9 in 2008-05-05, then IE10, looking at the markup above, 
would know to use the IE8 rendering engine for this content. This would 
allow other browsers to do this as well if they wanted.

I still think it's a horrifically bad idea, though.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 13 April 2007 22:44:50 UTC