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

Re: handling fallback content for still images

From: Robert Burns <rob@robburns.com>
Date: Mon, 2 Jul 2007 16:14:18 -0500
Message-Id: <E7A1F92B-3541-48A7-9434-A30786486100@robburns.com>
Cc: "HTMLWG WG" <public-html@w3.org>
To: Anne van Kesteren <annevk@opera.com>

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

<audio> could just be

<object data='audio'>

<canvas> could just be

<object type='image/canvas'>

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  

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,
Received on Monday, 2 July 2007 21:14:28 UTC

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