- From: Shelley Powers <shelley.just@gmail.com>
- Date: Wed, 27 Jan 2010 23:15:15 -0600
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: "public-html@w3.org WG" <public-html@w3.org>
- Message-ID: <643cc0271001272115kd02025bye404bf5a3d8ca605@mail.gmail.com>
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 > > >
Received on Thursday, 28 January 2010 05:15:49 UTC