- From: Al Gilman <alfred.s.gilman@ieee.org>
- Date: Sat, 4 Oct 2008 12:38:17 -0400
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: joshue.oconnor@cfit.ie, James Craig <jcraig@apple.com>, Chris Wilson <Chris.Wilson@microsoft.com>, W3C WAI-XTECH <wai-xtech@w3.org>, public-html@w3.org, Gez Lemon <gez.lemon@gmail.com>
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:10 UTC