Re: handling fallback content for still images

Robert Burns writes:

> On the UA side, we can direct UAs how to handle this situation. For
> example, "UAs that recognize <img> as having content (as in an XML
> processing UA) must treat the contents of an <img> element as fallback
> in the same fashion as the <object> element." However, we guide
> authors conformance on this, I think that would be the prudent way to
> go for UA conformance. For forward compatibility, this UA conformance
> seems imperative.

Why?  Compatibility with what?  Compatibility with authors in the future
who put alternative content inside XHTML <img> tags?  Why do you think
that in the future there are bound to be such significant numbers of
authors doing that (even if HTML5 doesn't condone it) such that user-
agents will need to recognize it?

> It doesn't break backwards compatibility because we're only doing it
> on a shift in serialization.

True.  But there are two situations in which we'd want a browser to
support a particular construct:

* It's something which our spec permits authors to do.

* It isn't something authors are permitted to do, but its use is already
  widespread, so needs to be supported for backwards compatibility.

For alternative content inside <img> the second of those doesn't seem to
apply (nobody has yet provided evidence suggesting authors are doing
this).  And the first obviously only applies if it's valid for authors
to do it; I don't follow why, if we choose not to let authors do this,
it's imperative for browsers to support it anyway.

> > I'm sceptical that putting alternative content in <img> elements
> > would get sufficiently widespread use to bring significant benefit
> > to users, and which outweighs the backwards incompatibility
> > awkwardnesses.
> 
> I don't think there's any backwards compatibility issues.

There are, because existing browsers do not implement the required
behaviour.  So users of those browsers are in a worse position than if
the well-supported alt attribute had been used.

In a quick test I knocked up (see below) served as application/
xhtml+xml:

* Firefox (2.0) did not ever display the contents of <img>, even when
  the image wasn't displayed.

* Konqueror (3.5.6) _always_ displayed the contents of <img>,
  immediately after the image itself, as though the content followed the
  <img> element rather than contained in it.  Where the image was
  missing the content followed the 'missing image' icon (which also had
  the text of the alt attribute displayed across it where given).

* W3M (a text-only browser) uses colour to distinguish the content of an
  alt attribute (and therefore indicate that there is an image missing)
  from normal text.  The contents of <img> are displayed immediately
  after the alt attribute, but in 'ordinary text' colour.  Where an alt
  attribute is not provided the base name of the image filename in
  square brackets is used instead, and again followed by the <img>
  content looking like ordinary text.

In all three cases the user experience is worse than if alternative
content was simply put in the alt attribute.  So it is definitely not
backwards compatible.

> > > ... my proposal is not that concerned with fallback for missing
> > > content.
> > 
> > But that's surely the point of alternative content, to be made
> > available to a user who isn't experiencing the 'main' content?
> 
> Yes and no. Yes, it would be ideal if UAs displayed the fallback
> content in the case of an author or network error (network in the
> broadest sense of the term, i.e.., whether its a down server or router
> or whatever).

I was also thinking of the situation where somebody is using a graphical
browser but has disabled images.  This is especially important for
authors trying to create suitable alternative content; as Sander
Tekelenburg recently said:

  As an author, you should look at the entire document, without the
  images being loaded, and for each image consider what text would make
  sense in its place; what text would make you not miss the image,
  because that text conveys the same as the image.

> However, no its not the point of alternative content,

I reckon that it is the point of alternative content to be an
alternative when the main content is not displayed.  Why should it only
be there for some circumstances?

Moreover, why should we introduce a mechanism that only works in some
circumstances when we already have one which works in all?

Smylers

Received on Sunday, 15 July 2007 21:10:23 UTC