W3C home > Mailing lists > Public > public-html@w3.org > March 2011

Re: example spec text for longdesc

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Fri, 25 Mar 2011 13:25:43 -0400
Message-ID: <AANLkTi=P+gye7rbdoQU3VTVZ6MFhxyXCOyMZbWiro+jZ@mail.gmail.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Cc: Henri Sivonen <hsivonen@iki.fi>, HTML Accessibility Task Force <public-html-a11y@w3.org>, HTMLWG WG <public-html@w3.org>
On Fri, Mar 25, 2011 at 8:26 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
> It's completely bogus in the case of MediaWiki, for example.  Take this
> randomly picked image from the front page of Wikipedia today.  The URL ends
> in .jpg, but it's to the image's summary page, not the image itself, and so
> this could actually be a perfectly acceptable URL for a longdesc (if the
> page actually contained a suitable description).
>
> http://en.wikipedia.org/wiki/File:San_Giacomo_di_Rialto_%28Facade%29.jpg

FWIW, we consider that a bug:

https://bugzilla.wikimedia.org/show_bug.cgi?id=4421

We've had anecdotal reports in the past that, for instance, Google
doesn't index MediaWiki file description pages because of this,
apparently with special exceptions for some high-profile sites like
Wikipedia.  I haven't personally verified these reports, but they came
from fairly credible sources.  Even if we fixed that, of course,
there's still nothing to stop article names from ending in common
extensions, like <http://en.wikipedia.org/wiki/Hello.jpg> (don't
worry, no pictures in that article!).  It's occurred to me that we
could add type="text/html" to such links to disambiguate them, if we
thought anyone would use that info . . .

Although anyway, yeah, you're right that extension sniffing is not
completely reliable.
Received on Friday, 25 March 2011 17:27:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:23 UTC