W3C home > Mailing lists > Public > www-archive@w3.org > June 2009

Re: HTML WG - editing vs. affecting change [was: evidence of harm]

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
Message-ID: <20090625172110.GD30372@sideshowbarker>
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

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


Michael(tm) Smith
Received on Thursday, 25 June 2009 17:21:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:33:40 UTC