Re: handling fallback content for still images

Robert Burns writes:

> On Jul 5, 2007, at 10:55 AM, Smylers wrote:
> 
> > 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.
> 
> Certainly they could co-exist, but they're not co-existing in this  
> case.

People are being skeptical, that is they are not yet persuaded of your
proposal.

> You must surely admit that support exist along-side  irrationality.
> Why do you believe that can't happen?

It could happen.  We can have all 3.

> > Surely James, in asking for evidence in order to be persuaded, is
> > being very rational
> 
> Well I'v been struggling to find what does make progress around here.

I'd suggest doing what James suggested.  Note that being skeptical of
your plan is not the same thing as being _against_ it.  I'm currently
unpersuaded, but evidence of the sort James asked for could persuade me.

> > You're suggesting that we change the syntax of the <img> element,
> > which has been part of HTML since before HTML had version numbers.
> 
> No, now you've simply exhibited yourself as another on the list of
> those who don't understand my proposal.

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.

> > > 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.
> 
> However, an aural UA could easily make use of that

Indeed it could.  And I'm not _against_ doing that, as I said:

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

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

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.

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

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

Smylers

Received on Thursday, 5 July 2007 17:14:39 UTC