Re: Next issues to move forward on

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

Any help in getting these three issues settled is much appreciated.
>
> Regards,
> Maciej
>
>
>