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

Re: example spec text for longdesc

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Sat, 26 Mar 2011 07:32:35 +0100
To: Laura Carlson <laura.lee.carlson@gmail.com>
Cc: Aryeh Gregor <Simetrical+w3c@gmail.com>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, Henri Sivonen <hsivonen@iki.fi>, HTMLWG WG <public-html@w3.org>
Message-ID: <20110326073235142395.6c1999f7@xn--mlform-iua.no>
Leif Halvard Silli, Sat, 26 Mar 2011 04:59:43 +0100:

> 2) Spec that longdesc URLs point to a fragment identifier
>    This might be a radical proposal. But perhaps be not.
>    Pros and Cons:
>         * In *effect*, such a requirement would, to a high degree, be a 
> guarantee that HTML5-valid non-rotten longdesc URLs leads to an 
> HTML/XHTML page. 
>         * A lot of current uses of @longdesc in the wild would be 
> invalid per HTML, including some valid uses. (However, I note on your 
> longdesc research page, that several of them do make use of fragement 
> ids. Especially those that have created a longdesc description page 
> which contains more than one longdesc. And I must ask: if the @londesc 
> points to a page, the won't e.g. a screenreader read the title of the 
> page and other possibly irrelevant stuf? Won't that be avoided if it 
> points to a fragment ID? Perhaps someone should test?) 
>         * It is probably good authoring practise to keep long 
> descriptions together in dedicated 'long description page', rather than 
> creating several pages - one for each image. Such an authoring practise 
> nearly gives itself as the logical thing as long as we require the 
> @longdesc to point to a fragment.
>         * Requiring a fragment ID is also inline with the CP's 
> emphasize that @longdesc need not be a on a different page, but could 
> point to a fragment ID on the current page.

I would like to also add these @longdesc=page#fragment benefits:

 * It allows to check that the URL points to a meaningful resource and 
that this resource exists (e.g. by using a link checker. [1])
 * Though http://example.com/image.png#fragment is possible, it is 
seldom done. And for anyone that would like to misuse @longdesc (to 
link to a larger image 'and still be valid' and similar stuff that it 
is easy to document that it has been misused for), it would be an extra 
barrier to have to add a fragment URL "in order to be valid".
 * One could, more clearly, give guides about how descriptions should 
be written. For example, I would claim that 
   this is better: <article id=description >Lorem ipsum</article>
        than this: <a name=description></a>Lorem ipsum.
   Simply because the former identifies the *entire* long description 
(the article), whereas the latter only identifies where the long 
description starts. Thus, in the latter example, if the page contains 
more than one long description, the user could {more} easily start to 
read the next long description for the next image. While in the former 
example, there is a natural end when the article ends. Also, in the 
former example, by utilizing the CSS :target selector, it would be 
possible hide everything on the page, except the description.

And another possible negative side to @longdesc=page#fragment:

   What if one wants to link to a page which has no @id or @name 
attributes? Answer: But is it then a description page? If the author is 
able to add a @longdesc then - if he/she controls the description page, 
it is no problem to add @id's/@name's to that page. If the other page 
*is* a description of the image, then the author should ask that the 
interesting page gets updated with a relevant @id.  I don't think it 
needs to be *valid* to to link to a page which doesn't have an @id that 
identifies the description.
  In my view it is actually a benefit if on has to link to a page 
fragment. It means that authors will not be able provide 'quick fixes' 
that doesn't really work.

[1] http://pauillac.inria.fr/~fpottier/bigbro/html/doc_20.html
leif halvard silli
Received on Saturday, 26 March 2011 06:33:09 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:34 UTC