- From: Shelley Powers <shelley.just@gmail.com>
- Date: Wed, 8 Jul 2009 07:28:16 -0500
- 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