Henri Sivonen, Thu, 18 Feb 2010 12:03:40 +0200:
> In reference to:
>
http://www.w3.org/WAI/PF/HTML/wiki/Details_element_as_a_replacement_for_summary_attribute%2C_Feb_15%2C_2010
>
>> • Allow details as a child of table or caption
> [...] You can't introduce new children of <table> without ill
> effects in existing UAs. [...]
Another concern: Why should authors prefer either <table> or <caption>
as parent?
> P.S. What are "business reasons" for considering it unacceptable to
> have a visible description?
My suspicion: Same logic as for @summary. A <table> may need
@summary/<details> even when it doesn't have a <caption>. The business
reason: if one is only after an accessibility update of the page, then
adding a <caption> could be seen as a too drastic change, compared to
adding either <table @summary> or <details> directly in <table>.
HOWEVER: doesn't legacy compatibility concern means that there are even
greater risks if <details> is placed directly in <table> rather than in
<caption>?
An option would be to reserve @summary as back-up solution for these
"business reasons" cases.
> Note that the "Spec Changes" part of the wiki page fails to include a
> change to the parsing algorithm for making it possible to use
> <details> as a child of <table> in the text/html serialization. (I'd
> be opposed to changing the parsing algorithm on this point, though.)
The "Spec Changes" part also doesn't mention whether there will be any
changes to <caption>. I think there should be.
In my view it would be logical to place _all_ advisory content inside
<details>, and retain <caption> itself (that is: the content outside
<details>) as a pure caption feature. Thus all other block level
elements than <details> should be forbidden inside <caption>.
To exemplify with Ian's example in the HTML5 spec, which now reads:
<caption>
<p>Table 1.
<p>This table shows [etc]
</caption>
After change I foresee, it would have to be written:
<caption>
Table 1.
<details open>This table shows [etc]</details>
</caption>
>> • Replace the summary child element of details with a button.
>
> This seems like a bad idea to me, because <button> has pre-existing
> behavior that isn't designed for making <button> act as a disclosure
> triangle and the disclosure triangle label.
Can you mention any concrete issues? From my POV, <button> instead
<summary> sounds excellent.
--
leif halvard silli