- From: Robert Burns <rob@robburns.com>
- Date: Tue, 3 Jul 2007 17:33:20 -0500
- To: Andrew Ramsden <andrew@irama.org>
- Cc: Thomas Broyer <t.broyer@gmail.com>, public-html@w3.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, Rob
Received on Tuesday, 3 July 2007 22:33:48 UTC