Re: Issue 30 (Was: RE: Getting HTML5 to Recommendation in 2014)

Sam Ruby, Thu, 20 Sep 2012 19:15:09 -0400:
> On 09/20/2012 06:51 PM, Roy T. Fielding wrote:

W.r.t. the 10.000 top most Web sites question:

>> Regardless, I would strenuously object to any conformance requirement,
>> on any element or attribute, that is based on what kind of page is
>> intended.
> 
> The position that a validator should indicate via warnings that a 
> particular sequence of markup that it encounters is not one that is 
> widely interoperable is one that I would reject out of hand.
> 
> That being said, I can see how some would see that as less than 
> desirable, and to those people I would suggest that options that lead 
> to authoring expectations matching reality would be preferred.

I consider your thought about 'restricted' use as some kind of 
compromise proposal: May be you could limit it to that section. And the 
spec *could* say that @longdesc should be used that way - in fact, the 
spec sometimes has requirements that requires good faith authoring, to 
be met. Validators can't tell us. But what would such limitation help? 
Would you then say "OK, less broad vendor support would by OK" ? Or is 
that an argument for letting it reside in a 'extension spec', alone? Or?

However, we must *all* - including Mark Pilgrim -  ask ourselves, 
honestly: 86 files out of 10.000 contained 1938 longdesc matches. 1938 
matches in 86 pages - if those pages had been 'restricted' study 
material pages where longdesc had been used correctly, then it would 
still have been a quite stressful longdesc experience.

It is said that @longdesc is only seldomly needed. But most times when 
it is used, then it is seems to be used by some to tool that 
auto-inserts it.

But Steve's numbers are almost self explaining: the 1938 matches in 86 
files are not not used for a conforming way, and most of them are 
probably not even meant to be conforming in anything but the name. And 
by that I mean that, before HTML5 and before the data-* attribute 
construct came, then, when authors needed to include an extra URL (for 
example a large and small version of the img), then they looked and saw 
that, according to the DTD, the @longdesc contained a URL.

This can be seen in many, many JavaScript libraries and probably in 
other libraries. They don't intend to use it correctly. And of those 
few images I inspected in Steve's 86 files, most of those @longdesc 
attribtues seemed to contain images.  In addition to that non even 
attempted correct use, I have also found one open source photo album 
that, in an very early version, placed textual content inside the 
@longdesc. I discovered these things when I contributed to Laura's 
search for @longdesc implementations. (However, I have not made a list 
of it.) This misuse may not have ended yet - during the last 2 years, I 
became a Twitter friend with one guy who makes a such JavaScript 
library ... and I did not manage to convince him to stop, at least not 
then.

It is almost as if I simply *have* to subscribe to Henri's irony about 
the 'validate, validate, validate' mantra, because I think the desire 
to validate is lot of the reason why @longdesc fell in to misuse. When 
Mark Pilgrim rolled the longdesc lottery, it was only to ridicule: A11Y 
folks - "those idiots" - got to pay for the above misuse. But I think 
it is time to agree that *that* was a little bit simplistic.

That said: Part of the answer why @longdesc has (seemingly peacefully) 
rotted, has got to be that so few suffered from it plus that they who 
suffered were unable to tell (the were users, not spec lawyers) or 
unable be heard. However, if e.g. blind JAWS users don't suffer from 
this, then it got to be because they don't surf the 10.000 most popular 
pages (e.g. - and not be unpolite - may be photo albums are not the 
most popular part the Web for the blind audience), or because JAWS has 
heuristics or similar to not render the uselessest longdesc links.

The massive misuse causes:

A. confusion - e.g. within the HTMLwg ...  
B. bad reputation: they function badly as 'view source' examples
C. bad usability: as used in 'the wild', they may confuse users
D. bad habit: they are part of an authoring habit that seems hard
   to break since the habit has found its way into libraries
E. the HTML5 validator would not be able to catch all errors
   (not unless it is made very suspicious, at least)

When evaluating against a name change, the above must be weighted 
against 

1. First and foremost: whether it is better to deprecate the entire
   feature. Thus: A failure to change the name *could* imply 'death'
2. the widespread implementation of @longdesc in authoring tools
   (ironically, I *think* those tools, such as browser based
   CKeditor, are *not* the cause for the soup described above)
3. the widespread AT support for @longdesc
4. whether the misuse matters to the audience (if not, then this
   in and by itself *could* be a 'restricted usage' argument)
5. whether a validator test that catches most of the current errors
   could be defined (e.g. change allowed value to a hash name, if
   not in the extension spec then at least in the main spec - this
   would also make it simpler to offer something to browsers which
   do not support @longdesc)
6. whether name change increases chances for vendor buy-in
7. whether name change would be simpler to turn into a global attribute

So - hm - may be the 'restricted' path is worth considering. Especially 
if we don't go for a name change. See point 5 (allow only #hash name in 
main spec, but allow full URL in extension spec). 
-- 
leif halvard silli

Received on Friday, 21 September 2012 00:41:09 UTC