- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Thu, 18 Feb 2010 13:58:52 +0100
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: "public-html@w3.org WG" <public-html@w3.org>
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
Received on Thursday, 18 February 2010 12:59:28 UTC