- From: Robert Burns <rob@robburns.com>
- Date: Mon, 2 Jul 2007 16:14:18 -0500
- To: Anne van Kesteren <annevk@opera.com>
- Cc: "HTMLWG WG" <public-html@w3.org>
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