Re: what is dt?

Laura Carlson wrote:
> Hi all,
>
> What about using a <summary> as a generalized element with <details>
> etc. Leif mentioned  this previously.
> http://lists.w3.org/Archives/Public/www-archive/2009Jun/0045.html
>
> On Fri, 05 Jun 2009 Leif Halvard Silli wrote:
>
>   
>> In our internal debates at the HTML4all.org initiative, ideas
>> about a generalized <summary> element was put forward. By
>> generalized, it was meant that it could play the summarizing role
>> both for <table>, <figure> and (perhaps) for <canvas>.
>>
>> The very idea about a <summary> element *only* for <table> has
>> already been presented for Ian, but the idea was put aside due to
>> serious DOM compatibility problems with current Web browsers. As a
>> response, I proposed to have the <summary> element /inside/
>> caption, however Ian responded that it was not clear to him that
>> it was necessary to distinguish the summary from the caption in
>> that way. Also, my HTML4all colleges did not support making the
>> summary feature dependent on presence of <caption> in any way.
>>
>> However, <summary> as child of <figure> (and <canvas>) should not
>> have the same serious DOM issues that <summary> as child of
>> <figure> has. <figure> even allows to move the table caption to
>> the caption of the <figure> element:
>>
>> "When a table element is in a figure  element alone but for the
>> figure's legend, the caption element should be omitted in favour
>> of the legend."[1] (In Ian's proposal, one would then move the
>> summary content into the legend, together with caption content.)
>>
>> And as long as a table doesn't have a <caption> element, then the
>> DOM problems of the <summary> element almost disappears. Hence, in
>> those cases when one move the content of <caption> to the
>> <figure>'s <legend> element, the use of <summary> as child of
>> <table> would not face the same level of DOM problems.
>>
>> Thus, if the working group decides that, in line with the WCAG 2.0
>> requirement, the summary feature needs to be a
>> "programmatically-determined mechanism"[2][3], the <figure> gives
>> us two options w.r.t. a <summary> element: <summary> could be a
>> child of <table> or a child of <figure>.
>>
>> In a summary: If we are not looking narrowly at the <table>
>> summary problem, but expand the problem to <figure> and <canvas>,
>> then it should be easier to introduce the <summary> element.
>>
>> [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#the-caption-element
>> [2] http://esw.w3.org/topic/HTML/SummaryForTABLE
>> [3] http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-programmatically-determined-head
>>     
>
>
> Best Regards,
> Laura
>
>   
This strikes me as an interesting proposal, and when it comes to Figure, 
has been proposed by others[1]. The rejection of the idea, because of 
how browsers currently implement the DOM for HTML4 puzzles me, since 
we're changing the DOM for HTML5, anyway. 

I am less concerned about issues related to browser companies having to 
change their code, than I am introducing levels of new confusion with 
HTML5. This specification should have, as its primary audience, the 
larger of the groups who are directly impacted by its contents, which 
would be the web developers/designers. The needs of the browser makers 
should be secondary.

I would rather a new element be defined, clean of past semantics, and 
used consistently regardless of container (and meaning the same thing, 
regardless of container), than to, frankly, bastardize an existing 
element, generating new confusion because of differing syntax, 
semantics, and behavior, all in the interests of being expedient.

I don't necessarily care that we use "summary", though the element name 
is logical, and hence more intuitive for web developers/designers.

Shelley

Received on Thursday, 17 September 2009 13:27:33 UTC