Re: DI element

Martin Atkins wrote:
 > 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.

I see this as a /potential/ UA issue for di. We can't assume that these 
issues will occur, and are largely outside our control. We can't base 
our decisions around what a UA /may/ implement poorly (even if there is 
precendence from the way tbody is handled in IE).



 > 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.

I see this as a really good (and creative) solution.

I still feel that adding a DI element would prove a more elegant 
solution. Also, because a DI element would be consistent with other HTML 
grouping elements it should be easier for authors to understand and use.
Even if it means that UAs must insert implicit DI elements where they 
don't exist.



Cheers,
Andrew Ramsden


Martin Atkins wrote:
> 
> 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 22:30:08 UTC