[whatwg] <summary> and <details> elements' specification

[Ian Hickson]

On Mon, 11 Apr 2011, Tomasz Jamroszczak wrote:
> 
> Instead of making <summary> inside <details> working as <legend> inside 
> <fieldset>, we can throw away the <details> tag and make <summary> work 
> like <label> element with form element.  There's no need for "open" 
> attribute, instead already existing "hidden" attribute can be used on 
> any HTML element. Clicking on <summary> adds or removes "hidden" 
> attribute from element with given id.
> 
> 	Here's default UA style:
> 
> summary {
>  display: list-item;
>  list-style-type: -o-disclosure-closed;
> }
> [hidden] {
>  display: none;
> }
> 
> 	Here's example HTML:
> 
> <summary for="detailsId">This is summary. Click to show/close
> details.</summary>
> <div id="detailsId" hidden>...</div>

I don't think this really captures the way disclosure widgets work. On 
platforms that support them natively, the disclosure widget, the summary, 
and the details are all one unit.


> Pros:
> 1. Simple to understand by web page authors - its representation and semantics
> play well together.

It's not clear to me that it's any clearer -- in particular, for="" is 
especially bug prone.


> 2. No XBL involved.

We'd still have to have a binding for the animation effects.


> 3. Nicely rendered by browsers not supporting <summary> tag.

Isn't it the same as on browsers that don't support <details>?


> 4. No quirky rendering.

Not sure what you mean here. Why would anything have quirky rendering?


> 5. Less keywords to memorize by web authors, reusing existing keywords 
> in semantically correct way.

It trades <summary> and <details> for <summary>, for="", id="", and 
hidden="". I'm not sure that's much simpler.


> Cons:
> 6. Error-prone for web developers using copy-and-paste method.

That's a big con. :-)


On Tue, 12 Apr 2011, Jukka K. Korpela wrote:
> 
> Just as <label> could have been defined to be paired with (by default) 
> its next sibling or, perhaps better, with the next input field, 
> <summary> could be defined to be paired with its next sibling or, 
> perhaps better, with the next <details> element, by default.

This kind of magic association is, IMHO, very confusing for authors and 
not at all good language design.


> The element name "summary" is somewhat odd, and would appear even more 
> odd if liberated from appearing inside <details>. This element is really 
> meant to be a control for rendering vs. not rendering the contents of 
> the <details> element, and its contents is just a label for the control. 
> The example at 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element 
> is accompanied with the note "In these examples, the summary really just 
> summarises what the controls can change, and not the actual values, 
> which is less than ideal." In reality, the example seems to correspond 
> to _normal_ expected use of <details>, so the name "summary" is 
> misleading. Perhaps <control> would be better, but as it's really a 
> special kind of control only, how about <open>?

The idea is to encourage people to give a summary.

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