Re: summary attribute compromise proposal

On Aug 4, 2009, at 3:45 PM, Maciej Stachowiak wrote:
> On Aug 4, 2009, at 3:29 PM, Roy T. Fielding wrote:
>> But the same people said that they would be satisfied by a reasoned
>> argument that shows it is useful and distinct from other HTML5  
>> mark-up.
>
> Can you cite a reference for someone saying that?

Yes, but I won't waste my time with denial-of-service questions.

> I think the case against summary is not that it fails to have any  
> use whatsoever, but rather that there is some evidence that, on  
> balance, as practiced, it does not promote good accessibility  
> outcomes.

Same with canvas, video, and script.  The evidence supplied was
selected to support a particular opinion and does nothing other
than demonstrate that some unskilled authors will misuse any
given element or attribute.  Moreover, the folks who are actual
experts on accessibility disagree with both the "evidence" and
the assumed outcomes, so all you are doing is restating a
poorly motivated opinion that is held by a very small minority
of HTML implementors.  We all have opinions.

The @summary attribute has a purpose which is not satisfied by
any of the alternatives.  Case closed.

>> So either there is no need for a compromise or those people intend to
>> stand by their personal opinion in spite of both the reasoned  
>> argument
>> and the actual needs of others.  In either case, the appropriate  
>> action
>> by the editor is to make no change to the existing HTML language,
>> since WG consensus only necessary to make a change to the previously
>> agreed definition of the language in HTML4.
>
> WG consensus (or valid decision process if consensus can't be  
> found) is needed for any decision. There is no "default to old spec  
> version" exception in the W3C Process.

I said "the appropriate action by the editor", not what is written
into W3C process.  There are a lot of things in W3C process that
are just assumed because they are inherent in the definition
of "editor".

If Ian wants to claim that he can change anything in HTML for
which no WG consensus has been obtained, then I'd like to see
him do so in writing to this list.

>>>> The opinion that summary is not usefully distinct from all other
>>>> forms of caption mark-up has been proven wrong.  Do you disagree?
>>>> If so, then refute my argument.  If not, then there is no need to
>>>> find a compromise of opinions and Ian should fix the offending text
>>>> before it is published as a WD.
>>>
>>> I think your example is a plausible use case, and I have no wish  
>>> to argue against it. My proposal doesn't take the position that  
>>> summary is never useful. It takes the position that authors  
>>> should be advised to consider alternatives to what we have  
>>> learned is an error-prone construct. I don't think your use case  
>>> refutes that position.
>>
>> My use case refuted that position because it demonstrates that
>> there are no alternatives.
>
> I don't believe you have demonstrated that. Even in your example, a  
> <caption> that's hidden from visual but not UAs via CSS would  
> satisfy the use case.

No, because the use case requires that the solution be
backwards compatible with deployed browsers that do not
support CSS and deployed authoring tools that already
support @summary for the defined purpose.

> Further, even if you demonstrated that there are no alternatives in  
> one particular use case, this would not demonstrate there are no  
> alternatives for any use case, nor would it refute the case that  
> the construct is error-prone.

Why would I need to demonstrate that there are no alternatives for
any use case?  What kind of logic is that?  And I certainly
don't need to refute that the construct is error-prone, since
proneness to error is only a rational design concern when
there is more than one alternative satisfying solution.  In any
case, none of the solutions offered by Ian were less error-prone
aside from the fact that they would be displayed to visual users
and thus subject to more "eyes" on the bugs.

> That being said, maybe a lot of the people who find summary  
> problematic will see your example and reverse their position.  
> Personally, I'm not holding my breath.

I am not holding my breath, either.  I will take note of their
hypocrisy, however.

>> It would therefore be an ERROR for a
>> validator to warn that the author should seek out alternatives
>> when those alternatives clearly do not exist.
>
> Is it an error to advise authors to use CSS layout instead of  
> layout tables, even though CSS can't necessarily replicate every  
> layout that is possible with tables?

I don't follow what you mean here.  A table that has no substantive
content could certainly be replaced by CSS, but CSS is not a substitute
for table in general.  I think such warnings have nothing to do with
validation (style tools like lint do not belong in standards).

>> If the WG insists on placing a warning on the use of @summary, then
>> I will insist on placing a warning for any use of javascript,
>> canvas, and whatever-replaces object/embed.  Those features offer
>> far more potential for error-prone constructs that might be more
>> accessibly implemented using other HTML elements.  I don't think
>> that's why we have validators, but if we are going to be pedantic
>> about opinions regarding language features then at least
>> we should be consistent.
>
> You're welcome to make such proposals separately. I'm not sure all  
> of those specific examples would get consensus. (I do think  
> <canvas> with no fallback should be a warning or error.)

Why do my proposals require consensus but Ian's proposals do not?

....Roy

Received on Wednesday, 5 August 2009 01:04:36 UTC