Re: Implementor feedback on new elements in HTML5

Hixie wrote:
> These elements aren't especially critical

I agree that <figure> isn't especially critical — I think the use case  
is already quite well covered by <aside> (with a <header> in <aside>  
doing the job of <legend> in <figure>).

But <details> is really, *really* useful (to me and other authors) and  
there isn't anything similar to cover the use case of toggle-able  
content.

>> Why not abandon the idea of reusing legend and use <c>,  
>> <description> or
>> some other such element?
>
> Because the problem with <legend> is temporary, whereas the problems
> introduced with a new element would be permanent.

I understand the aversion to introducing a new element — though, like  
I said, it seems odd to introduce both <aside> and <figure>; two new  
elements covering very similar use cases (see also: <section> and  
<article>) — but I don't understand why <legend> is being treated as  
the only possible existing element to recycle.

For example, <dt> and <dd> are being recycled in the new context of  
<dialog> so they no longer mean "definition title" and "definition  
description". Now they can also mean (presumably) "dialog title" and  
"dialog description".

If those elements are already being recycled, why not apply the same  
thinking to <details> so that <dt> and <dd> could also mean "details  
title" and "details description"?

<details>
<dt>Details</dt>
<dd>All the gory details go here.</dd>
</details>

I guess the only question would be whether there would be any problems  
nesting <dt>s and <dd>s within the <details> <dd>:

<details>
  <dt>Copying... <progress max="375505392" value="97543282"></ 
progress> 25%</dt>
  <dd>
   <dl>
    <dt>Transfer rate:</dt> <dd>452KB/s</dd>
    <dt>Local filename:</dt> <dd>/home/rpausch/raycd.m4v</dd>
    <dt>Remote filename:</dt> <dd>/var/www/lectures/raycd.m4v</dd>
    <dt>Duration:</dt> <dd>01:16:27</dd>
    <dt>Color profile:</dt> <dd>SD (6-1-6)</dd>
    <dt>Dimensions:</dt> <dd>320×240</dd>
   </dl>
  </dd>
</details>

...but that's already going to be an issue with <dl> and <dialog>:

<dl>
<dt>Abbot and Costello sketch</dt>
<dd>
  <dialog>
  <dt>Costello</dt>
  <dd>Look, you gotta first baseman?</dd>
  <dt>Abbott</dt>
  <dd>Certainly.</dd>
  <dt>Costello</dt>
  <dd>Who's playing first?</dd>
  <dt>Abbott</dt>
  <dd>That's right.</dd>
  <dt>Costello</dt>
  <dd>When you pay off the first baseman every month, who gets the  
money?</dd>
  <dt>Abbott</dt>
  <dd>Every dollar of it.</dd>
</dialog>
</dd>
</dl>

So, maybe I'm missing something, but what advantage does <legend> in  
particular have over some (any!) other element such as <dt>?

I'm talking specifically about <details> here. I think that throwing  
away both <figure> and <details> because of parsing problems with  
<legend> really is throwing the baby, the soap, and the soap dish out  
with the bath water. I don't think it's helpful to discuss <figure>  
and <details> as if they are related—the only relationship is that  
they both currently use <legend>.

My take is:

1. There isn't a strong enough use case for <figure> and its existence  
could even be confusing to authors.
2. There are very good reasons for having a <details> element (the  
fact that authors are already hacking this behaviour together using  
JavaScript shows that) but the insistence on the <legend> element  
makes it unworkable. I'm proposing using <dt> instead but frankly I'd  
be happy with any other element.

Thinking about it, I'm guilty here of discussing <figure> and  
<details> together, which is exactly what I'm saying isn't useful. I  
should really start two separate discussions; one on the redundancy of  
the <figure> element and a second on alternatives to the <legend>  
element within <details>. Sorry.

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/

Received on Monday, 14 September 2009 11:32:41 UTC