W3C home > Mailing lists > Public > public-html@w3.org > September 2009

Re: what is dt?

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 16 Sep 2009 20:49:59 -0700
Cc: Smylers@stripey.com, public-html@w3.org
Message-id: <CF65ED73-5D08-4AAD-812B-4DB634E01566@apple.com>
To: Shelley Powers <shelleyp@burningbird.net>

On Sep 15, 2009, at 12:48 PM, Shelley Powers wrote:

>
> If we're redefining semantics, which is the exact  same thing as  
> saying we're rejecting semantics, then why not at least use  
> something that is meaningful? Such as caption?
>
> Why on earth are we using such inappropriate elements, when there's  
> one to hand that at least sounds about right?

[...]

> This was such a bad decision. No thought either, just throw  
> something out because some "super friends" had a hissy about legend.  
> I agree by the way, about the use of legend, but their suggestion  
> was for "label".

I've been a longtime advocate of moving <details> and <figure> away  
from <legend>, and I even suggested <caption> and <label> as  
possibilities. In the past, we've found that most of the existing HTML  
elements that mean something like "label" or "caption" have technical  
difficulties. For the record, here's a summary of past discussion.  
Note that most of these arguments are originally due to other people  
than me, I am just repeating them.

caption:
- Gets stripped by browsers outside of a table. This would make  
<details> and <figure> unusable until all browsers updated their  
parsing.
- Inside a table, <caption> pops the parser out of the current cell  
into the top level of the table. This would make it impossible to use  
<details> or <figure> inside a table. Worse yet, the popping out  
behavior of <caption> can't be changed, for Web compatibility reasons.

legend:
- Causes different undesirable behavior in all browsers (WebKit drops  
it, Gecko adds a fieldset, IE adds two empty elements named "legend"  
and "/legend"). This would make <details> and <figure> unusable until  
all browsers updated their parsing.

label:
- Is associated as the label for any controls inside it; probably not  
a big deal for <details>, but it's totally plausible to have  
checkboxes, radio buttons, text fields or other form controls in the  
caption of a <figure>. Think about the flickr UI for editing a photo  
caption, or sites like "Am I hot or not", or a UI to check the photos  
you like best out of a set.
- Cannot ever receive keyboard focus; this is more of a problem for  
<details> than for <figure>, since it is an interactive element.
- Apparently, a fair number of pages have existing style rules for  
"label" that are not further qualified, intending them only for form  
control purposes. Adding a <figure> or <details> to such a page would  
cause styling oddities in the caption, unless all existing label CSS  
rules are changed to qualify them further.

h1:
- Extremely likely to be styled by the site in a way that's not  
appropriate for a figure/details heading.
- Would interfere with attempts to infer an outline for the page.

title:
- Can only contain plain text, not markup.
- Gets moved to <head> in at least some current browsers when it  
appears in <body>.

If it were not for these technical difficulties, my first choice would  
be <caption> for <figure> and <label> for <details>, based on natural  
English usage. But I think these technical objections are stronger  
than matters of taste.

I think the only known options that avoid technical problems are using  
<dt>, or adding one or more new elements.

Reusing <dt> and creating a new element (that means something similar  
to the many heading/title flavored elements we have already) both have  
their downsides from an aesthetic perspective. It's hard for me to  
declare one option clearly better than the other. Personally, I can  
buy into the idea that the <dt>/<dd> pair always creates a label/item  
association, but the exact nature of that association is defined by  
the containing element. But I can also see that writing <figure><dt>  
might not be very mnemonic.


Regards,
Maciej
Received on Thursday, 17 September 2009 03:50:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:08 UTC