This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24594 - longdesc URL checking
Summary: longdesc URL checking
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML Image Description Extension (show other bugs)
Version: unspecified
Hardware: Macintosh Mac System 9.x
: P2 normal
Target Milestone: ---
Assignee: Charles McCathieNevile
QA Contact: HTML WG Bugzilla archive list
URL: http://dev.w3.org/html5/spec/embedded...
Whiteboard:
Keywords:
Depends on: 10015
Blocks:
  Show dependency treegraph
 
Reported: 2014-02-10 09:59 UTC by steve faulkner
Modified: 2014-06-13 18:07 UTC (History)
8 users (show)

See Also:


Attachments

Description steve faulkner 2014-02-10 09:59:52 UTC
+++ This bug was initially created as a clone of Bug #10015 +++

Probably as consequence of @longdesc having status as obsolete and non-conforming, Validator.nu does not perform any validity checking of th longdesc URL. Thus authors are not told whether they used it correctly or not - all they get to know is that it is wrong to use it.

HTML4 did not perform URL validity checking. And in the case of @longdesc, this has probly contributed a lot to the lack of understanding of how it works.

Meaningless or invalid URLs represents 96% of all errors linked to @longdesc. 
See Mark Pilgrim's blog post: http://blog.whatwg.org/the-longdesc-lottery
Hence introducing URL validity checking of @longdesc would be important.

Do the maths: 

(A) making @longdesc invalid will lead to 100% of all longdesc occurences becoming stamped as errors. 
(B) making it _valid_, but with strict URL checking, could in theory lead to 96% of all @longdesc occurences stamped as error

Hence we should perform proper URL validity checking rather than stamping all use as invalid - since this would in theory lead to the same error match.

Criteria: Due to the problems with incorrect use, I suggest that longdesc URL checking should be stricter than the URL checking that Validator.nu performs with regard to validity of the URLs inside @src, @href, @cite etcetera.

By stricter I mean that we should evaluate whether the things Mark Piligrim took up, should be invalid - or cause warning - in @longdesc, despite that it may not be considered an error to do the same in @src or @href:

* the empty string 
* pointing to the same URL as the src attribute
* pointing to the page you're already on
* pointing  to the root level of another domain (probably not possible to check)
* is the same as a parent link's href attribute 
   (i.e. the longdesc is redundant because you could just follow the image link instead)

One could also consider showing warnings or errors if the longdesc URL has certain file endings, such as .gif, .jpeg etc

One of Mark Piligrim's sources (http://wiki.whatwg.org/wiki/Longdesc_usage) showed that use of @longdesc as a word container is the largest group or errors: "12 pages used longdesc="..." not as an URL, but as a human-readable description"

It should probably be considered an error to use @longdesc on a presentational image. Thus, if the <img> has an empty @alt, the user should see an error, since such an image would (probably) count as having role="presentation", meaning that AT users would not see it.
Comment 1 Charles McCathieNevile 2014-06-13 18:07:27 UTC
longdesc defines itself as a valid URL, and there are tests in the test suite for that validity. Those tests are passed by the W3C validator, inter alia.

I believe this has therefore been fixed by the spec.