Re: handling fallback content for still images

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?

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

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

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

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

Neither of those sound good to me.

Regards.

Smylers

Received on Saturday, 14 July 2007 15:32:36 UTC