- From: Sam Ruby <rubys@intertwingly.net>
- Date: Tue, 23 Jun 2009 12:02:53 -0400
- To: Shelley Powers <shelley.just@gmail.com>
- CC: HTMLWG WG <public-html@w3.org>
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
Received on Tuesday, 23 June 2009 16:03:36 UTC