Re: handling fallback content for still images

On Jul 13, 2007, at 2:18 PM, Smylers wrote:

>
> Robert Burns writes:
>
>> On Jul 5, 2007, at 12:14 PM, Smylers wrote:
>>
>>> I thought your proposal being discussed in this thread was to put
>>> alternative content in an <img> element, as in:
>>>
>>>  <img src="carrot.png">Alternative content goes here</img>
>>>
>>> If that is not your proposal, then yes, I have misunderstood it; my
>>> apologies.
>>>
>>> If it is your proposal then clearly it involves changing the syntax
>>> of the <img> element, because the syntax afterwards would be
>>> different.
>>
>> My proposal is much more about what to do about content in an image
>> element in XML. ... the issue is how do we guide UAs and authors on
>> this issue (e.g., must, should, may).
>>
>> We could make it valid or invalid. Making it valid would be a syntax
>> difference
>
> I agree.  But when I (incorrectly) claimed "You're suggesting that we
> change the syntax of the <img> element" you corrected me with "No, now
> you've simply exhibited yourself as another on the list of those who
> don't understand my proposal", so I conclude that you are not  
> proposing
> this, merely mentioning it?
>
>> However even it ifs invalid it can still be may not/ should not /  
>> must
>> not.
>
> Oh, I had't thought of that, sorry.  What things are we classifying as
> invalid yet still only telling authors that they "may not" or "should
> not", rather than "must not"?  What do those states represent?

I'm suggesting its not as simple as saying something is valid or  
invalid. We have a much bigger toolbox than that and we should make  
use of it. Let's not always use the hammer. In other words, we do not  
have to insist that conformance checkers flag <img>fallback</img> in  
an xml serialized document as invalid. We can ask the question, how  
should the conformance checker respond to  that word "fallback" in  
this example? It can tell the author there is an error (i.e., "must  
not" have contents). The conformance checker could issue a warning  
(i.e., should not). Or there could be some sort of comment ("may")  
regarding the contents to let the author know that this can only work  
for XML serialization and delivery.

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[1]. It doesn't break backwards  
compatibility because we're only doing it on a shift in serialization.

And it would be easy to express a conversion algorithm (for  
serialization converting UAs) between the two serializations where  
the contents of an <img> element is moved to a @longdesc targeted  
document fragment and vice versa.

For author conformance, we might not say a word. Or we could provide  
guidance to authors that parallels the conformance criteria for  
conformance checkers. In other words:

•  "authors must not include contents within an <img> element for  
fallback"
• "authors should not include contents within an <img> element for  
fallback , even for xml serialize documents"
• "authors may include contents within an <img> element for  
fallback , only for xml serialize documents but should be aware ... "

>>>> However, an aural UA could easily make use of that
>>>
>>> Indeed it could.  And I'm not _against_ doing that, as I said:
>>
>> Well what ARE you skeptical of then?
>
> I'm skeptical 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 is a  
serialization conversion issue (one among many serialization  
conversion issues). There is also a forward compatibility issue[1]  
that we should not ignore: especially with respect to our UA  
conformance criteria.

>>>> I didn't claim buggily.
>>>
>>> Fortunately, my words above don't claim that you claimed buggily!
>>
>> "But it does strike me as bizarre to simultaneously claim both  
>> that the
>> proposal is something that browsers are already doing, and that  
>> they are
>> doing it ____buggily_____."
>>
>> Am I misreading this?
>
> You're right.  I owe you an apology: sorry.

I accept your apology. The buggily part relates to the next part of  
the discussion that follows here:

>>> But you did acknowledge that your claim that browsers support this
>>> was only that they didn't display the contents of <img> when
>>> displaying an image, not that they also _did_ display its contents
>>> when not displaying it.
>>>
>>> That means that browsers _aren't_ currently bahving in a way
>>> consistent with your proposal.
>>
>> No, because 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 t he  
broadest sense of the  term, i.e.., whether its a down server or  
router or whatever). However, no its not the point of alternative  
content, in the sense that this outlying case of author or network  
error should not in the slightest deter us from adding a feature  
needed by those who need this fallback content when their are no  
errors (to adhere to accessibility principles). So ideally <img  
src='mypicture'>fallback</img> should display the word "fallback"  
when 'mypicture' is supposed to read 'myimage' or when 'myimage' is  
on a different inaccessible server. However, its so much more  
important to properly handle the non-error situation. For users who  
are consuming content when no errors exist, but they simply have a UA  
incapable of displaying the image or they themselves are unable to  
see the image.

>> Again, I'm not interested in the fallback working for missing  
>> content:
>> at least that's not my primary concern. It may be a concern to others
>> and I'd support them in their attempts to improve UAs,, but its
>> completely unrelated to my proposal.
>
> It is related, because as a consequence of implementing it we'd end up
> with one of these situations:
>
> * The spec saying that alternative content in the alt attribute is an
>   alternative in all circumstances, but alternative content in the  
> <img>
>   element is an alternative in only some circumstances -- which is  
> very
>   confusing for authors to know what to do.

Our conformance criteria wouldn't say that. Our author conformance  
criteria might make no mention of <img>fallback</img> at all. It just  
that the current situation degrades gracefully. The missing contents  
of an <img> element for non-conforming UAs might not even be that big  
of a deal, since they would also have @alt available. After all,  
there are many semantics in HTML that UAs simply do not make  
available to users (<link> for example in many UAs). This would just  
be another: one that only happened in a particularly unusual situation.

> * All ways of specifying alternative content are theoretically  
> equal --
>   with new browsers changing their behaviour regarding <img>, and  
> legacy
>   browsers failing to show the content of <img> even when the image
>   isn't being displayed.

Again, its only visual UAs that have the problem. And they already  
have problems with fallback even for <object>.

All of these concerns seem very minor when compared with our need to  
maintain forward compatibility and adhere to our accessibility  
principles.

Its a lot to keep track of all of the options for conformance  
criteria (must not, should not, may not, may, should, must) and the  
different conformance audiences such as authors, and all sorts of  
UAs, general UAs, authoring UAs,  conformance checking UAs,  
conversion UAs, visual, aural, tactile, etc.  However, these options  
also  provide us  with a lot of fine-grained control over our  
recommendations. We should make use of that power.

[1]: Or just plain compatibility if you prefer: <http://www.w3.org/TR/ 
xhtml2/mod-image.html#s_imagemodule>

Take care,
Rob

Received on Saturday, 14 July 2007 20:38:20 UTC