W3C home > Mailing lists > Public > public-html@w3.org > July 2009

formal objection to one vendor/one vote

From: Shelley Powers <shelley.just@gmail.com>
Date: Wed, 8 Jul 2009 07:28:16 -0500
Message-ID: <643cc0270907080528o5fadd978qbd3209912dfb5350@mail.gmail.com>
To: HTMLWG WG <public-html@w3.org>
Sorry, I had posted this to the wrong place. Re-posting here. I've
also taken the liberty of copying over a couple of emails that
followed this posting

-------------

I believe the process to register a formal objection is to send an
email to this group, and label it as such. If there's another group I
should contact, please let me know.

---------

I'm quite concerned about what is happening with the HTML 5
specification, particularly in regards to the "one vendor, one veto"
that we're seeing with Video, and which we'll potentially see with
SVG, MathML, the Canvas element, the accessibility markup, and so on.

In the public-html email list, Robin Berjon wrote [1]

"At this point I'm only aware of one browser vendor having said they
wouldn't do this. Am I wrong? Since when does a single vendor get a
veto?"

I wrote in a follow-up note [2]

'Robin hit on what I think is the most important point on this
decision: it gives veto power to a single company. That is a dangerous
precedent to create.

What if Microsoft were to come along and say, "We're not going to
implement SVG". Do we then pull the SVG section?'

Ian Hickson responded with [3]

"Unless the W3C gains some kind of enforcement power, the implementors
will  _always_ have the ultimate veto, swayed only by their desire to
gain
market share. Implementors have the ultimate veto on any
implementation requirements we put in our specs not because we allow
them to, but because in every literal sense if they don't want to do
what we tell them to do, then they don't have to.

Specification authors -- the W3C, the IETF, the WHATWG, you, me --
have _zero power_ to enforce implementors to do what we put in our
specs. We only get what we write to be implemented if what we write is
what implementors are willing to implement. (This is why I work so
closely with browser vendors and other implementors to find out what
they want.)

We could put Theora into the spec, but then the spec would not be the
description of reality that I set out to make it when we started
HTML5.


> At this point we have multiple implementations of a feature that has
> strong backing in the community, and that we have no reason to believe
> isn't interoperable. That's reality. I'm all for listening to vendors,
> but once in a while they'll get something wrong and change their minds.

I'm happy to change the spec when that happens.

> If Theory really does not fly in the end, then there's plenty of time to
> remove it later. But at this point it is premature and unrealistic to
> remove it.

I didn't remove it recently. It hasn't been in the spec for over a
year now, if I'm not mistaken.

On Tue, 7 Jul 2009, Shelley Powers wrote:
>
> Robin hit on what I think is the most important point on this decision:
> it gives veto power to a single company. That is a dangerous precedent
> to create.

The relevant implementors have veto power over the parts they are
intended to implement whether we like it or not.


> What if Microsoft were to come along and say, "We're not going to
> implement SVG". Do we then pull the SVG section?

Not immediately, but if we can't convince them that SVG is the way
forward, then yes."

--end quote

Just to confirm, I asked Ian one last time to confirm one vendor/one veto [4]

"I wanted to clarify that you're using a one vendor/one veto approach
to determining what goes in, or doesn't go into, HTML 5.

I don't believe many of us were aware that any one vendor among the
larger browser companies had absolute veto power over the HTML 5 and
its contents.

I'm assuming that the companies that have this veto power are Apple
(Webkit), Microsoft, Opera, Google, and Mozilla. Do I have that right,
or are their other vendors with this absolute veto power?"

Ian responded with a link to an email in the WhatWG email list [5],
which contained the following (repeated in its entirety to prevent
misrepresentation):

--begin quote

On Mon, 6 Jul 2009, Kartikaya Gupta wrote:
>
> Seriously? If I were to declare that I, as a browser vendor, will not
> support anything in HTML5 that wasn't in HTML4, would you actually
> remove all the new additions from the HTML5 spec?

Not immediately, but if you had notable market share and we could not
convince you to implement these new features, then yes, I'd remove
them and then work with you (and everyone else) to try to come up with
solutions that you _would_ agree to.

Even if you did not have notable market share, I would work with you
to understand your objections, and try to resolve them. (Naturally if
your goals are substantially different than the WHATWG's goals, then
this might not go anywhere. For example, if Microsoft said that we
should abandon HTML in favour of Silverlight, without making
Silverlight backwards- compatible with HTML, then this would be
somewhat of a non-starter, since backwards-compatibility is an
underpinning of our work.)


> I'm not talking about the direction of the Web. I'm talking about the
> text that resides at http://www.whatwg.org/specs/web-apps/current-work/.
> The two are not the same thing.

If they're not one and the same, then I'm not doing my job.


> So let me re-ask my question: if a browser vendor has an installed base
> of greater than "a percent or so", and they flat-out state they will not
> implement, e.g. all the new <input> types in HTML5, will you take them
> out of the spec?

Yes.


> If the answer is yes, I would like specifics as to where that "percent
> or so" number comes from. There's lots of different ways people use to
> measure market share, which one are you using?

I haven't needed to exclude a browser vendor before, so this hasn't
come up. In practice, it's any browser vendor that has enough
influence that if
they fail to implement something, it'll affect broad deployment of the
feature. Generally speaking, that would be the browsers that are
important
enough for sites like Wikipedia to include in their reports, e.g. on:

  http://en.wikipedia.org/wiki/Usage_share_of_web_browsers

...but again, so far I've not had to decline the feedback of any
browser vendor, including a number that were much smaller than those
on that page.

--end quote

The Wikipedia article references the browsers IE, Firefox, Safari,
Opera, and Chrome, reflecting the companies Microsoft, Apple, Mozilla,
Google, and Opera--with Microsoft having the greatest impact.


There has always been a chicken and egg approach to web standards
development, but there is such a thing as determining a course to take
that has at least significant support and hope to, over time, convince
reluctant parties to join in. This approach was the only way that we
can hope to progress in the future beyond the limited web environment
we had yesterday, and have today.

If we continue to allow one vendor/one veto to be the underlying
philosophy of the HTML WG, then we might as well end working on it at
this point, because I can't see it being anything more than a race to
the bottom, with each vendor looking to cripple open web development
in favor of its own proprietary effort.

Worse, this process completely and totally disregards the community of
users, of web developers, web designers, accessibility experts, and
gives ultimate power to five companies: Google, Apple, Microsoft,
Mozilla, and Opera--with Microsoft having the largest veto power. The
rest of us might as well go home, because we have no say, no input,
nothing of value to add to the future of the web. Not unless we crawl
on bent knee to each vendor and ask them, "Please sir, I want some
more."

I would rather think that this decision wasn't with the concurrence of
the W3C. I would rather think this decision to support one vendor/one
veto was a misunderstanding coming about because of the dual
organization nature of the groups developing HTML 5.

Therefore, I am formally objecting to the the concept of one
vendor/one veto that is underlying the decision processes about what
to include, or not include, in HTML 5.

At one point in time, I believe, the W3C operated with a philosophy
that if it had implementation, or promise of implementation, from
three vendors (three being the majority), that would be sufficient.

A commitment from three vendors would allow the specification to
advance, and provide enough support to hopefully put pressure on the
recalcitrant companies to implement the specification.

Only requiring a commitment from three vendors would also ensure that
no one company would have such a veto power again. This would allow
the web to advance, and not be hindered by proprietary interests. A
three vendor commitment would also give the user community a chance to
have some influence in the future of the web. Not an unreasonable
influence, resulting in decisions that would make it difficult for all
vendors to comply. Enough influence, though, that the web of the
future would be the web for everyone, not just one small group of
browser vendors.

Thank you

Shelley Powers


[1] http://lists.w3.org/Archives/Public/public-html/2009Jul/0235.html
[2] http://lists.w3.org/Archives/Public/public-html/2009Jul/0242.html
[3] http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html
[4] http://lists.w3.org/Archives/Public/public-html/2009Jul/0265.html
[5] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020804.html


---------

An email exchange between I and Sam Ruby:

Sam Ruby wrote:
> Shelley Powers wrote:
>> I believe the process to register a formal objection is to send an
>> email to this group, and label it as such. If there's another group I
>> should contact, please let me know.
>
> I'll check into the process (and am copying Mike and Dan as they are
> the W3C team contacts for this working group, but meanwhile three things:
>
> 1) This Mailing list is described as a "Miscellaneous.  Mail-to-web
> gateway" on http://lists.w3.org/.  My understanding is that its
> primary purpose is to allow a public URI to be associated with an
> email that is sent.  As a general rule, it is a great resource for
> taking discussions "off-line" which may later need to be referred to.
> In any case, I have seen this email, and will take it seriously.

Oops, then this is definitely the wrong place for this.

I'll resend to the HTML WG list, then.

>
> 2) The document in question is merely a Working Draft at this point
> which means that it may be unstable and may not meet all of the
> Working Group's needs at this point.  As such, a formal objection
> seems a bit premature, but only by a little bit as it makes perfect
> sense to me for Formal Objections to block advancement to Last Call.
I'm not sure how we can move to Last Call.

Right now, we have no commitment one way or another from Microsoft on
most aspects of HTML 5. According to Ian, Microsoft has the strongest
veto of all. If it were to come in and just make a statement -- no
we're not supporting Canvas, or MathML, or SVG, or any number of other
elements--, just a statement of fact, then supposedly, *poof*, they're
gone.

Why call this HTML 5? We might as well call it the Sword of Damocles
HTML and be done with it.

As it is, we've already run into one vendor/one veto with the video
element. Oh, and that's another one that MS has not made a commitment
about.

>
> 3) I need to think more about what it means to have a formal objection
> to process as opposed to a result.  Formal objections to results, like
> a document which contain features like video which do not lead to
> interoperability due to a lack of specifying a common royalty-free
> codec: that is something I can get my head around.  A formal objection
> to removing Canvas (I chose Canvas as that is an item that the working
> group previously voted on and decided to include) in the unlikely
> event that Microsoft makes a statement that they will never support
> such a feature -- that too, I can understand.  But a Formal Objection
> to something that not only hasn't happened, but may never happen --
> that is something I need to ponder on further and consult with others.
>
I understand I'm not following procedures. Sorry about that. But it
doesn't lessen my concerns.

Do we assume, then, that the one vendor/one veto rule only applies
when a company specifically states it will not support something?
Shouldn't it also apply when a company doesn't say whether they will
or won't support one aspect of the document or not?

If the purpose behind this one vendor/one veto approach is to ensure
we no longer have what we had in the past, the inability to use all of
the available web technology because of lack of support among one or
more browsers, then unless the five vendor companies specifically
state they will support each element, or concept, documented in HTML
5, we should
immediately seek to remove it now--rather than wait until some later
time when we finally have to corner each and ask, "Well, will you or
won't you?"

I focused on SVG, MathML, Canvas in the objection, but there's a more
serious item that was brought up in my comments last night: the XML
serialization of HTML 5. It is very much at risk, because we have no
commitment from one company to support XHTML 5. And with one
vendor/one vote, that means we can kiss it good-bye, too.

We can't depend on anything now. Oh, a few scraps tossed us, some new
goodies like client side storage. You know, to keep the kiddies
entertained.

I take things that people tell me as truth. Ian has stated one
vendor/one vote. Not saying anything about canvas, SVG, XHTML, MathML,
etc., is a vote. It's a vote saying, "No". Ignoring the great hulking
elephant in the corner while professing to adhere to consistent
procedures is not something I'm particularly good at.

Sorry, Sam. I am new to this, and most likely not following proper
procedures. But there is more than a hint of lack of consistency to
the procedures followed with HTML 5, so in a way, I'm only following
the course others have set.

Shelley




> - Sam Ruby
>
>
Received on Wednesday, 8 July 2009 12:28:59 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:47 UTC