Re: function and impacts (was: @scope and @headers reform)

On 24 Sep 2008, at 12:33 PM, Henri Sivonen wrote:

>
> That said, I have four problems with the way headers/id has been  
> lobbied.

I am sorry if you feel this is what people are saying, but I can't  
validate this from anything I have heard or read.

The reference that HTML WG Participants are supposed to review before  
participating in any poll, as I understand the guidance from the chairs,
is the Wiki page

http://esw.w3.org/topic/HTML/IssueTableHeaders

If that review of the issues fails to reflect a neutral point of view,
please comment on <pubic-html@w3.org> with specifics about that page.

As for myself, I have been greatly _encouraged_ by the comments on  
this thread, from all sides, that suggest

* broad support for the definition, development, and deployment
of client-side processing that will make the author's job easier.

* broad recognition that de-scoping @headers is premature at this
time, if we are to take 'evolution, not revolution' seriously.

So I think we [HTML WG + WAI] have a positive way forward, and that's
what we [PFWG] will be pursuing in our conversations at TPAC.

Al

>
> 1) Headers pointing to td. I may be missing some practical issues  
> here, but to me it seems that this is essentially a statement  
> against native markup semantics enabling accessibility and for  
> promoting bolt-on accessibility as an ongoing solution. To raise  
> the overall accessibility on the Web, making things work out-of-the- 
> box should be the way to go, so we should promote proper use of th  
> semantics.
>
> 2) The attitude that a *handful* of AT vendors can't implement  
> complex algorithms so instead it's OK that *countless* authors  
> should go through trouble they wouldn't need to go through if the  
> client software had the kind of algorithms James' inspector has is  
> just wrong. I'd have a much more favorable view on the exact same  
> technical details and syntax if people advocating headers/id  
> indicated that client-side automation were the goal and headers/id  
> were mainly for legacy compatibility. (Putting the algorithm in  
> browser engines instead of ATs seems to be the better place  
> technically, though.)
>
> 3) Even if I'm inclined to think that headers/id as a pre-existing  
> feature should be kept as an override and for targeting legacy UAs  
> (even if the case for introducing headers/id to HTML now might not  
> quite be strong enough if headers/id hadn't been in HTML4), I don't  
> like the attitude of trying to fast-track this particular thing  
> even by trying to use another WG to override this WG when there are  
> some many other things in the queue (including the WF2 stuff from  
> 2006, which is being processed now). If an implementor had  
> announced that s(he) was scheduled to touch the table accessibility  
> API exposure code in Gecko, WebKit, Opera or Trident imminently,  
> then there'd be a good reason to put this issue ahead of queue.
>
> 4) The message has been "HTML5 should have headers/id"--just that.  
> However, I haven't noticed suggested solutions to obvious problems  
> that would flow from having headers/id, such as how to deal with  
> cyclic references.
>
> -- 
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>
>

Received on Saturday, 4 October 2008 16:39:04 UTC