Re: ISSUE-83 ACTION-152 Change Proposal for the use of dt/dd in figure and details

On Fri, Nov 27, 2009 at 5:22 PM, Jeroen van der Gun
<noreplytopreventspam@blijbol.nl> wrote:
> Even with a new element, hacks will be necessary for the simple reason
> that IE is unable to style unknown elements. If you decide to create a
> figurecaption element or something like that, the figurecaption cannot
> be styled either. The whole problem was that styles of dd and dt were
> leaking to the parent, in other words, the dd and dt elements could
> not be styled without side effects. So it will either be a dt element
> with a styling problem or a figurecaption element with a styling
> problem. To style the document, a hack is needed either way.

If people want to use any of the HTML5 elements, and have the elements
style in IE, they'll have to use the createElement option. There's
already a JS library specifically for this. Wrapping figure with a div
element is an additional hack.

>
> The div hack is required anyway to style the figure, e.g. make it float.
>

For IE. But if we used createElement, and CSS, and didn't use dt/dd,
we wouldn't need to use a div element, would we? (I haven't tried it,
and I'm using a Mac at this moment.)

> The figurecaption element will have the additional problem of not
> being recognized as a block level element. It will also need an HTML
> hack if the caption is below the figure: a div element will need to be
> inserted in the figurecaption element.
>

Unless we use createElement.

> Of course these could be avoided by creating the elements through
> JavaScript and defining their behaviour in CSS explicitly, but I
> personally think this is even uglier (especially since the code will
> have to target IE specifically).
>

Sure, but frankly, this probably won't be the only ugly JS we'll need
to use for IE6/IE7.

I'm not happy with having to use JS either, but if we start the hack
that figure has to be wrapped in div, it's a hack that's going to
linger past the time we need it. Anytime we use markup to hack, we're
less likely to clean up the markup at a later time. It's typically
easier to use JS, because we can either remove the hack in the JS at
some point (one edit in one place), or remove the JS file at some time
(one edit in one place in the entire document).

> To summarize the two possibilities:
>
> Current specification (preferred by me):
> <div class="figure">
> <figure>
> <dd>Insert something like an image here.</dd>
> <dt>This is the image caption.</dt>
> </figure>
> </div>
>
> The alternative (which I do not support):
> <div class="figure">
> <figure>
> Insert something like an image here.
> <figurecaption><div class="figurecaption">This is the image
> caption.</div></figurecaption>
> </figure>
> </div>
>
> This alternative with the figurecaption element is also problematic
> for the details element, since everything except for the caption
> should be hidden if the open attribute is missing. It is quite strange
> to hide an element except for one child and I'm not sure it is even
> possible.
>
But what you're talking about is a problem whether we're using
fltcaption, or using dt/dd.

Yes, I'm not fond of details.

There is third option, and that is to not have a caption at all, other
than what people add themselves:

<figure>
<img src="..." alt="something meaningful" />
<p class="caption">This is the figure</p>
</figure>

Someone mentioned about adding an attribute that could be added to any
element to make it a caption, and that would eliminate some of the
problems, but I find myself asking: why?

Do we need to do something with caption, that we have to designate a
special element? There's nothing meaningful about it. It's not even
required. In fact, there's barely anything meaningful about figure.

I think your finding this workaround is clever, but it is also quite
ironic: the whole purpose behind article, section, figure, et al, is
that some folks felt that the use of div elements for all of these was
an error, a bad legacy from HTML4. Yet here we are again, wrapping
contents with a div.

Then consider the worst case scenario:

<div class="figure">
<figure>
<dd>
<img src="..." alt="..." />
</dd>
<dt>something</dt>
</figure>
</div>

What if we don't have a caption, which is conforming. Then what we have is:

<div class="figure">
<figure>
<dd>
<img src="..." alt="..." />
</dd>
</figure>
</div>

Three elements all of them doing nothing more wrapping the real thing.
Frankly? Your approach shows that we should consider just bagging the
figure element.

> Since I personally think that the semantic change of dd and dt is
> small, I'd prefer to keep the specification as it currently is. If
> there needs to be a formal proposal to _not_ change the specification,
> then consider this a counter-proposal.
>

On the one hand, we have article, section, et al because of some drive
for meaningful or semantic elements, on the other hand, we're
redefining existing elements, which is redefining their
semantics--this is not a consistent message.

Then there's the issue of syntax: dt/dd behaves differently and
requires completely different syntax based on the parent element. I
don't think people are considering the problems this is going to
cause.

> Jeroen van der Gun
>

Shelley

> (BTW for the time being this e-mail address will keep accepting
> incoming mail, it's just so I can dump it in future.)
>
> 2009/11/27 Shelley Powers <shelley.just@gmail.com>:
>> On Fri, Nov 27, 2009 at 4:15 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> On Fri, Nov 27, 2009 at 1:40 PM, Shelley Powers <shelley.just@gmail.com> wrote:
>>>> Or we could use a new element, which doesn't require wrapping figure
>>>> in a div element, and also satisfy the two other expressed concerns,
>>>> too.
>>>
>>> Considering the benignness of this hack, and the fact that it's only
>>> going to be required as long as IE7 remains relevant, creating a new
>>> element seems excessive if this is the only reason.  (I was previously
>>> somewhat on the side of creating a new element, but it's just not
>>> necessary anymore.)
>>>
>>>
>>
>> Hacks tend to persist long after they're needed. It becomes extremely
>> easy to lose the meaning behind the hack at some point, in which case
>> we'll end up with figures wrapped in divs long after they need to be.
>>
>> Do we really want to issue a new specification that has to have hacks
>> built in, because of redefining existing elements? That seems to me to
>> run counter to the platform on which decisions have been made in the
>> past.
>>
>> A new element is just as simple, and it doesn't bring with is the
>> semantic and syntax concerns. Remember, the tech issue was one of
>> three concerns, and it wasn't my strongest concern. This hack, gentle
>> as it is, doesn't address either of the other two concerns.
>>
>> Jeroen, this is automatically attached to the issue because of the
>> subject line. Do you want this email to be considered a formal
>> counter-proposal?
>>
>>
>>> ~TJ
>>>
>>
>> Shelley
>>
>

Received on Saturday, 28 November 2009 00:15:47 UTC