Re: Next issues to move forward on

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

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.

/ Jonas

Received on Thursday, 28 January 2010 05:32:53 UTC