- From: Sam Ruby <rubys@intertwingly.net>
- Date: Mon, 08 Jun 2009 09:10:31 -0400
- To: HTML WG <public-html@w3.org>
Topic: http://www.w3.org/html/wg/tracker/issues/32 With all the talk of "yanking" and what the PF-WG wrote: > We reject the argument that summary should be removed from the > HTML specification because it is not implemented on most web sites. > We note that accessibility is poorly supported on most web sites. The > wider web is not an example of good practice. With this email, it is my intent to explore the operational differences between the various positions I have heard on summary, and put forward a question which I hope will help clarify whether "removing" or "yanking" is even a relevant factor to consider. -- Question: Is it possible for a document to contain a summary attribute and be considered conformant to the HTML5 specification? On the face of it, this sounds like a true binary question permitting only two answers. And yet, HTML5 manages to find a third option: http://dev.w3.org/html5/spec/Overview.html#conformance-checkers-0 This attribute is valid in HTML4.01, and that spec even contains a number of examples. http://www.w3.org/TR/html4/struct/tables.html#adef-summary http://www.w3.org/TR/html4/struct/tables.html#h-11.5 It even is reported to be supported by tools like JAWS and iCab: http://diveintoaccessibility.org/20 But might be disabled by some: http://krijnhoetmer.nl/irc-logs/whatwg/20090604#l-969 I'd like to see some evidence backup up that assertion. I'm sure that it is a true statement as undoubtedly two expert users that have disabled the support for this feature can be found. But is that fact meaningful? Meanwhile, there exists a proposal to make summary attribute conforming. Not mandatory or anything, simply optional: http://esw.w3.org/topic/HTML/SummaryForTABLE/SummarySpecification Looking at "version a" in that proposal, the only operational requirement I see on existing browsers is contained on the last line: The summary DOM attribute must reflect the summary content attribute. As far as I can tell, that particular requirement is both redundant and not in dispute. I say redundant in that HTML5 specifies that all unrecognized attributes, "vestigial" or otherwise, are to be placed in the DOM. And I know of no existing browsers or plans to do otherwise. How do we close the gap between "downplayed error" and "optional but allowed"? Especially where the browser behavior is not in dispute. Let's look deeper. http://krijnhoetmer.nl/irc-logs/whatwg/20090604#l-1138 * Hixie thought it was pretty obvious that you had to evaluate whether proposals actually solved the problems they set out to solve OK, so that's a bit snarky. But lets overlook that for the moment. At first blush, we have plenty of "evaluations": http://esw.w3.org/topic/HTML/SummaryForTABLE But I must confess, all of it looks either optimistic (i.e., take the form that "this SHOULD work") or anecdotal (9 sites found on the web which actually used this attribute). With roughly ten years of data you would think that something we would have something better by now. In the following email are three things to consider when evaluating possible solutions: http://lists.w3.org/Archives/Public/public-html/2009Feb/0601.html Looking at these items, there are a number of assertions being made. Most notably by the third item. Yes, that assertion seems like common sense, but frankly so does the bulk of the content in SummaryForTable. We need something more than simple assertions. http://krijnhoetmer.nl/irc-logs/whatwg/20090604#l-971 http://krijnhoetmer.nl/irc-logs/whatwg/20090604#l-1095 So, while I do think it is fair to ask whether or not there is evidence that summary attributes are used correctly enough for users to actually pay attention to it, I believe it is also fair to turn that question around. What evidence is there that document conformance requirements (i.e. ones placed on authors and tools) are used correctly enough for user agents to actually pay attention to such requirements? I'll note that this is not the first time the question has been asked: http://lists.w3.org/Archives/Public/www-archive/2009Feb/0108.html An answer that the poeople who actually care about this issue, while being in the minority, care enough that these requirement needs to be supported doesn't sound to me like an approach that is obviously insane. To both cases mentioned above. Yes, even if the rest of the world ignores or abuses the feature. This line of reasoning would lead one to the conclusion that "author conformance requirements, in general: in. author conformance requirements downplaying summary in specific: out". A part of the answer to the above may be that tools may chose not to conform, and thereby give up any right to claim that they are conformant, but frankly that's a cop out. Let's explore the impact on a set of tools that demonstrably do wish to be conformant, namely browsers. Again quoting from the HTML 5 editors draft: http://dev.w3.org/html5/spec/Overview.html#editors Authoring tools and markup generators must generate conforming documents. Conformance criteria that apply to authors also apply to authoring tools, where appropriate. So... does this apply to APIs such as the following: https://developer.mozilla.org/en/DOM/table If so, does Mozilla have plans to remove the summary attribute from this page in order to become conformant with HTML5? I doubt that would be popular. If not, why does Mozilla get to keep this in but other tools must take it out? Even more generally, this is not the only controversial omission. Before proceeding further on this specific attribute, it makes sense to address a point that Henri Sivonen brought up: http://lists.w3.org/Archives/Public/public-html/2009Feb/0127.html If the WG wishes to develop a general policy for assessing the adoption of HTML 4.01 features into HTML5, I think applying the policy to <font color='...'> is a good test. I like that. Particularly as nobody can accuse somebody who supports "retaining" font color as being part of the "accessibility orthodoxy". Such accusations have proven to be a very effective way of polarizing and derailing the conversation in the past. http://diveintomark.org/archives/2009/03/21/accessibility-is-a-harsh-mistress It also has a significant bearing on the burden of proof on Issue 32. If it turns out that there is consensus that there should be a low bar for pre-existing markup, then the question as to whether summary should be "removed" is a valid one. If not, summary needs to be supported based solely on its merits. Finally, one last solution worth exploring. Removing all references to summary out of the spec and explicitly scoping the spec to the parsing rules and the elements and attributes defined in the spec, and explicitly endorsing the possibility of attributes and elements being defined elsewhere. So, as a first step, can I get people to express opinions on which of the following should apply to <font color="blue">: 1) It's a conformance error, such as it is today in HTML 5. 2) It's a a downplayed error at it represents vestigial markup. 3) It's conformant. 4) The HTML 5 spec should be silent on this matter. Note: I'm not asking for general principles or how to apply the above answer to any other question. It is quite possible that there might be some who feel that font should be a conformance error and summary should be conformant, or vice versa, or that the spec should address one but not the other. I'm simply asking about the color attribute on the font element at this time. - Sam Ruby
Received on Monday, 8 June 2009 13:11:13 UTC