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

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.

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

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.

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

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.

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.

Jeroen van der Gun

(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 Friday, 27 November 2009 23:24:04 UTC