Re: handling fallback content for still images

On Jul 15, 2007, at 4:09 PM, Smylers wrote:

>
> 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?

I had already posted this. Our design principles also place an  
importance on forward compatibility. I think you could just think of  
it as plain compatibility if you prefer: <http://www.w3.org/TR/xhtml2/ 
mod-image.html#s_imagemodule>.. I think as interest grows in XML  
serializations of HTML, your going to see this happening. Authors are  
not going to be concerned about the outlying error condition of when  
their media files are somehow inaccessible. They will be concerned  
that visual UAs not display the contents of the <img> element (they  
don't for the most part) and they will be concerned that non-visual  
UAs do render the contents of the <img> element: increasingly they  
will (if they don't already).

>> 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 could (and it should IMO).

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

We also have a forward compatibility design principle. I think this  
will become increasingly used. (incidentally, I don't see this as a  
replacement to @alt. As I've said elsewhere, with the addition of  
@longdesc (and this mechanism fits here too), the semantics of @alt  
has diverged from simply a bad facility for equivalent fallback to a  
fallback shorthand. Something that can typically be rendered in the  
same space as the image it replaces (often unlike the equivalent  
fallback text).

> 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.

This evidence thing is a red herring. Its permitted by other W3C  
recommendations and draft recommendations. You can expect it from  
authors in the future. Its something we should address in our  
conformance criteria and I think it would be a big mistake (from a  
compatibility perspective) to tell UAs to throw out this content. If  
we really want to tell authors they "must not" do this then fine.  
However, it completely blows our compatibility principles away to say  
that UAs must ignore the contents of <img> in an XML serialization.

>>> 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.

I've addressed this over and over. It degrades gracefully. Only in  
the case of errors does the technique not accomplish what it should.  
This is something that UAs can correct from our recommendations. Its  
not a concern that should drive decisions over UA conformance on this.

> 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.

degrades gracefully.

> * 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).

That sounds like a test error to me (like it wasn't consumed as  
xml).  However, if that's a bug in Konqueror, I'm sure they'll fix it  
on our recommendations. This is the only UA I've heard of that  
doesn't degrade gracefully.

> * 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.

That sounds fully compatible to me. Again, I'm not proposing this as  
a substitute for @alt. @alt is required for author conformance, so it  
should be there too. This would more replace @longdesc, though that  
would be there too as an alternate mechanism for authors.

> 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.

No, it is compatible: forward and backwards. It also degrades  
gracefully in all of the media rich visual UAs (except perhaps  
Konqueror, though that surprises me because of its close relation to  
WebKit and I'd want to confirm that there weren't any test errors;  
its also a very small part of the UA market).

>>>> ... 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.

How does this get in the way of that?

>> 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?

Its for all circumstances. However you're advocating that we break  
compatibility with other HTML content even though this degrades  
gracefully or is even already supported in some browsers just be  
cause of this outlier situation (when there's a network of author  
error). That's absurd.

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

For compatibility. There may be other reasons too, but foremost we  
should be a good citizen in the XML community. That means that our  
XML handling should be XML like (the Konqueror example breaks that  
and we should make clear conformance criteria about that). Even if  
author's make mistakes, UAs should not be encouraged to throw out  
content like this when an error occurs with loading the replacement  
for the element.

For document/author conformance, we can do whatever you like. I don't  
have a strong opinion on that. However, it strikes me as absurd to  
not guide UAs (which are already degrading gracefully on this) to not  
continue to degrade gracefully and even add support for load errors  
or  turned off images (which seems to be a very big concern for you).

Take care,
Rob

Received on Sunday, 15 July 2007 21:52:33 UTC