Re: HEADERS, FOR whom - any ID?

On Aug 6, 2007, at 10:02 PM, Robert Burns wrote:

>
> 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>


Just to followup on my own suggestion. Here's some changes we might  
make to the DOM interfaces of table cells to help create better  
ineroperability, usability and accessibility for tables.

interface HTMLTableHeaderCellElement : HTMLTableCellElement {

  readonly attribute HTMLCollection dataCells
};


interface HTMLTableCellElement : HTMLElement {
                    attribute long colSpan;
                    attribute long rowSpan;
                    attribute DOMString headers;
                    attribute DOMString scope;
                    attribute DOMString axis;
                    attribute DOMString abbr;
  readonly attribute boolean header;
  readonly attribute long cellIndex;
  readonly attribute HTMLCollection headerCells
  readonly attribute HTMLCollection axisCells
};

This restores @abbr, @axis, and @headers. I t also restores the HTML  
4.01 practice of allowing combined data and header cells: that is a  
data cell can act like a header cell. Also UAs implementing the HTML5  
DOM would need to establish the algorithm (whatever that ends up  
being) to associate header cells and data cells. Other authors/ 
developers could access those through DOM calls to headerCells from a  
data cell or dataCells from a header cell. The DOM could also  
querying a cell to see if it was acting as a data cell through the  
readonly boolean DOM attribute: "header".

to answer my own question a bit, the HTML5 algorithm seems to be less  
complete than the HTML 4.01 algorithm (especially without scope set).  
That is the HTML 4.01 algorithm allows header cells to be scoped to a  
limited number of header cells (until the next header cell) whereas  
the HTML5 algorithm automatically scopes the header cell to the  
entire row or column. Also in HTML 4.01, the algorithm appears to do  
more even without @scope set. So simply using TH in HTML 4.01 has the  
effect of scoping every data cell to the right (left in rtl) and  
below (until the next header cell). That strikes me as even less  
demanding on authors than the proposed HTML5 algorithm. Am I  
misunderstanding this?

Take care,
Rob

Received on Tuesday, 7 August 2007 03:36:12 UTC