Re: Alternate proposals for ISSUE-83

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