ISSUE-93 Details change proposal discussion

Hi,

I’ve read some of the discussions and the various change proposals on this.

Here is my two cents on the issue. Hopefully, I’ll be able to add something
new, but it is possible that my argumentations will be similar to what’s
already been said.

I’ll start by looking at some of the examples available on details.

<details>
<summary>Get in touch</summary>
 <p>Interested in sponsoring? Get in touch.</p>
</details>

<details>
<summary>Name & Extension:</summary>
        <p><input type=text name=fn value="Pillar Magazine.pdf">
        <p><label><input type=checkbox name=ext checked> Hide
extension</label>
</details>

<section class="progress window">
<h1>Copying "Really Achieving Your Childhood Dreams"</h1>
 <details>
<summary>Copying... <progress max="375505392" value="97543282"></progress>
25%</summary>
 <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>
</details>
</section>

The first example is taken from Mr Bruce Lawson fine blog, [1] and the
others from the specification [2].

What I understand semantically speaking is that the details element is
trying to define a relation between some content and supplemental / optional
information on this content. That supplemental content cannot exist without
the parent content, but is optional to the page, though it can be necessary
to get that supplemental information or do a certain action in the context
of the page.

For this reason a default behavior is added so that the optional content or
form is not usable by default and must be activated either by a click on the
parent content or some other disclosure widget (the 10.4.3 [3] section of
the specification specifies a triangle, but does not specify how the widget
is activated click, focus, hover, we don’t know. I suppose it could be
specific to the type of user agent or the context)

The so called details of the example is not the enclosing details element,
but the various elements except the summary element. I find this confusing.
The summary element has weird semantics, it is the summary of what? The
details? I would think you could have a summary or title, then some content,
and then supplemental, or optional content, which is the details.

The specification itself is not helping here. I quote [1] :
“In these examples, the summary really just summarises what the controls can
change, and not the actual values, which is less than ideal. »

Then the summary is not a summary, but a description.

What if is some content can be defined as supplemental, details of some
other content. Should we use the details element? Clearly not, because the
details element is a widget / component, not an element that helps to
structure a document. We have been told not to use table for presentation,
but now, if we want an “activate to expand widget” we are told to use an
element that looks structural, but is not. You can use the semantics in it,
but only in the context of an activate to expand widget.

I think this is a very bad precedent and basically throws out the window the
principles of separating content behavior and presentation. I know that
there are elements with a mix of presentation and semantics (hr, i, br,
etc), but they are there for historic reasons, not as an example of good
language design.

Then there is the question of overriding the default behavior, the default
disclosure widget and presentation.

What if the author wants a plus sign instead of a triangle ? What if the
author wants to use hover instead of click. What about focus using
tabulations? Does details have a tab order setting? I suppose Javascript and
CSS could be used, but it defeats the purpose of having the details widget.
How would CSS be able to override the triangle with a plus sign? How would
Javascript not conflict with the default behavior? What are the
accessibility impacts of overriding the presentation and behavior ?

With these things in mind, I completely support Shelley Power’s change
proposal to remove the details element. The accessibility advantage that the
details element brings comes with too many strings attached to be benefic.
The details summary semantics are confusing and the examples in the
specification are themselves considered not ideal, which definitely shows
the difficulty in which the semantics can be applied.

If we want widget elements in HTML5, and maybe we do for accessibility
reasons, here is what I advise:
1) they should be completely separated them from structural elements
2) semantics should be left with the structural elements
3) they should have widget names (behavioral names like expandable)
4) If we want to mix behavior and structure, structure and behavior binding
should be explicit and easily overridable.

I understand that 1) 2) and 3) leads to elements that are similar to font
except that they are behavioral in nature instead of presentational. But if
easier accessibility is a necessity then maybe this is the way to do it. But
I am firmly against cramming false semantics into what is a behavior /
widget element. 4) Maybe could be done this way (note that this is only an
example and not completely fleshed out):

<optional>, <supplemental> or even <details> element

for attribute : contains an id for which the enclosing content is optional
(similar to the attribute for of  label) when not present the parent element
is used.

hasbehavior attribute: if present, the element uses a default user agent
behavior (in our case, adds a disclosure widget to the associated element. I
suppose that the disclosure widget would be different depending to what
element the optional element is associated to.

available attribute : same as the open attribute but a less visual name

Example

<table>
 <caption>Characteristics with positive and negative sides</caption>
 <thead>
  <tr>
   <th id="n"> Negative
   <th> Characteristic
   <th> Positive
 <details hasbehavior>
 <tbody>
  <tr>
   <td headers="n r1"> Sad
   <th id="r1"> Mood
   <td> Happy
  <tr>
   <td headers="n r2"> Failing
   <th id="r2"> Grade
   <td> Passing
</table>

 This would make the body of the table expandable by clicking a disclosure
widget. Could be that the caption is clickable or a small focusable area is
available just after the table head.

Another example :

<p>I have lived in the following countries:</p>
<ul>
 <li>Norway
 <li>Switzerland
 <li>United Kingdom
 <li>United States
 <li>Canada
     <p>In the following provinces :
     <details available>
     <ul>
        <li>Ontario
        <li>New Brunswick
     </ul>
</ul>

In this case, either the behavior is defined in javascript and the
presentation in CSS (creating the optional widget) or details is only here
for structural / semantic reasons.

In any case, I think that this way of handling details makes a better (if
not perfect) separation between structure and behavior, and is more
powerful. I don’t think that the current details element makes any of the
above examples easy. The markup is simpler too.

If anyone thinks this is a good / better way to handle a details widget I
could write a change proposal on this. Though it would have to have enough
support because my time is very very limited. I have not thought of the
content model, but it would be very interesting to do so… Still, I am not
sure if having a better details element is really better than to leave
behaviors with JavaScript... This is IMHO a high level design orientation
and if you are doing it for one element, it should be possible for many
others. This late in the process, I think this is not a good idea and should
be left for future versions of HTML or for HTML ongoing version.

Regards,

Benoit Piette
http://benoitpiette.com
http://w3qc.org

[1]
http://www.brucelawson.co.uk/2010/html5-details-element-built-in-and-bolt-on-accessibility/

[2] http://dev.w3.org/html5/spec/Overview.html#the-details-element
[3] http://dev.w3.org/html5/spec/Overview.html#the-details-element-0