- 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