Re: HEADERS, FOR whom - any ID?

On 2007-08-04 16:56:41 +0200 Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:

> Leif Halvard Silli wrote:
>> But why _haven't_ WHATwg proposed to remove it? FOR/ID and HEADERS/ID are 
>> twins - they're there for the same reasons!
> 
> Although they are both forms of explicit association, they're not included 
> for the same reason.  These are some additional reasons for including for="" 
> that do not apply to headers="".

Explicit - or «hard coded» associations are used to overrule/add to the implicit associations created by containership. I fail to see that you are describing other reasons: 

> * Allows for labels and controls to be separated, which allows for more 
> flexibility in the structure and style of the page.

It allows for flexible/sloppy** coding praxis for FORMs (= the "page"). Just as HEADERS/ID  allows free association of TABLE cells with cells outside their natural row/column container.

**Sloppy: to nest controls in LABEL elements should be recommended practise.

> * Increased usability by allowing users to click on the label to focus the 
> control. That's particularly important for checkboxes and radio buttons.

It is the association which creates this functionality/usability.  It doesn't matter whether you use FOR/ID or if you rely on containership. 

> * It is very widely used in reality.

Reality? We are talking media here. Hypermedia. :-D Else, by «same reasons», I was referring to HTML4.

>> It is logically inconsistent to keep the one combination that happens to 
>> assists sighted persons (FOR/ID), while at the same time propose to remove 
>> the one that (due to lack of follow-up of what HTML4 actually proposes) 
>> _only_ assists visually impaired (HEADERS/ID).
> 
> I disagree about it being logically inconsistent because of that rather 
> significant difference,
 
I fail to see that you established any different reasons at all. The one thing that differes is of course how often they occurs in documents. But that is nothing new. It remains that for the most part, both FOR/ID and HEADERS/ID are used for compatibility reasons - and not for usability reasons.

> but regardless of that, it seems likely that the 
> headers attribute will be added in due course.

This is good to notice. But then again, HEADERS is not an island. Are we dropping the new SCOPE algorithm in favour of the old algoritms of HTML4?  Why shall AT browsers adapt to new algoritms? Will we essentially be able to say the same about TABLE that is currently said about FORM? Namely that «This section will be a rewrite of the HTML4 [...] with hopefully no normative changes»? [1]
 
>> Lesson: To make HTML «accessible by design», it would be a good strategy 
>> strive to ensure that accessibilty elements/attributes also assists sighted 
>> persons.
> 
> Yes, whenever possible, that's a reasonable strategy to follow.

And then you have of course thought about why it is - or isn't - a reasonable strategy to follow when it comes to showing associations in TABLEs? 

Can we _add_ usability for sighted people as well? 

[http://www.whatwg.org/specs/web-apps/current-work/#forms]
-- 
leif halvard silli

Received on Sunday, 5 August 2007 01:52:11 UTC