It’s just data

Vendor Veto

Shelley Powers recently made a good faith effort to create a Formal Objection; however, to date I have not found a way to treat it as such.  The concern is certainly valid, but we need to find a process for dealing with the issue, and this post is a part of the process for determining the process.

The concern is that Ian made a decision to remove two subsections in his draft HTML5 spec in which codecs would have been required and that such a decision was widely viewed as a decision by the W3C.  It was not, in fact, a decision by the W3C, and as such it is not a subject to a Formal Objection.  But I can’t escape the fact that the perception exists, and is widely held.

Before proceeding, I wish to compliment Ian for making a decision.  This is not a topic with obvious answers.  On one hand, I believe that marketplace should sort out the codecs situation.  On the other hand I do not believe that the current draft contains enough information by itself to ensure interop.

Ian also took the opportunity to provide some insight into his decision making process.  In doing so, he created an impression that Apple had exercised a unilateral veto.  I believe that such an impression is unfortunate, counter-productive, and not in line with my understanding of either W3C or WHATWG processes.  In particular, I actually believe that the accepted goal of the WHATWG was two complete and bug-free implementations in 2022.  I do not believe that Apple’s participation is required to meet that goal.  In particular, I believe that there are at least three implementations today which could form the basis for meeting that goal, with required codecs, namely the browsers produced by Mozilla, Google, and Opera.  Nor do I believe that Ian has talked to anybody who can say with absolute certainty what Apple will or will not support by 2022, as I don’t believe that such a person exists.

That still leaves the matter of the public impression.  I will start by saying that I feel no compelling need to correct the impression at this time.  I believe that the correct way to address the mis-impression that the W3C Working Group has made a decision is to actually make a Working Group decision.  Meanwhile, I am posting this publicly, both on my blog and on public-html.  I harbor no illusion that it will be sufficient to correct the misunderstanding.  If anybody feels so inclined, feel free to refer people to this.

For the Working Group to make a decision, we need something concrete to express an opinion on.  Which means that we need some text, be it some sort of resolution or (my personal preference) some concrete spec text.  My reasons for preferring the latter is that spec text is both more durable and less ambiguous than resolutions.  I’m particularly skeptical about resolutions that take the form of “I think that somebody (other than me) should do the following” in general, and “make the editor do this (against his better judgment)” in particular.

At the present time, we (nominally) have two editors.  This has been a continuing source of controversy, but overall has served us well, at least to get us to this point.  It may, however, very well be the case that this is not the model that will get us to Last Call and beyond.  We now seem to have at least three individuals who have made significant efforts to work within this system, and now feel that producing a document themselves may be a more productive use of their time:

So, ultimately, we may end up this month with four separate specifications.  If this comes to pass, we may need to adopt naming conventions like the IETF’s: draft-author-docname.  If we do so, I am fully confident that the W3C has the technical chops necessary to make this a smooth transition via HTTP redirects.

It is also my experience that such a situation won’t last long.  Some efforts may merge, some may lose interest, and some may never make to the point where they have a first draft ready for consideration.  In fact, we could end up determining that a benevolent dictator is the worst form of government except for all those others that have been tried (with apologies to Sir Winston Churchill).

If, when we get to the point where we are ready to go to Last Call, a number of competing proposals still remain, then we will have a vote.  I fully recognize that a number of people would prefer technical superiority to win out over what they view as mere popularity contests, and these people are certainly encouraged to cast their vote in this manner.  I will simply note that it is quite possible for two intelligent individuals with similar backgrounds and experience can come to different conclusions when presented with the same data.  And we can all name standards that are “technically superior” that few follow.  I, for one, would rather take part in the creation of a standard worthy of loving parody by the likes of Clay Shirky than to produce another such standard.

Returning to Shelley’s objection (even though it may not be end up being recognized as being a Formal one), I beg her indulgence as I would like to see how these various efforts play out in the upcoming weeks.  Should one or more succeed and/or Ian changes his position, I would hope that she would consider voluntarily withdrawing her objection at that time.

Meanwhile I’ve reopened issue 7:video-codecs and opened issue 75:microsoft-review.  I’ll be looking for owners for those two issues.

Related reading: authority, access, policy, support.


It’s true that we could decide Safari is a lost cause and that the spec won’t describe what Safari does. When Mozilla says they won’t implement some other feature that has majority agreement, then we’d also call them a lost cause, because it would be unfair to give Mozilla veto power when we didn’t give it to Apple. And then we would have to decide that Chrome should be a lost cause when they decide that they can disagree with features in the spec without repercussions since everyone else is doing it, and then when Microsoft say they’re not going to implement the parser section, we’ll still be fine, because Opera would still be implementing everything, and after all we only need two implementations to pass to REC, and I’m sure we could find another... Lynx, maybe?

Of course by this point the spec would have no relationship to reality whatsoever, but that’s fine, because the goal is to go to REC, not match reality, right?

Sarcasm aside, when I say that implementors have a veto, I’m not saying this is part of the W3C or WHATWG process. It’s not. The processes don’t claim that anyone has a veto, because claiming that would be politically inconvenient, as is clear from recent discussions. But that’s academic. They have the veto whether we like it or not. It’s not granted to them by the standards organisations; it’s not that I want to give them power over the spec; it’s just that as a simple matter of practicality, the implementors decide whether or not they implement the spec, and if they don’t, then the spec is wrong. This isn’t just browser vendors — conformance checker implementors have the ultimate word on what is conforming, ATs have the ultimate word on what bolt-on accessibility features work (witness HTML4 and axis="" or scope=""), editors have the ultimate word on editor-related conformance requirements (e.g. our "SHOULD default to UTF-8").

There’s two costs to ignoring implementors — one is that it takes the spec further from reality, and the other is that it loses the respect of the implementors, which can in turn mean they go even further from the spec. An extreme example of the latter is XHTML2. The working group didn’t take into account that implementors would have to implement their work, and so the browser vendors ignored it.

Posted by Ian Hickson at

I fear that whatever situation got us to this point wrt video, whether it was Apple or not which caused Ian to remove the paragraphs, we’re at a point of lengthy delays in even getting to a position of reverting what was removed if one can even do that! It’s sad that now an incredible amount of work has to be done to prove that it should be added back.
The pitfalls of not specifying a currently-known-as-royalty-free codec will undermine [link] by allowing implementations to force the spec - because it specs what is de facto - to be non-RF.

Posted by John Drinkwater at

Man, am I glad this isn’t being done in the IETF. No only would you have all the well-publicized disagreements and threats of forks (hi again Rob!), but you would also have people second-guessing what the IETF leadership and the RFC Editor would do. It looks like you are touching on IETFishness with RFC2119 lanaguage that you can’t support (>100 instances of should, some capitalized). The IETF has plenty of half-documented experience with implied vendor vetos, none of it instructive for you.

This is not a criticism, and this is certainly not a suggestion of what you can do better. It really is relief that it isn’t happening with extra layers that could get in the way, and ones that I would likely get dragged into.

Posted by Paul Hoffman at

Man, am I glad this isn’t being done in the IETF.

Fully agree. (hi again Paul!)

Posted by Robert Sayre at

There’s two costs to ignoring implementors — one is that it takes the spec further from reality, and the other is that it loses the respect of the implementors, which can in turn mean they go even further from the spec.

It also alienates implementers who want to implement the edge feature but do not have a specification. There was something which was a lot more used in the past of W3C and that vendors do not use anymore that much. IMHO, It would make a possible resolution: W3C Member Submission.

SVG for example started with such submissions.

Another possibility is Working Group Note explaining that this idead is not yet mature for wide standards agreement but all the technical details of the technology are described in this W3C Foo Note.

Posted by karl dubost at

Sam, the W3C Process doesn’t give you wiggle-room to decide what is and isn’t a FO; that’s the Director’s call (see <[link]>). The way that you treat it as a FO is that you pass it on to the Director when the document advances. Time spent discussing a FO after it’s made is, in my experience, time wasted, unless you can find a way to have it retracted.

I don’t disagree with Paul’s relief that this isn’t happening in the IETF, but process-wise the approach that Ian, and by extension you, are taking is much more realistic there than in the W3C.

W3C’s Process is built from the ground up for consensus, and the combination of Ian’s razor with 500+ WG Members — who were told that they could be part of HTML5 but just discovered they don’t have a say — is going to produce a lot of pissed off people, and more worrisomely devalues the Process, which (for some kinds of work) is very useful as it is.

Posted by Mark Nottingham at

Paul: I’ve tried to use “should” appropriately and consistently lowercase, but if there are any occasions where I got it wrong, please let me know: ian@hixie.ch (or you can mail one of the lists mentioned at the top of the spec).

Mark: The 1000+ people in the WHATWG and the 340+ people in the W3C HTML WG do have a say. Just look at the acknowledgements section. They don’t get to tell Apple or any other implementor what to implement, but they do get to contribute.

karl: In the case of features like SQL, the “veto” gets handled by splitting the controversial feature into its own spec (not done yet for Web SQL, but will be done soon). In the case of features like Theora, there is already a spec, so there’s nothing to split out. The only thing we don’t have in HTML5 is a normative reference to the Theora spec.

Posted by Ian Hickson at

Ian - Sure, understood. However, the W3C Process isn’t really built for this; it doesn’t have the fine distinctions of implementer vs. not, even if in practice there’s a huge difference.

Please don’t read my comment as critical of either Sam or you; in particular I think Sam’s doing a great job in a shitty situation. I am critical of the W3C for performing what amounts to multiple process experiments simultaneously in a high-visibility WG, but that’s their call. Hopefully, the chairs will be able to juggle it to completion.

Posted by Mark Nottingham at

Ian, wouldn’t the analogous spec split in this case be to separate <video> into its own document? That seems pretty similar to Web SQL vs. key/value storage.

Web SQL has an unspecified SQL dialect, while <video> would have unspecified, um, videos. What am I missing?

Posted by Robert Sayre at

Re: “should”. The doc says that you use “should” as specified in RFC 2119. In my brief review of about a dozen random uses in the spec, you don’t say how an implementer can decide when the “should” is not a “must”, as 2119 says you need to. Without that, it is a “may”.

FWIW, RFC 2119 doesn’t differentiate between “should” and "SHOULD": they both follow the same rules. Kinda like the DNS.

In other words, you are doing what many (most?) IETF RFCs do, not what RFC 2119 tells you to do. Welcome to the shlub!

Posted by Paul Hoffman at

[from masaka] Vendor Veto [intertwingly]

For the [HTML5] Working Group to make a decision, we need something concrete to express an opinion on... We now seem to have at least three individuals who have made significant efforts to work within this system, and now feel that producing a...

Excerpt from Delicious/network/myakura at

Vendor Veto: on removal of codecs from <video> and <audio>

submitted by alexeyr [link] [comment]...

Excerpt from programming at

I remember the good old days of style-less and scrip-less Web 1.0 where I made physics papers for.
Everything was fine then.
I still browse in the CLI (sometimes with an imagebuffer attached to see pictures).

Make it so, people. Make it so.

Posted by CLI Bastard at

The problem with “Vendor Veto” is that it ignores the capacity for the specification to induce pressure on the vendor. It is quite obvious to me that sometimes vendors implement standards against their own wishes, because of customer-pressure. For example, how many thousands of people have implemented XML namespaces while thinking that the feature was terribly badly designed? How many have implemented processing instructions while wondering: “What are these for???” How many people have implemented features of ECMAScript that they considered silly or badly designed?  Another example: “On April 28, 2009, Microsoft released Service Pack 2 for Office 2007 which provided users the ability to open and save ODF files.”  Microsoft did not want to support the web at all in the early days: remember “MSN Blackbird"?

Frankly, I agree with Apple that there is no reason for HTML5 to directly refer to Ogg Theora and if other mobile developers feel as Apple does, then that would indicate an insurmountable technical problem. There are many other good arguments for leaving it out.

But one should not hide behind "one vendor, one veto” to justify the removal. It sets a terrible precedent.

The spec’s two jobs are to document what everyone agrees upon and to apply pressure when complete consensus cannot be reached. Of course, the carrot is better than the stick. Furthermore, sticks always suffer from diminishing returns. So it makes no sense to pretend that the opinions of browser vendors are irrelevant. A wise vendor chooses battles carefully.

But it goes way too far to say that every browser vendor has a veto over every feature. That’s outrageous and in contravention of one of the two major purposes of specifications.

Posted by Paul Prescod at

For example, how many thousands of people have implemented XML namespaces while thinking that the feature was terribly badly designed?

I’m not sure that’s a good example to give against the concept of vendor veto. Don’t you wish someone, anyone (vendor or otherwise) had vetoed Namespaces?

Posted by Henri Sivonen at

Ian Hickson said:

It’s true that we could decide Safari is a lost cause and that the spec won’t describe what Safari does. When Mozilla says they won’t implement some other feature that has majority agreement, then we’d also call them a lost cause, because it would be unfair to give Mozilla veto power when we didn’t give it to Apple. And then we would have to decide that Chrome should be a lost cause when they decide that they can disagree with features in the spec without repercussions since everyone else is doing it, and then when Microsoft say they’re not going to implement the parser section, we’ll still be fine, because Opera would still be implementing everything, and after all we only need two implementations to pass to REC, and I’m sure we could find another... Lynx, maybe?

Of course by this point the spec would have no relationship to reality whatsoever, but that’s fine, because the goal is to go to REC, not match reality, right?

This is a slippery slope argument. The conclusion may turn out correct, but the reasoning isn’t.

It also ignores the possibility of working around some browser deficiencies. In fact, for several years a large slab of web-dev has been working around deficiencies in a certain (majority share) browser. Interestingly that same browser-vendor seems much more concerned about implementing standards. Which doesn’t prove anything. 

None of this is to say that Ian Hickson has made a bad call, either now or in the past.

Posted by Sean Hogan at

Survivor: W3C

If the W3C were a TV show, it would be Survivor, without a doubt. With the announcement of the less than graceful retirement of XHTML 2.0, the charitable would say that W3C is consolidating resources. The less charitable would say that in a...

Excerpt from Bb RealTech at

Vendor Veto [On the the HTML5 video codec debacle]

Vendor Veto [On the the HTML5 video codec debacle] : 2 things that I didn’t realize until now: the spec is at the mercy of the implementors. If Mozilla, Apple, etc won’t implement it, it effectively does not exist Working in committees always...

Excerpt from Missives at

HTML 5 is a mess

“HTML 5 is a mess”, said John Allsopp. I agree. It is. It’s also several different kind of messes, not all of which are avoidable or bad. Let’s look at them. The backwards compatibility mess The first kind of mess is because...

Excerpt from Bruce Lawson's personal site at

Disappearing Silverware

It looks like the summary attribute issue is finally well on its way to being closed.  Recent events: John’s position, Ian’s position, Maciej’s mediation, Ian’s acceptance, John’s withdrawal of his draft. One of... [more]

Trackback from Sam Ruby

at

HTML 5 is a mess. Now what?

Lawson explains just why HTML 5 is a mess. And I ponder what we should do about it. Moving forward, compatibly....

Excerpt from Jeffrey Zeldman Presents The Daily Report at

Add your comment