Letter to the Team Contact - ISSUE-30.

Mike Smith,

I write to you as Team Contact, about my concerns with regard to the 
HTMLwg Decision on ISSUE-30:
http://lists.w3.org/Archives/Public/public-html/2010Aug/att-0112/issue-30-decision
A CC goes out to the HTMLwg co-chairs, to public-html@ and www-archive@

My time is limited, so if you feel that some issues are 
under-documented, then please tell me and allow me to follow up.

Concerns
--------

1) Errors in the decision document

The are many errors in the decision document - some of which the chairs 
have already admitted to. The document fails to make an accurate 
summary of many many things. Examples: Firefox is listed as a 
"successful" implementation of @longdesc, despite that Jon's objection 
state the opposite. And a few successful implementations that _are_ 
listed in the objections, are omitted as such examples in the decision 
document: Jaws, iCab. And Charles's presentation of @longdesc (in his 
objection to the zero-change proposal), is presented as if he says that 
@longdesc is the only way to technically link to a long description. 
These and a few other errors (which probably are just errors and not 
conscious errors) are easy to check simply by reading the relevant 
objections and proposals, undermines the trust in the decision as a 
whole.

2) Criteria for use of certain words

The decision demands things of the change proposers and objectors, 
which the decision fails to live up to itself. One of those demands are 
very specific criteria for the use of certain words. Example: the 
decision (unduly, in my view) complains about lack of definition of 
«the adjective "successfully"» (which is a an adverb, btw ...). 

However, the decision itself operates with several words for which it 
provides no criteria. Examples: 'use case' and 'require'. It is 
entirely unclear what kind of 'use case' the document wants, though, 
for the most part, the document seems to look for technical reasons to 
have @longdesc. 

To my mind HTML4 describes a use case: [1] "a link to a long 
description of the image. This description should supplement the short 
description provided using the alt attribute.". There are no links in 
HTML4 or HTML5 other than @longdesc that have this semantic. As such it 
@longdesc is required. (The proposal to keep @longdesc duly links to 
HTML4, and so the decision have every reason to discuss what HTML4 says 
- but fails to do so.)

3) Concerns not being duly considered

Example: Longdesc link rot was cited as a problem both in the 
objections, in the zero-change proposal _and_ in the decision document. 
In my objection, I pointed out that this - in a way - automatically 
becomes solved as soon as @longdesec is made valid: by making @longdesc 
un-obsolete, HTML5 conformance checkers must - obviously - start to 
conformance check the @longdesc URL. (Explanation: in the HTML4 
validator, no URL validity checking is performed whatsoever, whereas 
validator.nu does check URLs, as long as the attribute isn't 
obsolete.)  

I filed a bug about this, to make sure that conformance checkers would 
do this, and the link to the bug is in my objection. 

However, not a single time does the decision document that it has 
considered this simple and obvious argument. Instead, the decision 
document states it to be "uncontested" that "more work is needed to 
make longdesc useful". However such a general statement is hardly 
relevant when the required work, at the most basic level, simply 
involves moving @longdesc from the list of obsolete attributes to the 
list of valid attributes.

4) No evaluation of @longdesc from a semantic angle

This goes back to my 'use case' critique under 2) above. In the 
subsequent debate, I took up an idea that I picked up from Lachlan. 
Namely that rel="londesc" (<a rel="longdesc" href="*"><img alt="short 
description" src="*"></a>) many times could be used as a  replacement 
for the @longdesc attribute. (The exception being when there is already 
a link on the IMG. Another exception is on iframe elements, which HTML4 
also allows: the <a> element is not allowed to be a wrapper around an 
iframe element.) The response has been that rel="longdesc" is worth 
looking into. If we see @longdesc as shorthand for the - yet undefined 
- rel="longdesc" micro format, then should be obvious that the issue is 
about semantics.

(In my objection, I compare @longdesc with a special kind of link, 
although I fail to mention the rel="longdesc" parallel.)

However, the only time the decision uses the string "semantic" is when 
it states the following: "A number of use cases for semantically rich, 
structured descriptions of images were provided, however those use 
cases are abstract and don't directly and specifically require the 
support of a longdesc attribute".

By this definition, then even what HTML4 says about @longdesc is 
abstract! 

Apart from the situations when <img> already has a link as well as the 
<iframe> use case (see above), then it is probably impossible to find 
concrete examples of use cases when it is _technically_ impossible to 
solve the problem unless the language includes @longdesc. However, 
_semantically_ the language currently has no other method than 
@longdesc for solving the issue. But I look in vain for a discussion of 
this problem in the decision document.

[1] http://www.w3.org/TR/html4/struct/objects.html#adef-longdesc-IMG

This letter of concern is mostly a summary of points I have made in the 
following letters:

http://lists.w3.org/Archives/Public/public-html/2010Aug/0117
http://lists.w3.org/Archives/Public/public-html/2010Aug/0119
http://lists.w3.org/Archives/Public/public-html/2010Aug/0128
http://lists.w3.org/Archives/Public/public-html/2010Aug/0129
http://lists.w3.org/Archives/Public/public-html/2010Aug/0140

With regards,
Leif Halvard Silli
HTML WG Invited Expert

Received on Friday, 13 August 2010 13:24:13 UTC