- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 15 Jul 2011 20:33:10 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 15 July 2011 13:33:10 UTC