Re: HEADERS, FOR whom - any ID?

Hi Leif and Jon,

On Aug 6, 2007, at 9:00 PM, Leif Halvard Silli wrote:
> On 2007-08-06 14:59:08 -0500 "Jon Barnett" <jonbarnett@gmail.com>  
> wrote:
>> Someone might propose an alternative that would simplify
>> this if they wanted, where @for contained an XPath:
>> for="../following-sibling::dt/input"
>
> Sounds tempting. The <label for="nextIput"> proposal from Craig  
> Francis sounded even better - seems we could learn from the AT  
> browsers there!

The problem with associating labels and inputs seems very much like a  
presentation problem (another parallel with @headers for  
compatibility with aural browsers). That is I can't imagine any  
reason to not place an INPUT inside a LABEL except that CSS does not  
provide sufficient flexibility in visually presenting the label and  
the input. It seems to me that CSS should have a 'label-side'  
property (like the 'caption-side' property for tables) that allows  
authors to select which side a label appears with respect to its  
controls. That property along with other positioning properties  
should be enough to satisfy any visual presentation need. XForms  
reverses the HTML approach and places the label inside the input  
(which probably makes a bit more sense when declaring the  
presentation properties).

>> On the other hand, I haven't yet seen a real-world use case where
>> @headers is needed in favor of @scope or simple implicit markup, and
>
> The real world use case for most (contact) forms is that they could  
> have been made without for= - were it not for compatibilty issues  
> with some browsers. Should such a thing just be considered a  
> "benefit" of the fact we need for= in other contexts?

Again, we have a presentation problem: this time aural presentation.  
Without the use of @headers the aural browser cannot associate the  
data cell with the header cells. Again it's necessarily something  
that cannot be expressed more simply with @scope, but for legacy  
reasons we need to keep @headers and @abbr around (well @abbr needs  
to stick around because there is' nothing proposed at all to replace  
it ).

If we CSS was made to handle these presentation issues, then HTML  
could probably get by with simply placing all INPUT elements (and  
other controls) inside the LABEL element and set @scope for TH  
elements. No more markup is required.

>> the markup is more difficult for authors: each header needs a unique
>> ID and each cell needs to reference one or two of those IDs.  If
>> there's a real-world use case where @scope just can't cut it, then it
>> shouldn't be an issue.
>
> There are real world cases: Browser compatibilty. (AT browsers -  
> that is.) Plus: why should it be solved with SCOPE? Why is that so  
> good? Ferg (<ferg.org>) claims that HEADERS in connection with the  
> Basic algoritm  is the simplest. And simplisity is a goal, I think?
>
> 80% of the use cases/users have mentioned as what we get with SCOPE  
> only, by those that want to go solely for SCOPE, so the issue about  
> documenting the need for HEADERS is over.
>
> And it is not just SCOPE per se. THe «new SCOPE» were also supposed  
> to get a new algorithm. And for what? To my mind comes an recent e- 
> mail by Henri Sivonen were he explained how important it was to  
> document the need for new things, before having the vendor  
> engineers doing all the work to implement your (wishywashy)  
> features. Then taste your own dogfood:  a) the new thing here is  
> the new (version of the) SCOPE attribute, and b) in this context  
> you are not developers - you are users (unless the GUI vendors  
> decide to support HTML4's proposal about supporting headers in GUI  
> browsers as well). The _developers_ here are the AT browser  
> developers. Which with the formerly proposed solution would a) get  
> fewer tools to work with and b) would have to devote engineering  
> time to implement a new algorithm etc. Why should they sing  
> halleluia for that?

I'm still working on my review of the Tabular Data chapter of the  
draft. However, I'd be interested to hearfrom anyone who can explain  
how the HTML5 "auto" algorithm[2] differs from the HTML 4.01 algorithm 
[1]. It's hard to tell what the new algorithm adds. Given that an  
algorithm that would have done much of what HTML5 proposes has been  
around for 8 years now and has not been implemented very widely, I  
wonder why we should think it now will b be implemented widely due to  
the HTML5 recommendation.

One thing I could imagine would help with this (more so than simply  
removing @headers) would be to add an associatedHeaders DOM attribute  
to the HTMLTableCell interface. This way UAs would need to implement  
this interface to become HTML 5 conforming. Extensions and other  
applications making use of general browser engines would have access  
to this DOM attribute implementing the proper data cell/ header cell  
association algorithm.

Other suggestions were made that we should liaison with the CSS WG to  
add selectors for axes and header cell pseudo-classes. In this way  
visual UAs could provide ::hover support that could visually  
highlight a data cells headers (as just one example).

Take care,
Rob

[1]: <http://www.w3.org/TR/html4/struct/tables.html#h-11.4.3>
[2]: <http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html? 
rev=1.78#header-and-data-cell-semantics>

Received on Tuesday, 7 August 2007 03:02:54 UTC