Re: headers attribute (was Re: Form elements)

On 2007-06-01 05:04:07 +0200 Bill Mason <w3c@accessibleinter.net> wrote:

> Leif Halvard Silli wrote:
>> Anne also made the point about authors mispelling headers. But do we know 
>> why they mispell it? I think because no web features that those authors can 
>> sense relies upon it. And so they don't sense their misdeeds.
> 
> Since we know authors also commonly misspell attributes that do have a visual 
> impact [1], the impact of the rest of your argument is somewhat muted at 
> best.

The [1] indicted you could back up your claim - but I did not find that link.

Well, I think you, at best, is exaggerating somewhat. We all do things wrong, mistype elements an attributes and what not. And both draconian error handeling as well as lack of feature adding helps us in analysing and finding errors.

>> But if, as the HTML4 spec suggestes, «the [headers] attribute may also be 
>> used in conjunction with style sheets», then suddenly we would be in 
>> another situation. And authors would have insentives to use it and get it 
>> right. The fact that no _visual_ stylesheets relies on the headers selector 
>> _of course_ a) make headers little used, and b) does not create an author 
>> incentive for creating correct syntax (i.e. for spelling headers right).
>> 
>> <http://www.w3.org/TR/html401/struct/tables.html#adef-headers>
> 
> The headers in question being referenced are going to be the elements with 
> the corresponding IDs, which are already easily selected/styled today.

As if that is what I talk about. All data cells in a table can have different header cells. Each one. Headers is the only attribute that can act as a CSS pointer/selecetor from within the cell and out to the header cells.

Scope="" also need to become a usable as CSS selector btw, that would help author using scope ="" instead of headers=""! Think

th:scope{}

should sellect the scope of that particular header cell. This would also be helpful for visual designers. They could test what the scope="auto" would select and so on. And they could also use it in their visual design.


>> Hence, what if we allowd headers="" to take single CLASSess as value, and 
>> not just multiple ID's. That, and to make it possible to use headers as CSS 
>> selectors. Let us say that I could, via CSS, use a single cell's headers 
>> attribute to ask that cell who its header cells are. That would soon become 
>> interesting even for GUA users. And it would provide visual authors with a 
>> visual way of checking that their design is not broken for screen readers. 
>> And it would be much simpler for authors to see (visually) which header 
>> cells the data cell belonged to.
> 
> * How then is existing AT supposed to associate the cell to its header, if 
> you don't identify the header IDs in the headers attribute and put class 
> names in instead?

Class would only be usable for those AT UAs which support it. Of course. THe good thing with using ID is that, probably, the UAs read the header cells in the order they are listed in the headers attribute. With class, one would need some rules which define the order in which those headers should be read.

> * If you want to style a cell's headers today, since the header value is the 
> IDs of the header cells, then all you do is just style those IDs. You do not 
> need to give headers duplicate functionality of the class attribute.

You don't get my point. And you forget about interactive design (which, btw, screen readers rely heavily upon, if I analyze how they work correectly). 

What, if when you mouse over a particular cell, all its header cells «lights up»? The CSS selector could look like:

td:headers{}

>> The advantage of letting headers="" take class is that one could «light 
>> up» a cell's header cells  without selecting via the headers attribute. It 
>> would also be "faster"/more simple for authors. But it would not provide a 
>> way to check whether I spelled headers="" correctly, unless headers somehow 
>> could be used as a selector.
> 
> Since you can already select the header cells via the IDs, your use case 
> boils down to making authors spell-check "headers".  This is not a valid 
> reason to change the functionality of the headers attribute.


This is one good reasons. But fortunately, you are wrong. This is not what my suggestion boils down to. (See above.)

>> That said, it would be great if I did not need to be blind in order to 
>> design with headers properly: CSS and headers="" must be coupled.
> 
> You're in good shape then, because you don't need to be blind or have new CSS 
> abilities to use headers.

Yes, we do. See above.

> What you propose probably falls out of our scope anyway and into the CSS 
> working group.

I cannot bring my proposal of having a :scope and a :headers (note, for the CSS savvy: not ::scope, but :scope) selector to the CSS group unless HTMLwg agree to keep those attributes.

We are discussing incentives for for having both scope="" and headers="". One important incentive is that authors can use them for something. It would be good if most attributes and features of HTML was usable not only for those in need of AT, but for all of us. Then we have better hope that they are used and used correctly.
-- 
leif

Received on Friday, 1 June 2007 11:40:02 UTC