Re: Request for group input on ISSUE-83 (figure and details captions)

Shelley Powers, Sun, 24 Jan 2010 21:46:42 -0600:
> On Sun, Jan 24, 2010 at 9:30 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>> On Jan 24, 2010, at 7:14 PM, Leif Halvard Silli wrote:

>>> I personally also don't find <summary>/<dsummary> a good name as a
>>> <details> caption. For example consider this example from the <table>
>>> section in the draft [2] (where I replaced <dt> with summary :
>>> 
>>> <details><summary>Help</summary> [.. explanation ..]</details>
>>> 
>>> There is no summary here?! It is just a very short label/identifier.
>>> (And as well: The draft only permits phrasing content inside the
>>> <details> caption - whereas <summary> invites to a full explanation - I
>>> certainly don't think of a summary as any shorter than a caption - on
>>> the contrary!)
>> 
>> Examples like this make me think <dlabel> (or similar) would be 
>> better than <dsummary> or <summary>. It is true that the spec calls 
>> this portion the "summary", but the way this type of UI element is 
>> typically used, the short version is a label for the longer 
>> contents, not a summary of them. This is pretty obvious with the 
>> screenshot examples in the spec: 
>> <http://dev.w3.org/html5/spec/Overview.html#the-details-element>. 
>> "General", "Name & Extension" and "Preview" are not summaries of 
>> anything, they are labels.
>> 
> 
> I have no objection to <dlabel>.

There are _two_ conditions that *could* make <summary> work: 

(1) It is used for both <figure> and <details> 
(2) One solves the problem of the proposed <summary> element for
    <table> simultaneously.

For more explanation of (1), see "Some considerations" below. Here I 
want to explain (2): One could bind <summary> and <caption> together, 
into a accessibility solution somewhat like Laura hoped for, simply by 
twisting what the draft currently says (under the heading "The caption 
element") about what should happen when a table element is the only 
content in a figure element: 

]] 
	the caption element should be omitted in favor of 
	the [figure caption]
[[

But instead of advising to drop one of the two captions, the spec could 
advice to use <summary> and <caption> for different purposes: The 
figure's <summary> could be used for reading advice about the table - 
especially for the accessibility audience - somewhat like @summary. 
While <caption> could be used as a caption for the entire <figure>. (Or 
opposite - I don't know what would be most logical.)

But of course, it is not the name <summary> that is most important 
here, but the presence of two captions that allow us to split their 
purpose. So if we want to solve this issue without mixing the table 
summary problem into this, then we should - at least for now - not 
choose <summary>. A name for a common caption element is not a problem: 
<about>, <cap>, <describe>, <info>, <subtext>.

Some considerations:

(1) If we cannot have just *one* caption element, then we should have 
just one *naming convention*. For example, both elements could contain 
the word 'caption' - <fcaption> and <dcaption>. I consider this the 
only option if we look for two elements. If we go for <fcaption> and 
<dlabel>, then authors will look in vain for any symmetry. The 
<fcaption> vs <summary> already breaks the principle of 
one-naming-convention very badly ... !

(2) If one is willing to accept *anything*  - even unsystematic naming 
- as the name of this/these caption element(s), then that doesn't 
exactly bode well for the fate of <figure> and <details> themselves ... 
Neither of those elements can be said to be ready for prime time 
without a decent and fitting caption element - it is an essential part 
of either of them. In many ways, the caption looks as the most 
important part of both <figure> and <details>.
-- 
leif halvard silli

Received on Monday, 25 January 2010 17:12:30 UTC