Re: handling fallback content for still images

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.

Regards,
Maciej

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