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

On Thu, Jan 28, 2010 at 2:05 AM, Laura Carlson
<laura.lee.carlson@gmail.com> wrote:
> 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?

If we all agree to make that decision, then no process is needed if
<table> is introduced. We just stick to the decision we all agreed on
earlier.

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

My recollection was the <summary> was proposed before the task force
was formed, thus surely at least that person was trying to solve some
problem?

/ Jonas

Received on Thursday, 28 January 2010 10:14:08 UTC