- From: Michael(tm) Smith <mike@w3.org>
- Date: Fri, 26 Jun 2009 02:21:12 +0900
- To: Shelley Powers <shelleyp@burningbird.net>
- Cc: Sam Ruby <rubys@intertwingly.net>, www-archive@w3.org
Shelley Powers <shelleyp@burningbird.net>, 2009-06-25 10:29 -0500: > The inherent problem with this approach, Mike, is that in the meantime text > exists uncontested within the HTML 5 specification draft, There is text that is contested -- including text that is contested by implementors. One case is the section of the spec that covered client-side SQL database storage. Mozilla made it known that they were not going to implement it, despite it being in the spec. No part of the spec that isn't either descriptively (as opposed to prescriptively) describing actual existing application behavior or that hasn't been implemented across multiple UAs can be considered uncontested. > being implemented by user agents We have no power or authority to prevent any UA vendor from choosing to implement any part of any draft that they choose to implement. (Though we do have disclaimers on all our drafts telling implementors that the specs are subject to change.) >, with the HTML WG's concurrence and outright support. The existence of the current HTML5 draft as a W3C WD does not imply the HTML WGs concurrence and outright support for all parts of the spec. And vendors are not choosing to implement parts of the spec because they assume the HTML WG has OK'ed them. > Consensus should be sought _before_ text goes into the draft, not > afterwards, That is one way to produce drafts, but not the only way. Sam has written about that previously. There are projects and organizations that do not follow a policy of requiring that consensus be sought before changes are made, and they have been successful in getting things done under that policy. > when chances are any ability to effect change will be lost. I will fully agree that once a particular feature gets implemented across multiple UAs, the chances of it being possible to get changes to the specification for that feature go way down. But UA vendors are not implementing features simply because they are in any draft spec. In fact, there are cases where it's almost the opposite; that is, there are cases of features being added because one or more UA vendors are going to implement whether we have a spec for them or not. That was the case, for example, for the Web Workers spec coming into existence. The priorities of UA vendors are mostly driven by market needs. Speaking as someone who has worked for two different browser vendors, I have to say I think a lot of people looking at things from the outside vastly overestimate the power that this group or any standards-development working group can have over vendor implementation decisions. If the contents of draft documents and Recommendations published by working groups at the W3C had the power to influence UA vendors in that way, all UAs would have client-side support for XForms and XHTML2 by now. > is, to me, a definition of a working _group_. Not the current state of the > group, which is author and backup chorus. If that's the way you really see the current state of this group, I can only say that your choosing not to contribute does nothing to change that state -- and if just watching it and not making an effort to help prevent it from becoming the future state of the group (instead of just the current state) seems like a sort of self-fulfilling prophecy. Anyway, I don't think the group even in its current state is a case of an author and a backup chorus. We have a task-oriented co-chair of the group who is in my estimation firmly at the helm as far as having a plan for doing some course correction in the group, and who is committed to guiding us forward toward a future state for the group which could be dramatically different from the current state. You and others are free to choose whether or not you want to help support him in that effort that he's making. > Even a Formal Objection may be too late to effect change, but could, at > least, help to highlight issues. At a minimum, a formal objection may help > influence perceptions about authoring conformance. In my estimation, formal objections are among the very least effective tools available to anyone who feels strongly about bringing about real change. As I've said before, in my limited experience at least, among the most effective means for bringing about real change are concrete proposals with alternate language for whatever parts of a draft that you'd otherwise state a formal objection to. --Mike -- Michael(tm) Smith http://people.w3.org/mike/
Received on Thursday, 25 June 2009 17:21:26 UTC