Re: handling fallback content for still images

On Jul 2, 2007, at 2:27 AM, Anne van Kesteren wrote:

>
> On Sun, 01 Jul 2007 23:55:55 +0200, Robert Burns <rob@robburns.com>  
> wrote:
>> <object
>>
>> 	type="image/png"
>> 	data="picture.png"
>> 	width="100%"
>> 	height="500"
>>  >
>> 	<param
>> 		name="src"
>> 		value="picture.png" /
>> 	>
>> Fallback content
>> </object>
>
> Without browser hacks this becomes:
>
>   <object data=picture>
>     Fallback.
>   </object>

Without implementation problems

<video> could just be

<object data='video'>
fallback
</object

<audio> could just be

<object data='audio'>
fallback
</object

<canvas> could just be

<object type='image/canvas'>
fallback
</object

However, the <picture> element solves a use-case problem. I'm not  
sure what the problem/use-case these other elements solve that  
justifies adding an element. An Object combined with a mime-type  
provides all the semantic differentiation an author could need.

As for just using object instead of picture, I think that would be  
ideal. However, I think authors may be intimidated by the very term  
"object" and therefore there's a cultural resistance to moving to the  
<object> element. <picture> is un-intimidating.  However, if the  
implementation issues could be addressed (and here we're talking a  
big one), than I probably would not care as much about the cultural  
resistance.

However, why would we feel the need to add another <canvas> element  
just for cultural reasons and not also do so for <picture> to fix the  
accessibility problems with <img>. Again, we need to think about our  
priorities and our constituencies.

Take care,
Rob

Received on Monday, 2 July 2007 21:14:28 UTC