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

Re: A New Way Forward for HTML5

From: L. David Baron <dbaron@dbaron.org>
Date: Thu, 23 Jul 2009 10:38:08 -0400
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: HTMLWG WG <public-html@w3.org>, WHATWG <whatwg@lists.whatwg.org>
Message-ID: <20090723143808.GA14972@pickering.dbaron.org>
On Thursday 2009-07-23 09:48 -0400, Manu Sporny wrote:
> http://html5.digitalbazaar.com/a-new-way-forward/

I have a few thoughts on this document.


The above document says:

  # The single greatest complaint heard from the standards community
  # concerning the development of HTML5 is that it has not allowed
  # for the scientific process.

I strongly disagree with this statement.  A key part of a scientific
process is that the starting point is evidence.  I think the
development process of HTML5 gives arguments based on evidence more
weight than any other W3C work I've been involved in, and has put
more effort into gathering relevant evidence than any other W3C work
I've been involved in.  This is a good thing.


Regarding the section "Action: Splitting HTML5 into Logically
Targeted Documents", I agree that there is value in splitting the
specification.  However, I see significant danger in the way you
propose to split it:  separating the specification of what is
available to authors and what should be implemented means the
specification risks promising to authors what cannot be implemented,
or cannot be implemented at a cost proportionate to the benefit (as
HTML4 did in a number of places).


I'm a little bit puzzled by the inclusion of the section "Problem:
Partial Distributed Extensibility":  it seems to be a technical
issue (although a far-reaching one) in a document otherwise about
process issues.  I'm not sure it belongs in this discussion.


Finally, regarding the section "Problem: Disregarding Input from the
Accessibility Community".  I think some of the input that has been
ignored or has been felt to be ignored is input that is difficult to
act on.  Specification development ought to work from requirements
to solutions rather than straight to solutions.  This is done to
make sure that the requirements are addressed, to make sure that the
specification does not become more complicated than needed to
address the requirements, and (most importantly in this case) to
avoid unresolvable debates between parties that are emotionally
attached to particular technical solutions.  I think a number of the
arguments that have been ignored (e.g., some of the arguments over
@headers or @summary) have been arguments made *in the face of*
evidence that the particular technical solutions do not work in
practice, and without presenting the requirements that are not
addressed by the HTML5 specification's replacements for those
particular (non-functioning) solutions.  I think such arguments
ought to be ignored, ignoring them is not a problem, and giving
those who make them and then complain that they are ignored the
power to edit the specification would be a mistake.  However, I
think HTML5 specification reflects significant consideration for the
needs of disabled users, and I strongly encourage more input
regarding use cases for and requirements of disabled users that the
specification fails to meet.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Thursday, 23 July 2009 14:38:48 UTC

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