Re: ISSUE-93 Details change proposal discussion

Thanks to Benoit, I can now say that support Shelley with regard to 
<details>. <details>, as it stands, appears to me as a half baked idea. 
I am open to a "rebirth"  if its <details> improves is changed.

Benoit Piette, Sun, 2 May 2010 15:43:08 -0400:

  [...]

Focusing on what what you said about <summary> especially:

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

Indeed. How 'summary' links to 'details' is diffuse. The spec earlier 
had (as I remember) an example with an "i" (for "information") as the 
content of the caption/summary of <details>. Clearly, "summary" is the 
wrong word, unless we can interpret "summary" as merely synonymous for 
"caption", in which case <figure>'s <figcaption> should also be 
baptized <summary> - bug 9631. [1]

The spec currently uses another example: the Show Info panel for a Mac 
OS X files:

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

The text then says that:

]] One could use this in conjuction with other details in a list to 
allow the user to collapse a set of fields down to a small set of 
headings, with the ability to open each one. [[

I suspect it is meant something like this:

<ul>
  <li>
    <details>
      <summary>Name & Extension:</summary> 
        File.html
      </details>
  <li>
    <details>
      <summary>Preview:</summary> 
        <img src="Front_Cover_with_Cat" alt="Foo" >
      </details>
</ul>

But why not rather use a <dl> list? And skip the <details> entirely? 

<dl>
  <dt>Name & Extension:
  <dd>File.html
  <dt>Preview:</summary> 
  <dd><img src="Front_Cover_with_Cat" alt="Foo">
</dl>

Definition lists can also be used for glossaries. And interactive 
glossaries is a hot thing. Should I choose <details> when creating a 
glossary, just to gain "interactivity"? That seems like turning things 
on their heads.

Also: I strongly suspect that the XML file used in the Mac OS X's Show 
Info panel is pretty similar to a <dl> list. (I have only looked at a 
'Info.plist' file, which is an advanced Key/Value list - don't know how 
much it reflects the actual Show Info panel.)

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

When I think about the definition/description list example, then I have 
to agree with you. One should not have to change to another element, 
just because one want some interactivity. 

....
> If anyone thinks this is a good / better way to handle a details widget I
> could write a change proposal on this.
...

Yes, that would be a great thing. But one thing: You had an example 
with a <details> tag inside <table>. I suspect that Maciej would object 
to that as Safari is so allergic to any elements inside <table> - it 
spits them out. Perhaps it has to be an attribute solution?

Regardsless, I am not sure how it fits with Issue-93. We are now in a 
Proposal/Counter proposal situation. I think that you should consider 
supporting Shelley's proposal to remove Details, and then, after - or 
in parallel - develop a new solution which we can discuss.

Perhaps the chairs could shed some light? 

[1] http://lists.w3.org/Archives/Public/public-html/2010May/0004

-- 
leif halvard silli

Received on Monday, 3 May 2010 00:40:44 UTC