Re: HEADERS, FOR whom - any ID?

On 2007-08-06 14:59:08 -0500 "Jon Barnett" <jonbarnett@gmail.com> wrote:
> On 8/6/07, Jason White <jason@jasonjgw.net> wrote:
>> On Sun, Aug 05, 2007 at 08:32:46PM -0400, Debi Orton wrote:
>>> 
>>> I'd like to see a different tactic in this debate.  Can someone explain
>>> what the downside to including them is?
>> 
>> If I am right, then it would be best to acknowledge, as a consensus 
>> position, that there should be no change in this respect, and leave
>> the discussion there.

I hope this is right.

> The premise in the original post was [...] if there's
> a consensus about label/@for, why doesn't that obviously apply to
> table/@headers?  I can offer a couple reasons for this.

Right. But I think the technical side is clear: it is an identical case. What I am wondering about why there is a different attitude.

> label/@for has use cases that aren't covered by the alternate syntax -

Sure. But why don't you take the stand that have been taken about 'complex tables', that «Thou shall not make complex forms»? Why do you expect that HTML5 should care for you in this?

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

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

> 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?
-- 
leif halvard silli

Received on Tuesday, 7 August 2007 02:01:43 UTC