RE: Versioning and html[5]

On Sat, 14 Apr 2007, Chris Wilson wrote:
> 
> Asking: Please don't think that because you want every version of HTML 
> after HTML5 to be completely backward compatible with HTML5 that you 
> should just drop a version number altogether.  Hedge your bets, consider 
> it insurance, and say <!DOCTYPE html PUBLIC "html5">.

Well, "<!DOCTYPE html>" is as unique as "<!DOCTYPE html PUBLIC "html5">", 
so it doesn't actually make it any harder to change the version number 
with the next release anyway. If we find that you are indeed right and 
we somehow need something in HTML6 that distinguishes it from other 
versions, we can do that -- but that can happen in HTML6, it doesn't have 
to happen in HTML5.


> It's really not a big deal right now.  But in HTML6, when it turns out 
> we forgot to normatively specify some behavior in IE5, and Firefox and 
> IE do it differently, we're not going to break that behavior - meaning 
> knowing that we're looking at HTML6 will be a good thing.

We've never, up to this point, needed to know what version we were looking 
at, and even now 17 years into the Web's development, Microsoft are the 
only vendor saying that there is a need. So it's not clear to me that it 
would be a good thing. In fact I'm rather of the opposite opinion. Thus, I 
disagree with your conclusion.


> I don't believe HTML5 will take a decade to start being deployed.  It's 
> not when the standard gets turned into a Recommendation that matters to 
> compatibility, it's when the content starts being deployed.

Ah. Well then we've already started seeing HTML5 get deployed.


> > What would you do if you need a new opt-in switch before HTML6 is 
> > started?
> 
> Add one.  But when people started deploying HTML6, I'd want it to be 
> automatically opted in.

So you're saying you want authors to be forced, through the use of 
cargo-cult boilerplate, to trigger new rendering behaviour in your 
browser.


> >> 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
> 
> No, I disagree with you.  ActiveX can be implemented on other platforms 
> (I believe Mac IE5 had an implementation), and embed is the moral 
> equivalent anyway (I note the explicit reference in HTML5 to the 
> Netscape Plug-in model - nice!).  codebase I believe we do misuse - it's 
> a URI, but not as stated - but classid I don't think we do, we just 
> invented a URL type of "classid:" for it.

The falacy is that not including the attributes somehow prevents you from 
implementing them. However, we can always specify them in the spec, I've 
nothing against doing that.


> I don't think it's possible to have ONE spec that specifies how to 
> handle ALL content on the web today.  Some requires IE.  Some requires 
> Firefox.  In this case, you need to choose.

Do you think we should move away from this model?


> > That is, you think that browsers actually *should* have to implement 
> > something that is incompatible with the spec in order to render legacy 
> > content?
> 
> Yeah, pretty much.
>
> > If this is really what you think, what do you think the point of the 
> > spec is? Just a guide or influence?
> 
> Hmm.  Guide?  Determination of how to do it right, that we all converge 
> on?

Wow. We have fundamentally different goals here then. I'm not sure they're 
even compatible.

What I want, what I believe most of the WHATWG community want, is a 
specification which Web browsers can implement exactly. The idea that a 
browser vendor would specifically _not_ implement it exactly as written, 
and not ask for the spec to be changed if they couldn't implement it 
exactly as written, is diametrically opposed to my goals.


> >> 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.
> 
> Wow, I simply disagree with that statement.  So does your employer, as 
> they have a competing word processor to Microsoft Word.

I understand that you disagree. I assure you that my statements are based 
directly on Google's experience in this space. I wouldn't even remotely 
characterise Google Docs as competing with Microsoft Word; indeed, trying 
to compete with Word is, because of the format issues alone, too expensive 
even for us.

Please don't bring this world to HTML. Quirks vs Standards is a bad enough 
mess; browser vendors shouldn't have to go through the hell of multiple 
versions the way groups like OpenOffice have.


> > Authors want consistency across implementations more than they want an 
> > ideal spec that isn't implemented anywhere.
> 
> I'd think we could give them a third option - an ideal spec that all 
> implementations converge on.

But you have explicitly said that you don't think browsers should exactly 
implement the spec. What do you mean by "converge on" if you don't mean 
"implement"? And if you don't mean that the browsers should implement the 
spec, how would this differ from the option that I said authors _didn't_ 
want, namely an ideal spec that isn't implemented?

It really sounds to me like your third option is exactly the same as the 
second option I listed, which most authors explicitly don't want.


> Lachlan wrote:
> > But in the case of, say, IE's broken DOM, I seriously doubt that there 
> > are any sites that absolutely depend on the non-tree structure of IE's 
> > DOM in certain cases.
> 
> Not true.  <table> and <form> are still occasionally interleaved.

The HTML5 parser spec handles this case, even with a tree structure.

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

Received on Sunday, 15 April 2007 02:52:22 UTC