W3C home > Mailing lists > Public > public-html@w3.org > September 2008

acceptable fallbacks [was: Re: Is longdesc a good solution? ...]

From: Jim Jewett <jimjjewett@gmail.com>
Date: Tue, 9 Sep 2008 15:34:51 -0400
Message-ID: <fb6fbf560809091234y1916d4d3hf20fd6a402c238d0@mail.gmail.com>
To: "HTML WG" <public-html@w3.org>, wai-xtech@w3.org

Henri Sivonen asked:

> Would this

   <video src=movie.ogg>Please upgrade to a browser
   that supports HTML5 video.</video><p>
   <a href=transcript.html>Annotated transcript</a></p>

> be a "hack"?

As a usability issue, please *at least* reverse the order.  Links
following a "Please upgrade your browser" messages are almost always
to downloads of the suggested browser or plugin.  (Alas, that
conflicts with the standard desired visual layout unless CSS is used
to reorder.)

> Is a semantic association between the <video> element
> and the  transcript necessary if the link is very near the video
> in the document reading order?

While the above is adequate, it is still a hack.  It relies on people
continuing to leave them together, and to recognize that they are
together, and to not have stronger prior assumptions about nearness.
It is still better than most existing sites; the question is whether
it would be worth an explicit annotation.

   <details id=mov1><legend>
     <a href=transcript.html>Annotated transcript of XYZ</a>
     </legend> ... </details>
   <video src=movie.ogg fallback=#mov1>
      Please read the transcript or upgrade to a browser that supports
HTML5 video.</video>

(For the moment, I am explicitly not taking a position on whether that
@fallback should be @alt, @longdesc, link@rel=alternate, etc.)

I'm almost inclined to say "no", because the final <source> element
could do the same job, if properly defined.

   <video src=movie.ogg>
     <source src=movie.ogv type="video/ogg">
     <source src=#mov1>
     Please upgrade to a browser  that supports HTML5 video.</video>
   </video>
   <p><a id=mov1 href=transcript.html>Annotated transcript</a></p>


-jJ
Received on Tuesday, 9 September 2008 19:35:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:23 GMT