RE: Versioning and html[5]

Ian Hickson [mailto:ian@hixie.ch] wrote:
>> 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.

Umm, you've HEARD of quirksmode, right?

>> 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.

Right.  And the clock is ticking on the point when enough top-200 sites identify themselves as "HTML5" (whatever that means) that it is impossible for us to make breaking changes.  I'm sorry you disagree.  You are asking us to enforce a "level playing field" by bulldozing our own customers.

>> > 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.

Cargo-cult boilerplate.  I like it.  It's a great descriptor for what DOCTYPE is today, and what it will be in the future, even in your world.  I didn't invent it.  I'm not even the only one saying it should be perpetuated, despite how you are trying to paint it - even <!DOCTYPE html> would be cargo-cult boilerplate to get you in "one true standards mode" across all browsers, in your world.  I'm just being a bit more realistic that perhaps HTML5 will not define <canvas> (or whatever complex, hard-to-completely-interoperably-specify feature set you wish to plug in there) for all time, since UAs will invariably ship different details (since we don't all share the same codebase or even underlying OS) and the spec will have to arbitrate later.

>The falacy is that not including the attributes somehow prevents you from
>implementing them.

That's known as proprietary functionality, and we get slapped for implementing it.  <object> was captured in a standard.  It's a real shame to me that you all seem deathly allergic to the <object> tag.  It's still one of the major building blocks of the web.

>> 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?

Yes*, despite you thinking I'm going to say no.  I don't think the way we move away from this model is to punish IE users and developers, even if they did write bad code.  And I'd hoped you'd take my input into this nascent standard as experience that might be useful, and not simply as wrangling.

*Except, of course, for the interaction with binary platform-specific components (ActiveX, NS plugins, XPCom objects, etc.)

>> > 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.

Well, then that's a great place for us to start.

>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 can't tell exactly why, simply from this thread, where our difference in intuition comes from.  I can't tell if you're implying that Microsoft (or anyone) would _purposefully_ implement the spec not as written and then not want to change it - I'll rule that out for the moment as evil and expect you're not claiming that I'm evil, or as you misunderstanding something I've said to mean that I think we would (purposefully mis-implement).

So, we're down to incompetence - oh, wait, except that there's also the realities of shipping.  We have to ship at roughly a given date.  It's possible we don't find a bug or spec mis-compliance until late in the cycle, at the point where the bar for changes to the release is extremely high.  It's possible, as I said before, that the spec just doesn't state COMPLETELY what the implementation must do, in all possible combinations with other features.

And then, of course, once we've shipped and been out there in the market for a year, how many hundreds/thousands/millions of users will be affected when we change it?

>> >> 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.

Simply not true.  I would say Google chooses to not do that.  Great, I don't blame them.  I wouldn't go after that market either.  Google Docs, on the other hand, hits the sweet spot for a tremendous number of people.  Some would claim that sweet spot will, over time, become much more important than the Word one.

I would claim the same happens to the web platform.  IE-specificity will rot away.  It's already started.  I'm all for that, believe or not.  I can't responsibly hurry it along, because I will do so at the expense of my own users and web developers who DID code for IE.  You do understand why that particular arrangement - punishing IE users and web developers - would be bad business, right?

>> 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.

Huh?

No, I've said (I think) that browsers won't get it perfectly right the first time.  I'd love to exactly implement the spec.  I think you will turn up loose areas of the spec and corner cases after implementations have shipped.  Size of user base matters in agility (as measured by ability to change behavior on your users).

>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?

I'm sorry, I don't think I ever said browsers shouldn't implement the spec.  If so, please point me at it so I can correct that statement specifically.

>> Not true.  <table> and <form> are still occasionally interleaved.
>
>The HTML5 parser spec handles this case, even with a tree structure.

It's not possible to "handle" this case - that is, have the same behavior IE4 has - without a non-strict-tree structure somewhere.  Maybe it's in your form topology rather than your tree - I'm not sure why that's better.

-C

Received on Monday, 16 April 2007 19:56:04 UTC