Re: ISSUE-92 Change Proposal

On Mon, Apr 12, 2010 at 11:18 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Apr 12, 2010, at 7:57 PM, Shelley Powers wrote:
>
>> On Mon, Apr 12, 2010 at 7:40 PM, Tab Atkins Jr. <jackalmage@gmail.com>
>> wrote:
>>>
>>> On Mon, Apr 12, 2010 at 5:27 PM, Tab Atkins Jr. <jackalmage@gmail.com>
>>> wrote:
>>>>
>>>> I find nothing objectionable in this Change Proposal, and agree that
>>>> the example table used in the spec is somewhat contrived and
>>>> unrealistic.  The example table given in this Change Proposal seems
>>>> more realistic, exhibiting useful complexity without being
>>>> overwhelming.
>>>
>>> On second review, I have to retract my statement that there is
>>> "nothing objectionable".  The table itself is generally acceptable as
>>> an example of a table.
>>>
>>> However, I had skipped over the part where the @summary attribute is
>>> reintroduced, and given an explanatory paragraph.  That is not
>>> relevant to the Issue at hand, and given the current state of the
>>> @summary attribute, should be removed.  If @summary is later
>>> reintroduced as a valid attribute in HTML, the example may be amended.
>>
>> Rather than address this one before @summary, I believe the co-chairs
>> should resolve the issues related to @summary, first, and then we can
>> revisit this change proposal.
>>
>> Co-chairs?
>
> Here are some possibilities:
>
> 1) Adjust the current Change Proposal to be agnostic about the future
> @summary change, and then we can work it through the process without waiting
> for ISSUE-32. Then revisit whether to highlight @summary in the example
> after ISSUE-32 is settled. It tentatively sounds like that is more likely to
> get consensus in the short term.
>
> 2) Process the current Change Proposal as-is right away. It seems like at
> least Tab is objecting to that option, so we'd need a call for
> counter-proposals.
>
> 3) Keep this proposal on hold until ISSUE-32 is settled. Then either revise
> it, or process it as is, depending on ISSUE-32 resolution.
>
> I haven't consulted with my co-chairs, but personally speaking, option #3 is
> my least favorite. I prefer for things to move forward independently than to
> be blocked indefinitely with no clear deadline. The quicker we move through
> issues the closer we get to a quality spec that can move closer to Last
> Call. So I'll be real happy if we can work this one out sooner rather than
> later.
>
> Regards,
> Maciej
>
>

I can't adjust the text, it's about the table element. The only unique
attribute the table element has is summary. There is no agnostic way
to describe the table element without referencing its only unique
attribute. And the example, in which I tried to incorporate all
aspects of a table (with the edit that Laura asked for, and I still
need to make), also includes summary because it is relevant, as the
table is designed.

How could we make that table more accessible, without incorporating a
lot of unnecessary verbiage into the text surrounding the table? The
only way we have, is through the caption, the table headers, and the
summary attribute. Both the caption and the table headers are
insufficient for this example, hence, the summary attribute. It is the
_only_ way to attach this extra accessibility information _directly_
to the table element that exists today. We don't want to put it into
caption: it would come across as very silly.

I could change the text of the summary attribute if people don't find
it sufficient, but no one has said anything about the text in the
attribute.

The only change I would make to that entire section  if summary is
kept as "obsolete but conforming", is to add a note after the table
example that summary is obsolete but conforming, in similar style to
how this has occurred elsewhere in the specification. Sure that will
confuse people to no end, but that's the choice we'll have made, and
the appropriate edit to make under these circumstances.

Though I would be personally unhappy at this option, and most likely
would formally object, the addition of this note after the table
example would not add clutter to the section. We'll still have removed
the directives to people telling them what they need to write in their
text surrounding the table-- which is most definitely outside of this
group's scope.

Sorry, I just really feel we need to decide on summary, first, before
this change proposal can proceed. It is, in effect, blocked.

Shelley


As I wrote in the change proposal, we've beat the summary attribute
until it's almost glue. It's time to resolve this one. I just can't
see how I can do this section until it is.

Received on Tuesday, 13 April 2010 13:27:57 UTC