<summary> not for table (was Re: Next issues to move forward on)

On 1/27/10, Jonas Sicking <jonas@sicking.cc> wrote:
> On Wed, Jan 27, 2010 at 9:15 PM, Shelley Powers <shelley.just@gmail.com>
> wrote:
>>
>>
>> On Wed, Jan 27, 2010 at 9:57 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>>>
>>> The Chairs would like to move more issues forward in the process. Here
>>> are
>>> the ones we are currently concentrating on:
>>>
>>> ISSUE-27 rel-ownership
>>>    - Two concerns were raised about this proposal (registry licensing and
>>> advisement to use a Web-based development process), but Mark Nottingham
>>> seems to have addressed both. We'd like to ask Tantek and Henri to verify
>>> whether their concerns are sufficiently addressed.
>>>    - If existing concerns are addressed, and no new objections come up,
>>> we
>>> will assume there is no need to call for counter-proposals. Instead we
>>> will
>>> seek amicable resolution (if Ian is willing to just go ahead and make the
>>> change), or issue a Call for Consensus on the submitted Change Proposal.
>>>
>>> ISSUE-66 image-analysis
>>>    - From discussion, it seems like there is a good possibility that we
>>> can come to a compromise agreement and settle by amicable resolution.
>>> That
>>> would be the preferred outcome. We're looking to Ian to propose some text
>>> that could be generally agreeable based on the discussion.
>>>    - If we don't come to amicable resolution, then we will likely call
>>> for
>>> counter-proposals / alternate proposals, since there was at least some
>>> disagreement voiced with the original proposal as written.
>>>
>>> IMAGE-83 dt-dd-semantics
>>>    - We seem to have near-total agreement on an amicable resolution to
>>> this issue, with one sticking point. Namely, Shelley objects to using
>>> <summary> as the element that holds the caption/label/summary of
>>> <details>,
>>> while Ian would prefer to use that to his second choice, <dsummary>. We
>>> will
>>> ask one last time if either is willing to live with their less preferred
>>> option, and if so try to settle this by amicable resolution.
>>>    -  If neither is willing to back down, then I will make a final
>>> adjustment to my Change Proposal and ask the other two Chairs to take the
>>> next action. It is likely they would call for consensus on it at that
>>> point.
>>>
>>
>> I have already compromised on this issue, by being willing to give up the
>> idea of a caption that could be used with many elements, given a name of
>> fltcap. I was willing to go with separate elements for both figure and
>> details, and was willing to go with the options given, except summary for
>> details. I stated that summary already exists as an attribute for the
>> table
>> element, is an attribute that has had considerable discussion in the last
>> few years, and probably in the future, and that creating this new element
>> with the same name will generate confusion.
>> In response to the mention that there are other element/attribute name
>> pairs, my response was that with these pairs, the purpose of the
>> element/attributes was the same or similar, but the same could not be said
>> about the summary attribute for the table element, and a captioning
>> element
>> for the details element.
>> In addition, as Laura Carlson also pointed out[1], one suggestion still
>> under consideration as an alternative for the summary attribute was a
>> summary element in the table element, performing the same function of the
>> summary attribute. I do not believe this alternative has been officially
>> rejected, and the use of summary for the details element abrogates this
>> previously existing alternative under consideration for the summary
>> attribute. And again, a summary element unrelated to previous discussions,
>> will cause confusion.
>> From what I've been able to deduce from the discussions, the reason for
>> using summary seems to be more one of personal opinion, than anything
>> based
>> on technical merit[2]. The fact that summary "reads nicely" is a
>> subjective
>> reason, rather than a reason based on technical merit[3]. The objections
>> to
>> something like dsummary seem to be primarily one of the use of the letter
>> to
>> differentiate the element from the summary attribute--a matter of
>> aesthetics.  However there is precedence in HTML for this type of naming:
>> iframe, thead, tbody, and so on. I would think it preferable to use this
>> approach than using a name that has had such discussion and debate in the
>> HTML WG for months, if not years, and which does not share a similar
>> purpose. Moreover, one that is still under active debate as an
>> accessibility
>> alternative to the summary attribute[4].
>> I feel that I have compromised, considerably, in this issue, and have
>> given
>> sound arguments for my objection to the use of summary. I have no interest
>> in this going to a poll, and ask the HTML5 editor to join me in
>> compromising
>> in order to achieve consensus.
>> Shelley Powers
>> [1] http://lists.w3.org/Archives/Public/public-html/2010Jan/1191.html
>> [2] http://lists.w3.org/Archives/Public/public-html/2010Jan/1187.html
>> [3] http://lists.w3.org/Archives/Public/public-html/2010Jan/1188.html
>> [4] http://esw.w3.org/topic/HTML/SummaryForTABLE#head-1d4cc386df3edd130dd677e056ba2bf98961145a
>
> How about using <summary> for now, but deciding to change the name if
> we indeed adopt a <summary> element for <table>?

What would the process to reverse that decision entail?

> I'd also note that I in a recent email asked what the purpose of a
> <summary> element under <table> would solve, that isn't solved by the
> aria-describedby attribute. No reply to this question has been sent
> yet, though it wasn't very long since I posed the question so one
> might still appear.

The accessibility task force has not discussed <summary> yet. I copied
Tab's earlier email [1] to the group and am doing the same with this
email.

[1] http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0284.html
Related:
<summary> email
http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0280.html
Draft Accessibility Consensus Procedure
http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0302.html

Best Regards,
Laura
-- 
Laura L. Carlson

Received on Thursday, 28 January 2010 10:05:57 UTC