Re: what is dt?

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

We keep referencing the importance of semantics, but most of the 
considerations about elements to use for Figure and Details have been 
based on some physical characteristic or behavior. Physical 
characteristics and behaviors, I should add, that came about because of 
earlier, non-compatible semantics.

What has happened is that we've sifted through the various elements and 
found the ones that don't have any browser behavior attached that would 
make them incompatible. We then attach semantics that changes based on 
container, formatting that will have to change based on container, and 
even occurrence that will change based on container.

Where now, there is no real conflict about how dt/dd is used within the 
dl element, we've introduced confusion. A very significant confusion.

The use of dl/dt/dd is no longer encouraged for dialogues, because we've 
heard, there is no inherent order to the dt/dd elements in a definition 
list. Yet we've made rules that there can be many dt/dd pairs in a dl 
container, but only one pair in a Figure, and I'm not quite sure how 
they work in Details yet. The first is a dt, the last child a dd, and I 
guess we can assume there is the possibility of millions of pairs in 
between. Which really confuses the heck out of what Details is.

But I digress. The way dt and dd is defined for use in Details, is 
because there can be many dts in a row in a definition list BUT, such 
behavior is not allowed in Details or Figure...

These "rules" will co-exist on the web with ten years of using dt/dd and 
dl for dialogue, now considered a "bad" use of dl, because of that 
aforementioned inherent lack order to dt/dd pairs within a definition 
list. Interesting, too, that such a restriction on the use of dt/dd 
pairs is enough to filter their use in dialogues, but a similar 
restriction is seemingly not enough to filter their use in Figure and 
Details.

Yet another paradox for such short, confused little elements.

Yes, I think that, among our other concerns, we can also include a 
concern about the mnemonics of dt/dd in Figure.

Shelley

Received on Thursday, 17 September 2009 04:17:57 UTC