W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: handling fallback content for still images

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 2 Jul 2007 22:47:41 -0700
Message-Id: <F282C84C-BB40-4C34-8487-D5F60302BA40@apple.com>
Cc: Sander Tekelenburg <st@isoc.nl>, public-html@w3.org
To: Robert Burns <rob@robburns.com>

On Jul 2, 2007, at 10:17 PM, Robert Burns wrote:

> Does this mean we'll move towards having a different element for  
> every MIME Type (or at least the first level types)? Won't we still  
> require conforming implementations to work with <object> for  
> diverse types?

I don't think a blanket statement can be made - it depends on whether  
the content type is common and what kind of requirements it has for  
integration with web applications and documents.

> Again, don't these same arguments apply to <picture>? Yet again and  
> again we're told "well why don't you just use <object> if you want  
> a single unified approach to still images that allows optional  
> fallback". I'm not trying to be argumentative here. I'm really  
> trying to understand the principles that are being applied so that  
> we can start to build a consensus around these issues.

I haven't really made an argument for or against <picture> myself.  
However, to make the case for it, you'd need to show how to achieve  
the following with a single markup fragment -- how <picture> would be  
defined and what markup you would use to get these effects:

1) Would show the image and not the fallback in visual, graphical  
browsers supporting the new tag.
2) Would present the non-image fallback content in visual text-only  
browsers supporting the new tag.
3) Would present the non-image fallback content in screen reader/ 
browser combos supporting the new tag.
4) Would show the image in currently existing graphical browsers that  
don't recognize the new tag (presumably by falling back to an <img>  
or <object>).
5) Would present the non-image fallback content in existing visual  
text-only browsers (such as Lynx) that do not support the new tag.
6) Would present the non-image fallback content in existing screen  
reader/browser combos that do not support the new tag.

The solution should not rely on a script that changes the content  
depending on what type of UA is displaying it (since that could  
already be done by swapping in images for other content).

Personally, I am not sure how to achieve this. But if someone can  
figure out a design that meets these requirements, then it would make  
sense to discuss whether the incremental benefit to accessibility and  
media-independence is worth it.

>> Consider also developers using the DOM API. It makes sense that a  
>> single class doesn't wildly change what methods and properties it  
>> exposes, based on runtime conditions. And with <object>, changing  
>> the type attribute on the fly could, if <object> was overloaded,  
>> result in a total change of API on the very same object.
>> So in this case, I think the goals of being implementation- 
>> friendly and author-friendly are aligned.
> I understand what you're saying. However, I'm thinking more of the  
> novice authors. Authors using the DOM already have a level of  
> sophistication that allows them to understand these things. I'm  
> trying to make easy things really easy and difficult things possible.
>>> Again, I think its entirely the wrong approach to take complexity  
>>> in API implementation and deal with that by making HTML  
>>> needlessly more complex. The algorithms should simply branch on  
>>> the different media types. If there are other arguments for  
>>> semantically distinguishing between the various embedded content  
>>> objects,, that's fine, but not simply to off-load (minor)  
>>> difficulties from the processing algorithms.
>> Exposing completely different APIs on the same element depending  
>> on what type of content it is currently displaying is more than a  
>> minor difficulty.
> I guess I'll take another look at the <audio>, <video> and <canvas>  
> APIs, but I don't recall the differences being that major.

It's the differences among all three and the differences relative to  
a regular <object> element that are significant.

> It would require DOM code to use introspection on <object> elements  
> (how about doing canvas drawing right on the top of a video?)  
> before assuming it will respond to video calls for instance. How is  
> that any different from checking whether a <div> has a particular  
> value for @class before performing some method on it?

You don't have to check a <div>'s class to decide what API the  
implementation needs to expose.

>>> I feel some relief that so many think we can deal with these  
>>> <object> interoperability/implementation problems.
>> I think IE is the main problem area so I'd like to hear from  
>> Microsoft on this.
> Me too. Though I'd also be interested in testing (or if someone  
> else has done this already) what the various UAs do, when  
> confronted with those simplified <object> cases (i.e., no <param>  
> and not necessarily any declared type) for video, audio, image, and  
> flash (probably no one supports type='image/canvas' since I made it  
> up).

Since you're interested in this topic, maybe you could start the  
testing. If you fill in a wiki page with most of the results and  
links to test cases, you could probably get others to fill in any  
browsers you don't have access to.

Received on Tuesday, 3 July 2007 05:47:51 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:23 UTC