RE: {agenda} HTML WG telcon 2009-05-21

Speaking as someone with a long-term investment in web standards:

Design Principles:

My main objection to the Design Principles (and the document that has
resulted from them) is the fundamental assumption -- made from the
beginning, alas -- to confound the "describe, as best we can, what HTML in
the wild is today, and how to process it in a way that is bug-compatible
with IE" with the other goal of "define new features that increase the
expressivity and interactivity of the web", in a way that fundamentally ties
any future advances to the mess of the past. I think it's a step backward,
unnecessary, and leads to  a much worse, broken, inconsistent, and unhappy
world for users, authors, and future browser-makers. It was a bad technical
decision, made for short-term political (browser-wars) reasons.

Name of document: 

I also agree with Roy's assessment [1] that the document is named
incorrectly and should not be released with the current name. I'm less
concerned about what it is exactly renamed TO, my requirement is that it be
clear that it the document is not a "Technical Specification" of a
"HyperText Markup Language". 

As the use cases almost exclusively considered were "browser" use cases, the
document is most like a "Functional Specification for HTML5-based Browsers",
as it seems to fill that role, so that's my suggestion of what to rename it
TO.

[1] http://lists.w3.org/Archives/Public/public-html/2007Nov/0430.html

Process for Proposals:

I agree with Sam's contrasting the normal role of "editor" from Ian's role
as "author" (which is more appropriate than "dictator" since Ian controls
the document but not people directly). 

I am not satisfied with the Sam's suggested "Process for Proposals", as it
is at odds with the W3C process, and subject to manipulations that are
inconsistent with a transparent open standards process.

It is not part of the W3C process for authors to create separate documents
which the working group and then the AC vote on without discussion or
consensus.

In the W3C process, working groups may start with a document (often a Member
Submission), but then they discuss technical issues, accept feedback,
respond to public comment, and come up with a document which represents that
consensus, or, in cases where consensus is not available, identify the issue
and continue to gather more feedback to break the impasse. If voting is
necessary (in rare cases), then participants have identified their
affiliations and the significant relationships between their organizations
(as has not clearly been done in this WG).

"Lazy consensus" (or "silence is consent") is only effective when the
process is well-understood, issues are not embedded in an otherwise
impossibly noisy channel.  The more hours-per-week it takes to wade through
the working group mail to find essential "silence-is-consent" issues (and to
understand what the issue is in sufficient detail to make an informed
decision) the more likely it is that actual control will fall to the handful
of vendors whose proprietary interest is to dominate the work.  "Lazy
consensus" makes little sense when we have tools like survey forms where
members in good standing might have the opportunity to explicitly register
an opinion on issues, or explicitly abstain.


In the W3C process, working group editors attend meetings, accept action
items, edit documents as best they can according to the decision of the
group; if issues remain open, the open issues are carefully identified.
Generally, whenever possible, proposals are discussed before edits are made.


The prioritization of use cases are made by the working group, and the
process is open and transparent -- the reason for decisions are documented
and an effort is made to insure that the submitter of a comment is satisfied
-- or at least understands the reason -- for a response. 


As a counter-proposal: Treat the current draft as a Member Submission from
the WhatWG consortium. Finding someone to act as editor, in a way that is
consistent with the W3C process.  Ian could be editor if he is willing to
act in that role, rather than his current role. 

Surely, if this is a document of critical concern to the W3C, we can find an
editor who is willing to follow W3C process in the last stages of
development of that document. On the other hand -- if this is a functional
specification of current interest to a consortium of browser makers, who are
using it to complete and ship their products this summer -- there is no need
to turn the W3C process upside down just to give them bragging rights of
calling their products "open standards compliant".  

In the long run, it doesn't help the web, the W3C, the users, or even the WG
members who are short-sightedly pushing for such a thing.

Larry
-- 
http://larry.masinter.net

Received on Thursday, 21 May 2009 07:07:58 UTC