- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Mon, 3 May 2010 02:40:08 +0200
- To: Benoit Piette <benoit.piette@gmail.com>
- Cc: public-html@w3.org
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