Re: handling fallback content for still images

Robert Burns writes:

> On Jul 15, 2007, at 4:09 PM, Smylers wrote:
> 
> > Robert Burns writes:
> > 
> > > 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. ...
> > > 
> > > It doesn't break backwards compatibility because we're only doing
> > > it on a shift in serialization.
> > 
> > True.  But there are two situations in which we'd want a browser to
> > support a particular construct:
> > 
> > * It's something which our spec permits authors to do.
> 
> It could (and it should IMO).

Yes.  But you also asserted that even if we don't permit authors to do
that -- if my first bullet point doesn't apply -- then it's still
imperative that we force browsers to implement this.

> > * It isn't something authors are permitted to do, but its use is
> >   already widespread, so needs to be supported for backwards
> >   compatibility.
> 
> We also have a forward compatibility design principle.

OK.  I'll add a third bullet point of things we should force browsers to
implement:

* It isn't something that we permit authors to do, nor is it currently
  widely used, but it's permitted by a separate standard that we are
  trying to be compatible with.

If we are trying to be compatible with XHTML2's syntax then that
obviously would be an excellent reason to implement this behaviour.

Doing so isn't how I read the design principles, but I've already
questioned that in a separate thread (one without a subject relating to
alternative content for images).

> > > > I'm sceptical 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 are, because existing browsers do not implement the required
> > behaviour.  So users of those browsers are in a worse position than
> > if the well-supported alt attribute had been used.
> 
> I've addressed this over and over. It degrades gracefully.

I'm not sure what you mean by "degrades gracefully", but I showed
situations in which it the user experience is worse using the proposed
mechanism than with existing mechanisms.

> Only in the case of errors does the technique not accomplish what it
> should.

Not only:  It's also in the case of a user of a graphical browser with
images disabled.  Or who has images disabled but poor eyesight and who
views the 'Properties' of an unclear image in an attempt to discover the
alternative content.

And has anybody tested any screen readers and the like on this?  Does a
screen reader manage to read from Internet Explorer or Firefox content
that is in the HTML source but which they are not displaying (even if
they have images disabled and are displaying other alternative content)?

> This is something that UAs can correct from our recommendations.

Of course browsers can change their behaviour to meet our spec.  But
note that exactly one of the following can be true:

* We are recommending something that all mainstream browsers already
  implement, so it is backwards compatible with them.

* We are recommending that browsers change their behaviour to implement
  something new that wasn't in HTML4 and which browsers don't currently
  do.

We can't claim both at the same time!  We can't both be claiming that
this is backwards compatible _and_ that browsers have to change their
behaviours.

> Its not a concern that should drive decisions over UA conformance on
> this.

Why not, given that we already happen to have something that does that
_and_ meets these criteria?


> > In a quick test I knocked up (see below) served as application/
> > xhtml+xml:
> > 
> > * Firefox (2.0) did not ever display the contents of <img> , even
> >   when the image wasn't displayed.
> 
> degrades gracefully.

Fails to provide the fallback content ever; worse than alternative
mechanisms.

> > * Konqueror (3.5.6) _always_ displayed the contents of <img>,
> >  immediately after the image itself, as though the content  followed
> >  the <img> element rather than contained in it.  Where the image was
> >  missing the content followed the 'missing image' icon (which also
> >  had the text of the alt attribute displayed across it where given).
> 
> That sounds like a test error to me (like it wasn't consumed as  
> xml).

Possibly.  In a later message I remembered to include the document I
used, so others can try that out and check I didn't get something wrong
there.

> However, if that's a bug in Konqueror,

That's begging the question.  It can hardly be a bug that they don't
implement a feature that wasn't in HTML at the time they released!

> > * W3M (a text-only browser) uses colour to distinguish the content  
> >   of an alt attribute (and therefore indicate that there is an image
> >   missing) from normal text.  The contents of <img> are displayed
> >   immediately after the alt attribute, but in 'ordinary text'
> >   colour.  Where an alt attribute is not provided the base name of
> >   the image filename in square brackets is used instead, and again
> >   followed by the <img> content looking like ordinary text.
> 
> That sounds fully compatible to me.

OK.  I was imagining that users would want this alternative content
displayed in they way they are used to seeing other alternative content.

> > In all three cases the user experience is worse than if alternative
> > content was simply put in the alt attribute.  So it is definitely
> > not backwards compatible.
> 
> No, it is compatible: forward and backwards.

I'm stopping this now, cos otherwise I'd be repeating myself.

> It also degrades gracefully in all of the media rich visual UAs
> (except perhaps  Konqueror, though that surprises me because of its
> close relation to  WebKit and I'd want to confirm that there weren't
> any test errors;

Please do.

> > I was also thinking of the situation where somebody is using a
> > graphical browser but has disabled images.  This is especially
> > important for authors trying to create suitable alternative content;
> > as Sander Tekelenburg recently said:
> > 
> >  As an author, you should look at the entire document, without the
> >  images being loaded, and for each image consider what text would
> >  make sense in its place; what text would make you not miss the
> >  image, because that text conveys the same as the image.
> 
> How does this get in the way of that?

I can't simply disable images in my graphical browser to preview what
users without images will see if my browser hides the alternative
content that they get.

> > > However, no its not the point of alternative content,
> > 
> > I reckon that it is the point of alternative content to be an
> > alternative when the main content is not displayed.  Why should it
> > only be there for some circumstances?
> 
> Its for all circumstances. However you're advocating that we break  
> compatibility with other HTML content

No, I'm advocating that retaining compatibility with existing browsers
is more important than changing behavour to match some other standard
that isn't widely implemented.

> > ... why should we introduce a mechanism that only works in some
> > circumstances when we already have one which works in all?
> 
> For compatibility. There may be other reasons too, but foremost we  
> should be a good citizen in the XML community.

Why?  That isn't in our design principles, let alone the "foremost"
principle which should override others; compatibility with existing
browsers is in there.

Though if that is our foremost aim, we should probably also change this
in the spec:

  Generally speaking, authors are discouraged from trying to use XML on
  the Web

Smylers

Received on Sunday, 15 July 2007 22:59:20 UTC