W3C home > Mailing lists > Public > public-html@w3.org > June 2009

<font color="blue"> (was ISSUE-32)

From: Sam Ruby <rubys@intertwingly.net>
Date: Mon, 08 Jun 2009 09:10:31 -0400
Message-ID: <4A2D0DC7.2070906@intertwingly.net>
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:


This attribute is valid in HTML4.01, and that spec even contains a 
number of examples.


It even is reported to be supported by tools like JAWS and iCab:


But might be disabled by some:


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

Meanwhile, there exists a proposal to make summary attribute conforming.
Not mandatory or anything, simply optional:


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.


   * 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":


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:


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.


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:


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:


   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:


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:


   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.


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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:46 UTC