W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: HEADERS, FOR whom - any ID?

From: Jon Barnett <jonbarnett@gmail.com>
Date: Mon, 6 Aug 2007 14:59:08 -0500
Message-ID: <bde87dd20708061259k1e902978v1ea8c1cb2c4e2983@mail.gmail.com>
To: public-html@w3.org

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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:25 UTC