Re: LONGDESC: some current problems and a proposed solution added to the wiki

I concur with these sentiments for a <picture> or similar.

Ian Hickson asked we define issues - real issues and not "X is omitted
from spec"

I ask if this is the kind of issue analysis required. I'm reluctant to
edit the wiki without getting a feel from the mailing list first.

The issue: fallback mechanisms are required for embedded content. (I
trust I don't need to repeat the reasons why here, our design
principles cover this from many angles).

Let us not assume (yet) any proposal is correct.

HTML 4 has:
1. <img>: @alt for short (text only) embedded alternatives and
@longdesc for rich (HTML) alternatives accessible via URI.
2. <object>: fallback content (HTML) within <object>
Note that these two fallback mechanisms are different.

HTML 5 draft currently proposes:
1. <img> with @alt (currently does not include @longdesc)
2. <object> - same as HTML4
3. <embed> with NO fallback mechanism
4. <video> and <audio> with (HTML) fallback derived from content
5. <figure> (with any of the above) provides <legend> for captions

Note that video/audio use the same mechanism as object, embed offers
nothing, figure adds something new and img has lost its (explicitly
defined) richer fallback mechanism.

When I read this spec, it means this to me: Aha, new elements. Aha,
fallback is done through child elements, *like <object> in HTML 4 and
the proposal to use @src everywhere in XHTML2* Hmm, @longdesc isn't

I deduce that @longdesc isn't there yet because (yes I know, we
haven't researched it fully) people aren't convinced it effectively
solves the problem. I deduce that video and audio do not use @alt and
@longdesc because people are convinced the <object> fallback mechanism
is a better solution to the problem. I deduce that video and audio DO
have a defined fallback mechanism, in contrast to @longdesc on img,
because people DO believe it adequately solves the problem.

Now, does anyone else think fallback mechanism for all embedded
content is the same problem, regardless of media type or tag name?

I don't understand why img and embed do not have comparable fallback
mechanisms defined. If the <object> fallback model is best, shouldn't
we adopt it for all embedded content? If @alt is better, shouldn't it
be used on all embedded content? If @longdesc is best, shouldn't we
use that? (And it need not be either, all three - and more - could be
used, if there was a good case for doing so).

I apologise for not "making a use case" at this point. I look forward
to producing some soon. For now I want to let you ponder why we
propose different fallback mechanisms...
- nothing for embed
- text only (@alt) for img
- HTML for video, audio, object

To summarise my view: the problem appears to be solved, but hasn't
been applied retrospectively to img and embed elements.


On 6/30/07, Robert Burns <> wrote:
> On Jun 30, 2007, at 7:57 AM, Anne van Kesteren wrote:
> >
> > On Sat, 30 Jun 2007 14:40:27 +0200, Robert Burns <>
> > wrote:
> >> I've seen a several dismissive remarks on adding a <picture>
> >> element in the HTML5 discussions. However, the need for a new
> >> embedded element with fallback content for still images is far
> >> more important than adding <video> and <audio>. I'm not saying I'm
> >> against those new elements, but the need for them is far less than
> >> for a new embedded content element with fallback for still images.
> >
> > What are you basing this statement on, exactly?
> I'm not sure which statement you mean. That author's and users have a
> need for <picture> more than <video> and <audio>? Because authors are
> already using <object> to embed video and audio without much
> complaint. By using <object> for video and audio, these non-text
> media have a mechanism for decent fallback content. However, using
> <img> does not provide such a fallback content so there is a stronger
> need to introduce a new element for that than for the others.
> > Also, introducing a new container for images has been tried before
> > and it didn't really work out so well although support for <object>
> > is improving.
> Well, there were many complicating issues that made it difficult for
> authors to switch <img> over to <object>. First <object> doesn't
> really stick in an author's mind for still images the way <img> does
> (or the way something like <picture> would). Also, IE added
> complications that made it more difficult to embed still pictures
> with <object> (needing to add <param> or javascripting) than simply
> using <img>. My contention is that if we deprecated (i.e., omitted or
> dropped) <img> (and with it @longdesc) from HTML5 and added something
> like <picture>fallback</picture>, it would have a much stronger
> chance of success (presuming it was implemented in the most popular
> UAs without added complications) than <object> did. In five or ten
> years from now we could end up seeing all content created using
> <picture> with proper fallback content. All of the complicating
> issues of @longdesc would be gone then.
> Take care,
> Rob

Received on Saturday, 30 June 2007 15:51:04 UTC