- From: Martin Atkins <mart@degeneration.co.uk>
- Date: Tue, 03 Jul 2007 18:35:22 +0100
- Cc: public-html@w3.org
Ben Boyle wrote: > > DT/DD has always stuck out like a bit of a sore thumb. it's just > different to how most elements work. I mentioned TBODY as a analogy to > DI, you can use it or not use it. It exposes the semantics in an > explicit way. As an aside, please note that the TABLE>TBODY thing is not currently implemented in an interoperable manner. For example: <table id="blah"> </table> ... and later ... var table = document.getElementById("table"); table.appendChild(row); Assuming that row is an instance of a TR element containing some cells, in Mozilla and Opera this will cause the new row to appear in the visual rendering of the table. In IE, the rows will go into the DOM but will not appear. This is because IE implicitly creates a TBODY element in the DOM to contain all of the orphan TRs, but this is handled in the parser, so the DOM API doesn't maintain the illusion. This is the same sort of confusing behavior that is likely to result if this "di" element is added. Either scripts that process the contents of definition lists will now have to handle both di and bare dl/dt as children, or the parser will have to magically introduce the di elements much like IE does with TBODY. The latter is unworkable since it'd break backwards compatibility. Another approach is to: * Add methods to the DOM API that allow scripts to access the logical structure of the list rather than the raw DOM tree, and * Define a CSS pseudo-element such as dl::definition-item which selects a definition item as defined by the processing rules. Then, if you really wanted to, you could do this: dl { display: table; } dl::definition-item { display: table-row; } dt, dd { display: table-cell } The above would not work were multiple dt or dd elements used within a single item, of course.
Received on Tuesday, 3 July 2007 17:35:30 UTC