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

On Sep 24, 2008, at 21:01, Laura Carlson wrote:

> Henri wrote:
>
>> 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,
>
> HTML WG has requirements in our charter to work with  WAI, and PFWG in
> particular. It says: "The HTML Working Group will cooperate with the
> Web Accessibility Initiative to ensure that the deliverables will
> satisfy accessibility requirements.

"Work[ing] with" and "cooperat[ing]" are different from the attitude I  
was referring to. What I was referring to has been observable on the  
list and on telecons, but it's elusive to pinpoint there, so I point  
to the operative verb in title of this blog post for illustration:
http://www.paciellogroup.com/blog/?p=80
(The title is: "Circumventing Hegemony in the HTML WG")

> However the @headers issue is 14 months old. Over a thousand messages
> have been written on this subject on-list.

What proportion of those messages has carried new information? I  
wouldn't want the WG to set a precedent that sending a huge volume of  
email gets an issue ahead of queue just to make the flood stop.

> It has been an issue since
> May 2007. [4] Like Julian mentioned "if each feedback loop takes two
> years we have a serious problem that we need to fix, for instance by
> installing more editors". [5]

It would be great if we could go faster without having to make a  
tradeoff that would sacrifice something else (such as spec precision).

Just having more people--any people--is not a solution (compare with http://en.wikipedia.org/wiki/The_Mythical_Man-Month) 
. Potential editors who are competent, willing, available and have  
sustainable funding for spending substantial time on editing are in  
very short supply.

>> 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.
>
> It is highly commendable to improve the algorithm, but retaining
> headers/id functionality is needed as well as backwards compatibility.
> I June 2007 PF advised grandfathering it into the spec

In the part of my email you didn't quote, I said I was in favor of  
grandfathering headers/id into the spec. (With the caveat about the  
case of research showing net harm given existing content.) Your  
response makes it seem like I had said the contrary. (In fact, I also  
got off-list mail that seemed to assume I had opposed grandfathering  
headers/id, so perhaps I'm not communicating clearly.)

As for only making it conforming to point to th (i.e. not td),  
consider compatibility with legacy clients:
If an author marks up a table properly using th for headers so that  
the table would work with presumed future clients automatically, to  
feed the same associations to legacy clients, the author only needs to  
point to th elements with the headers attribute. (If the author were  
pointing to td element, (s)he'd be doing something other than merely  
adding compatibility for legacy clients. I'm assuming here that legacy  
clients don't barf on th elements, so th avoidance isn't required by  
legacy clients.)

Consider amending cases where the automatic algorithm fails:
If an author marks up a table properly using th for headers and the  
algorithm fails, the author needs to override associations and point  
to the right th(s). Here again, if the author were pointing to td  
elements, (s)he'd be doing something other than merely fixing  
associations that the algorithm got wrong.

What am I missing?

BTW, when I asked for expedited consideration regarding this issue in  
2006 because I was *about to write code* pertaining to this spec area,  
Hixie guessed (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-October/007430.html 
) that the spec would have headers/id but only pointing to th in the  
same table would be conforming. If you try, you'll notice that the  
code is still running in Validator.nu, which means my guess is that  
we'll end up having headers/id in the spec.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Thursday, 25 September 2008 08:05:07 UTC