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

James Graham jgraham at opera.com
Mon Apr 11 06:58:30 PDT 2011


On 04/11/2011 03:40 PM, Tomasz Jamroszczak wrote:
>
> I've got another proposal for making <summary> and <details> easier to
> implement and - what's more important - easier to understand and thus
> easier to use.
> 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>

That seems much harder for authors. In particular having to maintain the 
id references would be harder, not just for copy-paste. That sort of 
structure should only be used when it is really needed for the extra 
flexibility, but in this case is is clearly not; the possibility of 
having multiple elements between the disclosure element and the thing it 
discloses seems unnecessary.

I also imagine that in this case the author would typically wrap the 
whole structure in an extra <div> to get the grouping they want. They 
would then style the element in such a way as to reproduce something 
like the default styling proposed for <details>. So that part would 
shift complexity from implementors to authors, which is bad.

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

fwiw I find this much harder to understand; it depends on lots of low 
level mechanics rather than on a simple declaration.



More information about the whatwg mailing list