Re: HEADERS, FOR whom - any ID?

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.
>
> If there is further discussion needed surrounding @scope and @headers in
> <table>, this should be taken up in a separate thread.
>

The premise in the original post was that the same logic that applies
to table/@headers also applies to label/@for, so therefore, 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.

label/@for has use cases that aren't covered by the alternate syntax -
putting <input> inside <label>.  For example, there are obvious use
cases where the label is in one table cell, but the field is in
another, or the label is inside a <dt> and the field is inside a <dd>.
 In those cases, the only logical markup is to use @for.

But using @for becomes cumbersome: 99 form fields leads to 99 unique
@id attributes and 99 @for attributes.  It's cumbersome, but it's the
only option.  Someone might propose an alternative that would simplify
this if they wanted, where @for contained an XPath:
for="../following-sibling::dt/input" - that would prevent the need for
99 unique IDs on the page by instead using 99 identical @for
attributes.  I'm not specifically proposing this, but that's an
example how syntax can be markup can be simplified for authors in a
way that keeps semantics.

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

Debi Orton wrote:
> The most useful example I've found of using headers/id is for
> extremely dense tables of such size that reiteration of row and
> column headers is necessary to place the information in context.

Can you give an example of those where the semantics of @scope don't suffice?

-- 
Jon Barnett

Received on Monday, 6 August 2007 19:59:11 UTC