- From: Shelley Powers <shelley.just@gmail.com>
- Date: Thu, 14 Jan 2010 13:11:19 -0600
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, public-html <public-html@w3.org>
On Thu, Jan 14, 2010 at 1:03 PM, Maciej Stachowiak <mjs@apple.com> wrote: > > On Jan 14, 2010, at 10:46 AM, Shelley Powers wrote: > >> On Thu, Jan 14, 2010 at 11:57 AM, Maciej Stachowiak <mjs@apple.com> wrote: >>> >>> I have recorded the three alternate proposals for ISSUE-83 on the issue >>> status page. We're not facing a timeout now, but I left the deadline of >>> January 16th on the page in case any additional Change Proposals for this >>> issue are submitted. >>> >>> Regards, >>> Maciej >>> >>> >>> >> >> As happened with the Microdata change proposal, should I then respond >> to the alternative and counter proposals? > > You should feel free to update your original Change Proposal at any time to > respond to new arguments. > > In terms of formal process, here's what I expect is going to happen: > > 1) Most likely, no one will write a "zero edits" Counter-Proposal by the > deadline. > 2) At that point, we'll essentially be decided to get rid of <dt>/<dd> for > <figure> and <details>, but with multiple options for what replaces them. > 3) My hope is that in follow-up discussion we can pare down the options. My > hope is that we'll find a single option which is most preferred by the > Working Group, and agree that we can get behind it without having a formal > bakeoff. > 4) If we do get down to a single preferred option, I think there are > reasonable odds that the editor will just adopt it, leading to an amicable > resolution, and sparing us the work of a formal Working Group decision. > > If things do indeed go down that way, then we may not need to do a formal > round of revisions to the Change Proposals. On the other hand, if even after > discussion there are multiple proposals with serious backing, then we may > have to use a straw poll or similar mechanism to make the call. > Incidentally, since I wrote one of the proposals and contributed to others, > I am hoping the other two co-Chairs can do the adjudicating if we need to > decide among multiple options even after discussion. > > > Incidentally, now is a fine time to start discussing the possible > replacements for dt/dd. Right now on the table we have: > > A) Use <fltcap> as the caption for both <details> and <figure>. No special > body elements. [Submitted by Shelley Powers] > B) Use a caption="" attribute on any element as the caption for <figure>, > with no special body element. No change for <details>. [Submitted by Tab > Atkins] > C) Use <fcaption> as the caption for <figure> and <dlabel> as the caption > for <details>. No special body elements. [Submitted by Maciej Stachowiak] > D) Use <fcaption> as the caption for <figure> and <dlabel> as the caption > for <details>. Use optional <fbody> and <dbody> respectively for their > bodies. [Submitted by Tab Atkins] > > We may get more proposals by the deadline, but it would be totally fine to > start discussing the submitted ones now. If anyone (including and perhaps > especially the various Change Proposal authors) has an opinion on which of > these replacement solutions they like best, and which they strongly dislike, > that would be valuable input. > > > Regards, > Maciej > > > I'll pull my fltcap suggestion. I don't have a strong view on naming elements, and your proposal for a separate caption element for each figure and details sounds good to me. I have no problems with the names you picked, either. The only alternate proposal I can't support is the one by tab, with the caption attribute. One reason is I really don't like boolean attributes. More importantly, though, is that he didn't address what will happen with details, which leaves a gap if dt/dd is no longer being used with details. That strikes me as an incomplete proposal. Also note that the reason I'm somewhat indifferent about what to call the captioning element is that I have other issues related to both details and figure that would make the need for a captioning element moot. Therefore, other than the issue with Tab's counter, which doesn't provide a replace for dt/dd in details, I don't have any preference, one way or another. I don't see that also creating a body element buys us anything, which is Tab's D option (and one I just noticed). Therefore, I support C. Shelley
Received on Thursday, 14 January 2010 19:11:48 UTC