Re: handling fallback content for still images

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. To the extent that one can separate ill-formed from  
invalid in text/html, this is about something that would be ill- 
formed in HTML, but not ill-formed in XHTML. It is invalid, however,  
with XML I think the trend (the paving of the cow-paths) has been to  
worry much less about invalid markup than ill-formed markup. So, the  
issue is how do we guide UAs and authors on this issue (e.g., must,  
should, may). This is definitely going to be a tempting move for any  
author deploying XHTML.

We could make it valid or invalid. Making it valid would be a syntax  
difference (a semantic difference even). However even it ifs invalid  
it can still be may not/ should not / must not.

>>>> [...]
>> 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?

>
>>> (Note this isn't an argument against your proposal being useful in
>>> terms of providing rich fallback content, merely pointing out that
>>> we can  have interop in other ways without your proposal.)
>>
>> And miss an opportunity.
>
> I'm not disagreeing with that; but the opportunity therefore has to be
> justified (with evidence along the lines of James's suggestion); its
> being interoperable is irrelevant to its justification, because pretty
> much any suggestion is going to be interoperable.
>
>>> But there is no evidence at all of any of them having any intention
>>> of treating this content as  'alternative' (rich or otherwise); none
>>> of them display it in circumstances where images have been disabled
>>> or are otherwise unavailable.
>>
>> But there are other UAs that aren't ignoring the content. How is that
>> interoperable?
>
> It isn't.  But it would be if they changed their behaviours to match
> your proposal (or indeed any proposal, including it being a parse  
> error
> and that such content should be ignored).
>
>>> You have, reasonably, pointed out that we can't expect browser to
>>> implement features that haven't yet been written.  So the fact that
>>> browsers currently don't do this again isn't an argument against the
>>> plan.
>>
>> 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?

> 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. Its a BUG that others have raised and keep raising.  
I merely said it was a minor bug or minor issue because its  
completely unrelated to what I'm trying to accomplish.

> It means that implementing your proposal would be a behaviour  
> change for
> those browsers (probably all browsers).

No, it doesn't. 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.

> Note this isn't a reason not to take your proposal.  It doesn't  
> mean I'm
> against it.  It merely means you can't claim 'browsers are already  
> doing
> this' as a point in favour of your proposal.

What I'm saying is that — since we've been asked to make sure our  
proposals work with existing implementations — this works in two of  
the three major visual (and XHTML capable) UAs. If the other could  
change their behavior as soon as possible to be interoperable with  
the other two, then we're in business for this meeting at least that  
very minor, but necessary HTML5 criterion. The other piece of the  
puzzle has not been explored: the aural and tactile UAs whether they  
work independently or in association with these major XHTML UAs.

>> I never said anything about buggy.. I said they aren't doing it
>> consistently
>
> Actually you did say::
>
>   It is a minor bug if Opera doesn't display the fallback content when
>   the image is not available.

As I already said, I was simply agreeing with others pointing out the  
bug and I was trying to minimize it by calling it minor because I  
don't really care about that behavior. Call it a feature. It has  
nothing to do with my proposal.

>> and that we should provide guidance in the spec so that the do behave
>> in an interoperable manner. I dumbfounded that this can even be
>> controversial.
>
> I don't think anybody finds the _general_ principle of the spec
> specifying what browers should do and what authors should write is
> controversial; what people are being skeptical about is the _specific_
> proposal of precisely _what_ that interoperable behaviour should be.

No! No one has suggested any alternate behavior: except in the "minor  
bug" case above. But again that "minor bug" is entirely perpendicular  
to my proposal, so its not really an alternative interoperabiliby  
behavior to what I propose. No one has suggested an alternative, but  
they have rather suggested they are skeptical of providing UA and  
author guidance on this. Or they flip-flop between wanting to forbid  
and then saying they didn't mean to say they want to forbid. Again, I  
view that as irrational.

The amazing thing is I began this thread in an attempt to rationalize  
to myself and then for others why the semantically rich fallback  
content provided by @longdesc would possibly be deprecated in HTML5  
and what must be considered best practice in its place. This has led  
me to suggest: 1) improving interoperability on the <object> element  
and simplifying its use for authors. 2) an alternative <picture>  
element to support rich fallback content and 3) showing how an xml  
serialization provides a new opportunity to provide guidance to  
authors and UAs on the <img> element for XML serialization. All of  
these proposals are meant to address the same pressing need: for  
semantically rich and media rich fallback content for still images.  
Frankly, I see no reason why we wouldn't do all of them.

Again, these proposals were simply developed as I tried to understand  
what happened to the @longdesc attribute.  This latest proposal (3),  
seems unavoidable, at least in the sense that we need to provide  
guidance whatever that guidance is (may not/ shall not/ must not).  
The first proposal, I'm not sure how that led to "skepticism", but it  
did. This type of skepticism is mostly just nay-saying. It reminds me  
of the Monty Python "Argument" sketch.

<dialog>
<dt>Rob</dt>:<dd> Look I came here to hear some skepticism</dd>
<dt>Smylers: </dt><dd>No you didn't</dd>
<dt>Rob</dt>:<dd> Yes I did</dd>
<dt>Smylers: </dt><dd>No, I don't think you did</dd>
</dialog>

Take care,
Rob

Received on Thursday, 5 July 2007 18:01:50 UTC