W3C home > Mailing lists > Public > public-html@w3.org > February 2010

Re: Feedback on using <details> as a replacement of summary="..."

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>
Message-ID: <20100218135852257148.4889ba5d@xn--mlform-iua.no>
Henri Sivonen, Thu, 18 Feb 2010 12:03:40 +0200:

> In reference to:

>> 	• 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 

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:

		<p>Table 1. 
		<p>This table shows [etc]

After change I foresee, it would have to be written:

        Table 1. 
		<details open>This table shows [etc]</details>

>> 	• 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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:58 UTC