- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 27 Jan 2010 21:32:00 -0800
- To: Shelley Powers <shelley.just@gmail.com>
- Cc: Maciej Stachowiak <mjs@apple.com>, "public-html@w3.org WG" <public-html@w3.org>
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