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

[Bug 10015] New: longdesc URL checking

From: <bugzilla@jessica.w3.org>
Date: Fri, 25 Jun 2010 21:15:54 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-10015-2486@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10015

           Summary: longdesc URL checking
           Product: HTML WG
           Version: unspecified
          Platform: Macintosh
        OS/Version: Mac System 9.x
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: xn--mlform-iua@xn--mlform-iua.no
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html@w3.org


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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 25 June 2010 21:15:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 25 June 2010 21:16:00 GMT