RE: Taking another round at @summary

Lachlan Hunt wrote:
>
> The summary attribute is currently not removed all together.  It's in
> the spec and can be used.  Although it is considered obsolete, it's
> still technically conforming.  (Note that the validator will only issue
> a warning about its use, not flag it as invalid).

This particular point is both wrong and problematic. First, it is no longer 
obsolete (@summary being removed from that particular list earlier in the 
summer: http://www.w3.org/TR/html5/obsolete.html#obsolete), it is today a 
valid attribute for the table element, although as you note, in the current 
draft it is supposed to generate a warning in conformance checkers.  You go 
on to lament that 'non-agnostic' 'lock-in' is a bad technical decision, yet 
with the current draft should a content author working in HTML5 use @summary 
correctly, they will be 'Warned'.  How can one reconcile this obvious 
contradiction?  Since the attribute is conforming, no warning should be 
issued... unless it is the intent of conformance checkers and HTML5 to 
measure degrees of 'correctness'. Lachlan, you said it yourself: "This 
should be a clear lesson that [government] policies should avoid mandating 
specific technical solutions to problems..." Why should that truism not 
apply to HTML5 and the usage of @summary as well? There should be no room in 
a technical specification for editorial meddling.

>
> Any one of the alternative techniques listed in HTML5 for providing a
> table summary outside of a summary attribute has the potential to be
> equally,

OK, so you agree that @summary can be useful, although today there are 
equivalent tools/techniques that *might* be "equal" or better, yet none save 
@summary generate a "Warning".  What technical reason has prompted this 
warning requirement?

> if not more effective in some cases, so it should be clear why
> govt. policies creating such lock-in are bad.  Policies like you
> describe simply make the often incorrect assumption that the specified
> technical solution is the most appropriate in all cases, which is
> almost certainly not always going to be the case.

Can we use that same statement in regards to Jonas' suggestion that using 
aria-describedby should be used instead of @summary? Why is it wrong for a 
government policy to lock in to specific technical recommendations, yet it 
is not wrong for the specification to treat a technically valid solution as 
warranting a Warning? This very much seems to be shades of "Do as I say, not 
as I do."


> And I don't think we should
> let such clear mistakes in some govt. policies weigh too heavily on the
> technical decisions we make.

Technical decisions:

* Based upon correct use of the @summary attribute, it is useful and 
provides value to end users, as does other similar techniques.

* Current versions of today's browsers both support the @summary attribute 
with no known technical reasons indicating that it is difficult to implement 
or has security, privacy or performance issues. No specific technical reason 
has been advanced that would suggest that from a technical reason alone 
@summary should be obsolete, or even generate a 'Warning'.

* As Jonas Sicking has confirmed, at least one browser (Firefox) today will 
continue to support the @summary attribute into the future.

* Warnings should be reserved for when technical problems are present, they 
should not be used to advance a particular 'lock-in' position advocated by 
any particular bias.

* The effort (time, money and other resources) required to 'evangelize' 
correct usage of alternative techniques (such as aria-describedby) versus 
the effort required to 'evangelize' correct usage of @summary is roughly 
equal; the cost of going back and removing the recommendation to use 
@summary in both existing (and currently undergoing translations) W3C 
documents, not to mention external government polices and guideline 
documents is non-trivial - it costs real money to do that work, and for what 
real *technical* benefit?

No, it is pretty clear that this debate is not about technical issues, it is 
an ongoing conflict of opinion and politics, for if it were based solely on 
technical reasons, it would have long ago been put to rest.  In one recent 
exchange regarding @summary, the editor Ian Hickson, in one single email 
argued from personal opinion no less than 8 separate instances (including 3 
"IMHO"s and numerous "I think..."s) 
http://lists.w3.org/Archives/Public/public-html-a11y/2009Dec/0098.html
While people are free to have their opinions (informed or otherwise), the 
specification should, as you have argued, avoid locking into opinionated 
solutions in favor or agnostic and flexible language whenever possible.

JF

Received on Wednesday, 6 January 2010 17:51:12 UTC