Re: handling fallback content for still images

Robert Burns writes:

> On Jul 5, 2007, at 9:27 AM, James Graham wrote:
> 
> > It is clear that there is a certian amount of scepticism about the
> > need or viability of what you are proposing. The correct response
> > ... is to provide evidence for your position.
> 
> No, it is not clear that these is skepticism about what I am
> proposing. There is quite a bit of support for what I am proposing
> (providing parallel rich fallback content for still images).

That there is also support says nothing at all about the existence of
the skepticism; they can easily co-exist.

> There is also a few who are responding with quite a bit of irrational
> resistance to what I am proposing:

Why do you presume that those who disagree are being irrational?  Surely
James, in asking for evidence in order to be persuaded, is being very
rational, and indeed skeptical.  Clearly there are differences of
opinion here; labelling the 'other' viewpoint as irrational does not
make progress.

While indeed only a few people have been responding questioning your
proposals, it does not follow that only a few are skeptical of them.
For example, I have not until now contributed to this thread for the
quite simple reason that every point I wished to make was already being
made eloquently by somebody else.

> where I'm not actually proposing we change anything fundamental,

You're suggesting that we change the syntax of the <img> element, which
has been part of HTML since before HTML had version numbers.

> but instead provide interoperability ...

You're right, the spec should tell user-agents what to do if they
encounter content in an element which is supposed to be empty (if it
doesn't already do this; I haven't checked).  That is sufficient to
provide interop; we do not need to assign meaningful semantics to any
such content found.

(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 author guidance

Again we can have author guidance by telling them that <img> is empty,
in the same way that the spec has rules for all sorts of things that
authors should do.

> for something that is already happening (non-inter-operably) in UAs.

It's been shown that it isn't already happening!  There are user-agents
which completely ignore any unexpected content inside an <img> element,
under all circumstances.  That's quite a reasonable thing for them to do
with unexpected content.  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.

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.

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.  A proposal is either codifying existing _de facto_
behaviour, or it is proposing a change; if browsers don't already do it
then it's a change, no matter how much we think that browsers _should_
already be doing it.

I could claim that in the case of a missing image browsers are currently
displaying the winning numbers for next week's lottery, but they suffer
from a bug in which the numbers are displayed invisibly!  But that
doesn't make much sense.  (It's even, dare I say it, a little irrational
...)

Smylers

Received on Thursday, 5 July 2007 15:55:49 UTC