Re: Next issues to move forward on

On Wed, Jan 27, 2010 at 11:32 PM, 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>?
>
> 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
>

Interesting suggestion, but no, this doesn't remove my objection to using
summary for the name.

If folks don't like dsummary, they could use an approach similar to
figcaption for figure, perhaps by using detlabel, or detsummary, or some
such thing. I believe there were other options given.

Shelley