Re: <details>

On Mon, 14 Sep 2009, Jeremy Keith wrote:
> 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.

   <div class="details">
    <div class="legend"> ... </div>
    <div class="body">
     ...
    </div>
   </div>

...with some script handles this fine today.

The <details> element improves accessibility, and is probably easier to 
use for authors, but it doesn't add anything that can't be done today.


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

There are already about 18 elements in HTML that have some kind of 
semantic that basically boils down to "heading" (<head> <title> <h1> - 
<h6> <hgroup> <header> <strong> <caption> <thead> <th> <label> <legend> 
<optgroup> <dt>). It's getting ridiculous.


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

That's not a bad idea actually. Ok, done.

While I was at it, I also did this for <figure>, and removed <dialog> from 
the spec altogether.


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

The main advantage was consistency with <fieldset> (since <details> is 
likely to also be used in forms), and that <figure>'s child elements 
being <dt> and <dd> is very non-intuitive compared to using <legend>.


On Mon, 14 Sep 2009, Toby Inkster wrote:
> On 14 Sep 2009, at 12:38, Anne van Kesteren wrote:
> > 
> > One thing I'm afraid of is that if people start using <details> before 
> > implementations are ready is that implementations can no longer 
> > provide the functionality of <details> natively. From that perspective 
> > I'm sort of happy authors cannot use it yet.
> 
> I take it you mean that if people start implementing the show/hide 
> functionality of <details> in Javascript, this would interfere with 
> native show/hide functionality?
> 
> This would be a reason to add <script implements> to HTML5. The HTML5 
> documentation would define a URI that represents the functionality of 
> the <details> element, say:
> 
>  http://www.w3.org/1999/xhtml/element#details

Search for "unreliable" in:

   http://lists.w3.org/Archives/Public/public-html/2009Jul/0685.html

...for an explanation of why feature strings are basically a non-starter.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 15 September 2009 11:04:45 UTC