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

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.

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."

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".

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.

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.

Shelley

Received on Tuesday, 23 June 2009 16:31:17 UTC