- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 16 Feb 2010 20:49:36 -0800
- To: Cynthia Shelly <cyns@microsoft.com>
- Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
- Message-id: <0A2A2CDF-E7D4-4BA7-B234-91D9C759495E@apple.com>
Hi Cynthia, On Feb 16, 2010, at 8:31 AM, Cynthia Shelly wrote: > This is my change proposal for replacing summary with details, as we > discussed on last week's call. Please put this on the agenda for > Thursday. > > http://www.w3.org/WAI/PF/HTML/wiki/Details_element_as_a_replacement_for_summary_attribute%2C_Feb_15%2C_2010#References > <tableexamples2.html> This is really intriguing to me, because I think the idea to recommend <details> as a replacement for @summary has the potential to get a lot of support from the full Working Group. I do have one concern with my co-chair hat on, thinking about how we'll handle this proposal in the full Working Group. This proposal suggests to "Replace the <summary> child element of <details> with a <button>. I would advise against including this change. The proper elements to use for the captions of the <details> and <figure> elements were subject to much discussion and controversy, culminating in ISSUE-83, which drew a number of Change Proposals: <http://www.w3.org/html/wg/tracker/issues/83 >. In the end, ISSUE-83 was resolved by amicable resolution. The amicable resolution was to adopt the <summary> and <figcaption> elements respectively for <detail> and <figures>. The Call for Consensus on this amicable resolution closed on February 11, with no objections: <http://lists.w3.org/Archives/Public/public-html/2010Feb/0344.html >. I note also that in much of the discussion on this topic, a key consideration for many was to *not* reuse any existing HTML elements; it was strongly preferred to mint new elements. We can't change the name of the <details> caption yet again without reopening ISSUE-83. Per the Decision Policy ISSUE-83 can be reopened with permission of the Chairs, and the A11Y TF is free to request that permission if the TF feels strongly about this change. However, I have two requests: 1) If the A11Y TF wishes to reopen ISSUE-83, then please produce a separate Change Proposal just for ISSUE-83. I think it would not be good form for a Change Proposal on an open issue to have the side effect of reopening a resolved issue. It seems to me that doing things that way does not give due notice to the Working Group that the issue is being reopened, or a fair chance to review the new proposal in isolation. 2) Please consider the option of dropping <summary>/<button> change entirely. I think it would not help the smooth functioning of the Working Group for the A11Y TF to ask to reopen closed issues. It took a lot of effort to bring ISSUE-83 to a successful conclusion, and I would be very hesitant to reopen it, given the risk of damaging our hard-won consensus on the topic. There's probably more purely technical feedback that could be given on your Change Proposal, but I wanted to make sure to highlight this process issue. Other than this one small point, I think this Change Proposal is a very promising direction. Regards, Maciej
Received on Wednesday, 17 February 2010 04:50:11 UTC