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

Re: DI element [Re: html 5 and accessibility issue]

From: Robert Burns <rob@robburns.com>
Date: Tue, 3 Jul 2007 17:33:20 -0500
Message-Id: <43298F43-4A06-4E23-946C-F6FE8BF76C6A@robburns.com>
Cc: Thomas Broyer <t.broyer@gmail.com>, public-html@w3.org
To: Andrew Ramsden <andrew@irama.org>

On Jul 3, 2007, at 5:11 PM, Andrew Ramsden wrote:

> Thomas Broyer wrote:
>> But the point was that Rob was trying to style a table where a tbody
>> were to be inserted/implied between a *tr* and a *td* rather than
>> between a table and a tr.
> Another good point :)
> I put together some test cases using "table td" and "table tbody td":
> <http://wg.irama.org/html/test/table/implicit-tbody.html>
> ... And indeed it was the second selector that always matched (in  
> FF2). In fact viewing the generated source (DOM source), there was  
> always a tbody inserted. And the same is true of other browsers  
> tested (IE6, Opera9.2, Safari3.0.2).
> You learn something every day :)
> I might be missing something though. I can't see that it would it  
> be a problem for UAs to treat di the same way?

I think the problem is that existing browsers will not know to infer  
the <di> element. What I understood from the original proposal was  
that authors would need to make the <di> element explicit to make use  
of this facility (this is how UAs parsing tables as "application/xhtml 
+xml" work with tbody). So the proposal would be to the work the way  
XHTML works with tbody and not the way HTML works with tbody.

I think that should work for backwards compatibility and graceful  
degradation, though we'd need to test it to be sure.

The problem I see with using for="ids" is that it puts too much  
flexibility in the authors hands. You'll end up with @for pointing to  
an id that's not even a <dt> or to the <body> or whatever. This could  
treated  as a silent error, but I think the nested element structure  
is simply easier and less intimidating for novice authors and it  
accomplishes precisely what we're looking for and no more.

Take care,
Received on Tuesday, 3 July 2007 22:33:48 UTC

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