Re: Issues of @summary and use of data for "decisions"

Shelley Powers wrote:
> On Tue, Jun 23, 2009 at 11:02 AM, Sam Ruby<rubys@intertwingly.net> wrote:
>> Shelley Powers wrote:
>>> Before the teleconference this week, since @summary is the top agenda
>>> item, one of the issues associated with @summary is the fact that the
>>> HTML 5 sole author, Ian Hickson,  based his decision on pulling
>>> @summary (or I should say, collapsing it into caption) on data queries
>>> he made against Google's index.
>>>
>>> Though CSSquirrel addressed this issue humorously(1), several of us
>>> have expressed concern about decisions being made on proprietary data,
>>> especially since the use of proprietary data is counter to independent
>>> verification (2). I've been lectured on how HTML5 is derived from the
>>> use of scientific methodology(3), yet independent verification of data
>>> is an underlying component of true scientific research.
>>>
>>> Other data sources have also been queried, and the results have been
>>> used to challenge @alt, @longdesc, @summary, and other accessibility
>>> attributes. Focusing specifically on @summary, data queried from a
>>> couple of different sources, neither of which is all encompassing,
>>> shows that the @summary attribute is used incorrectly a significant
>>> number of times (4). This is then used as some kind of empirical proof
>>> that the @summary attribute should be pulled.
>>>
>>> Yet the same data also demonstrates that HTML tables are, themselves,
>>> used incorrectly. However, a decision wasn't made to eliminate HTML
>>> tables. Instead, text was added to the HTML 5 specification to clarify
>>> how HTML tables are used, in order to hopefully increase the accuracy
>>> of HTML table use. One then has to ask, why this same practice wasn't
>>> applied to @summary? Why wasn't clarifying text added to HTML5 in
>>> order to facilitate more accurate use of @summary.
>>>
>>> That's the problem with this process, and this practice: it is applied
>>> inconsistently, and used more to justify personal opinion than as a
>>> basis for a "best practice".
>>>
>>> The problem is compounded because the data is waved, like a flag of
>>> victory, in the faces of people who express concerns, or attempt to
>>> interject other opinions. More importantly, it is used to override
>>> those who are a), chartered by the W3C to specifically deal with the
>>> issues, and b) to undercut those with experience and expertise in
>>> accessibility. In fact, such experts are typically treated either with
>>> thinly veiled disdain, or out and out derision, if not directly in
>>> these lists, passively, and indirectly, in the WhatWG IRC(6).
>>>
>>> I don't understand the WhatWG disdain for people with years of
>>> experience and specialized training. Hubris comes to mind.
>>>
>>> Regardless, when moving forward on the topic of @summary, and the
>>> issue of "data" is brought up again, I hope that people keep in mind
>>> that the use of "data" as justification for decisions in HTML5 has not
>>> been without challenge, or controversy. A reference to "data" should
>>> not be used to end the discussions, nor should the reference to
>>> "data", by itself, continue to be sole justification for overriding
>>> other's concerns.
>> When I asked about font, I had a number of goals in mind - the primary one
>> being to assess whether "yanked" was an appropriate description. Looking
>> through the responses, the preponderance of the responses I saw focused on
>> with whether font was a good idea.  There was next to nothing said on
>> expectations set by prior specifications.  If anybody sees this differently,
>> please speak up.
>>
>> Even if my assessment is correct, that doesn't mean that no (as in zero)
>> weight should be given to prior specifications, but it does mean that we
>> should not treat as a given that things specified in the past are to be
>> carried forward.  Ian (and others) have asked for use cases.  I've seen
>> mention of other potential long term solutions that might do a better job
>> than @summary has done to date.
>>
>> I don't believe that data has been ever given as the sole justification in
>> these discussions.  There are people who have listened to the use cases
>> provided, and come to the conclusion that @summary is not the best solution
>> to the use cases provided.  When asked, data has been provided.
>>
>> I'd like this discussion to be based on something more than who has the most
>> years of experience.  Data, reason, and use cases seem to be a reasonable
>> way to proceed.  As does (but at a much lower weight) discussions on what
>> prior editions of HTML may have suggested.
>>
>>> Shelley
>> - Sam Ruby
>>
>>> (1)
>>> http://www.cssquirrel.com/2009/06/22/comic-update-who-really-is-the-wizard-of-html5/
>>> (2) http://lists.w3.org/Archives/Public/public-html/2009Jun/0204.html
>>> (3) http://krijnhoetmer.nl/irc-logs/whatwg/20090604
>>> (4) http://philip.html5.org/data/table-summary-values-dotbot.html
>>> (5) http://lists.w3.org/Archives/Public/www-archive/2009Jun/0026.html
>>> (6) http://krijnhoetmer.nl/irc-logs/whatwg/20090623
> 
> Sam, I disagree.
> 
> I did mention how there is a serious disconnect between HTML 4 and
> HTML 5 when it comes to "conformance", and how conformance is meant to
> be interpreted by HTML authors/editors, and user agents. I mentioned
> the disconnect between many times the user agent is also and author,
> with a shared API/data model.

I must confess that I'm not completely following what you said above.

I do believe that user agents can also be authors, and some of the APIs 
designed to accompany HTML 5 appear to support that goal; that being 
said, I have yet to hear one such tool author step forward and say that 
they believe that what they are doing would be precluded by HTML 5 being 
adopted.

As near as I can tell HTML 4 and HTML 5 have similar approaches to 
conformance.  I understand the point of view that a language with the 
goal of 100% interop no matter how ill-formed the content is is a quite 
different beast, particular with respect to author conformance 
requirements, than one that doesn't define error paths.  That being 
said, that point of view doesn't have consensus yet either.

And while I see both of the above, I don't see how that related to "yanked".

> We also ran into problems with the so-called "use cases" with RDFa. It
> would seem that no use case was sufficient. This one was too long,
> this one was too short, and so on. When we asked for examples of what
> makes a good use case, we were given a basic shoulder shrug.
> 
> "I dunno. I guess I'll see it when I see it."

Acknowledged.

> As for reason -- this group can't even agree on what to put in the
> Best Practices document. Why? Because the so-called "best practices"
> have been applied erratically, and, again, more to justify personal
> opinion and biases. The number one justification to wall HTML5 off
> from RDFa is Henri's repeated references to the best practices as
> "rules", yet we've had Ian say these are really more guidelines than
> "rules".

Design Principles are guidelines.  Henri does refer to them a lot.  And 
I don't see that as a bad thing.

> You're saying that all of this takes precedence over the advice given
> by experts in the field, as well as other W3C groups chartered to
> provide recommendations and advice...this counter to the very charter
> that supposedly forms the basis for this group.

Each of us are experts, just perhaps not over the same domain, or to the 
same level of depth.  I would like to see the various experts come 
together and discuss ideas, and spend less time comparing the lengths of 
their expertise.

> Seems to me that this working group's underlying practice is more to
> take the path of least resistance, than to create a new version of
> HTML that meets the needs of all people, not just a small group
> remarkable for the lack of diversity of its members.

I've seen quite a bit of discussions and controversy; I definitely 
disagree that the content in the current draft was formed as a 
by-product of following the path of least resistance.

  - - -

You (collectively) have seen me operate over an extended period of time. 
  I am quite willing to play devil's advocate.  I'd like to hear an 
answer that I can understand to the question of "why do we need @summary 
as opposed to something else or even nothing at all" that doesn't 
crucially depend either on "because it was in HTML 4" or "because I said 
so".  Both can be included in the answer, just hopefully the third (or 
forth or fifth) leg of the argument are substantial enough that the 
entire weight doesn't fall on the first two legs.

> Shelley

- Sam Ruby

Received on Tuesday, 23 June 2009 17:21:14 UTC