W3C home > Mailing lists > Public > public-html@w3.org > August 2008

Re: table headers - clear description of problem

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Tue, 26 Aug 2008 02:08:36 -0500
Message-ID: <1c8dbcaa0808260008u72cc3b5by6b048a6b34fdc016@mail.gmail.com>
To: "Ian Hickson" <ian@hixie.ch>
Cc: "Steven Faulkner" <faulkner.steve@gmail.com>, "public-html@w3.org WG" <public-html@w3.org>, "W3C WAI-XTECH" <wai-xtech@w3.org>, wai-liaison@w3.org

Hi Ian,

In the message quoted below, you describe your process of "How to add features to HTML5" [1] (We still do nor know if this is HTML WG process)*

Anyway, has the new replacement for table headers/id gotten to step number two in your process? Have AT implementers committed to implementing your replacement for headers/id? If so which ones?

We know AT implementers support headers/id [2] [3] [4]. For AT backwards compatibility alone, Action 72 [5] should be accepted and the definition of the headers attribute be extended to allow the headers attribute to reference a td.

Ian Hickson wrote:

>  1. Research the use cases and requirements by discussing the issue
> with authors and implementors. Read the responses. Listen to the
> feedback. Consider whether your ideas are good solutions to the
> use cases and requirements put forward. Discussions here should be
> done in public, e.g. on an archived public mailing list or
> documented in blogs.
>  
> 2. Get implementors to commit to implementing
> the feature. If you can't get several implementors to implement
> the feature, then get at least one user agent to implement it
> experimentally. Experimental implementations should be publicly
> available.
>  
>  3. Bring the experimental implementations to the attention of the
> spec's editors. Document the experience found from any
> implementations, the use cases and requirements that were found in
> the first step, the data that the design was based on.
>  
>  4. Participate in the design discussions, considering all the
> proposals carefully. Typically at this step the original design
> gets thrown out and a significantly better design is developed,
> informed by the previous research, new research, and
> implementation and author experience with experimental
> implementations. Sometimes, the idea is abandoned at this stage.
>  
>  5. The spec is updated to reflect the new design.
>  
>  6. Implementations are updated to reflect the new design. More
> authors and implementors are exposed to the design.
>  
>  7. The spec is updated to fix the many problems discovered by
> authors and implementors, over a period of several years.
>  
>  8. At the same time, write a comprehensive test suite. This will also
>    find problems in the spec, which have to be fixed.
>  
>  9. Eventually, a number of provably interoperable implementations are
>    deployed. At this point development of the feature is somewhat
> frozen.
> 
> This is the process that has been followed for almost all the new
> features in HTML5. Some features failed to go through this process,
> most of those are likely to be removed (e.g. the data templates
> stuff).
> 
> I should add that in almost all cases, features fail to make it past
> the first few steps. Even after reaching step 5 (adding the feature
> to the spec), if the feature doesn't get implemented widely it can
> (and will!) _still_ be dropped. The default state for a feature
> request is for it to be rejected; the default state for a section of
> the spec is for it to be eventually dropped. I can't could the number
> of ideas I've had that I've thrown out, sometimes before even talking
> to anyone about them (step 1).
> 
> Also, at the moment I'm being especially negative in terms of new
> features, since HTML5 has so many new things already and
> implementations are lagging behind. We don't want to add so many
> things to the spec that user agents all implement different new
> features and nobody is compatible! Because of this, the bar for
> adding features right now is basically a threat from an implementor
> that if we don't add the feature they'll just make it up themselves
> and implement it anyway. This limits it only to things that are so
> important that browser vendors (an especially stingy and overworked
> group) are actually ready to commit money and risk interop issues
> over it.
> 
> (This doesn't apply to features that were proposed last year or
> earlier, since those would already been processed last year, before
> the feature freeze was announced, if it wasn't for me being slow.)

Best Regards,
Laura

[1] http://lists.w3.org/Archives/Public/public-html/2008Jun/0140.html
* We still do not know if Ian's procedure is an official HTML5 working group procedure or not:
  http://lists.w3.org/Archives/Public/public-html/2008Jun/0145.html
[2] http://esw.w3.org/topic/HTML/TableHeadersTestingBug5822
[3] http://esw.w3.org/topic/HTML/TableAccessibility
[4] http://esw.w3.org/topic/HTML/IssueTableHeaders#head-33a3d0ffbf5c6936b165f1ef92a80d98015073fb
[5]  http://esw.w3.org/topic/HTML/Action72Headers
Received on Tuesday, 26 August 2008 07:09:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:22 GMT