Re: dt/dd in figure/details has killer rendering issues in ie6 and

Tab Atkins Jr. On 09-09-23 16.19:

> On Tue, Sep 22, 2009 at 7:34 PM, Leif Halvard Silli <lhs@malform.no> wrote:
>> Tab Atkins Jr. On 09-09-22 23.47:
>> Tab, for <dl> you've interpreted dt as 'description title' and dd as
>> 'description data', while in <details> you suggested dt as 'details title';
>> and dd as 'details data';[1].  Hence, by analogy, do you suggest <ft> -
>> figure title and <fd> - figure data?
> 
> It would have the benefit of naming consistency there, at least, and
> makes the pattern being established by the reuse of <dt>/<dd> more
> clear (which would help alleviate Shelley's concerns somewhat).*  I
> wouldn't be opposed to elements with those names.
> 
>> But if we can't use <dt> and/or <dt> in both elements, then what is the
>> /technical/ advantage of using them in just /one/?
> 
> I'm not certain what you mean by "technical advantage" here.

I meant what I said in the same paragraph about "need to define 
workarounds for the more comomon <figure> caption" - see old quote 
below. E.g. for IE6 and 7, if we have separate solutions for 
figure and details, yet use <dt> for details, then then we still 
need to do this:

<script>document.createElement("figureCaptionElement")</script>

And, so why not use that single fix-up line that we need to have 
anyhow for a more economical way, with a more predictable effect:

<script>document.createElement("generalCaptionElement")</script>

The latter option effectively gives authors just one technical 
problem (and one semantical problem too) to solve. Whereas <dt> + 
<ft> gives authors two technical problems to solve (and two 
semantical problems too). It would be strange that, for backwards 
compatibility, one has to "fix" the one, but not the other - or 
that you have to fix them in different ways.

Some background: When I proposed <dt><dd> many months ago, then it 
was because of technical considerations - it was the only solution 
that was Firefox 2.0 compatible, as Firefox 2 does not keep block 
elements if they are inside new elements.

Or so I thought. Because, actually, both Firefox 2 _and_ 3.5 are 
incapable of keeping many of the block elements, at least not 
h1-h6, inside <dt>, unless they are wrapped in a <div> or another 
supported element.  Yet another hick-up - yet another reason to 
not favor the <dt> solution ...

>> We still need to define
>> workarounds for the more common <figure> caption. And thus, why not rather
>> drop the body element  (<dd> or whatever) and invent one, new caption
>> element for both figure and details?
> 
> Well, <figure> and <details> aren't really related at all, except that
> they're both new and both have their contents split into two distinct
> pieces.  That's the only reason people keep drawing parallels;
> otherwise they're quite distinct.

To me, <details> looks like a special purpose <figure> element. 
And, also, our subject right now is the caption of both. And the 
caption of both have everything in common - except their parent 
element.

> That said, I've got nothing against solely marking up the
> caption/toggler; after all, that's how they were set up previously,
> before <legend> got dumped.

Is it perhaps easier to control the caption, via CSS, if there 
also is a body element?
-- 
leif halvard silli

Received on Wednesday, 23 September 2009 17:47:08 UTC