- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Sat, 26 Mar 2011 04:59:43 +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>
Laura, Laura Carlson, Fri, 25 Mar 2011 12:36:32 -0500: > Based on Lachlan's and Henri's feedback I deleted the sentence, > "Conformance checkers should issue errors if the longdesc URL has > certain file suffixes, such as .gif, .jpeg, .png etc.)", +1 This wasn't as simple as I must admit that I thought it to be. > I could put something like it back if people think it would be > useful to have it as a warning. Do you think that the example > spec text is better with or without it? Instead of suffixes, we could require the @longesc URL to point to a #fragment ID. Such a thing should be easy for conformance checkers to check for, and simple for authors to understand. And, instead of suffixes, we should define the exact format(s) of @longdesc resources. 1) Specify the longdesc resource format: HTML5 specifies quite exactly the format of img's src: "a valid non-empty URL potentially surrounded by spaces referencing a non-interactive, optionally animated, image resource that is neither paged nor scripted". And in a NOTE below that paragraph, it describes which image formats this includes (amongst them one page PDFs) and precludes. Note especially that @src cannot contain interactive images. That is: no links and - I think - also no linkable fragment identifiers inside the image. The format of @longdesc should be described in a similar way. Proposal: @longdesc MUST point to a XHTML or HTML file. What? Banning audio and video? Yes. Authors can add audio/video in the longdesc HTML file. Even if it works, we do not need to say that it is *valid* to let @longdesc point directly to a audio or video file - because such a thing would be of extremely minuscule benefit. 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. Summary - text proposal: Replace this: """ The URL references a separate document, a content fragment in a separate document, or content fragment within the same document as the image. """ With this: """ The URL references a fragment identifier located in a separate document or in the same document as the image. """ (I did not say "HTML document" - it probably should be emphasized some place though. In the text above, you could though place a link on the word 'document' to http://dev.w3.org/html5/spec/dom.html#html-documents . ) Thoughts? [1] http://www.w3.org/mid/20110326035116555453.bb398d1c@xn--mlform-iua.no -- leif halvard silli
Received on Saturday, 26 March 2011 04:00:18 UTC