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

Re: handling fallback content for still images

From: Sander Tekelenburg <st@isoc.nl>
Date: Tue, 3 Jul 2007 04:15:05 +0200
Message-Id: <p062406d5c2af60a8a2bf@[192.168.0.102]>
To: <public-html@w3.org>

At 01:04 +0000 UTC, on 2007-07-03, Ian Hickson wrote:

> On Mon, 2 Jul 2007, Robert Burns wrote:

[...]

>> <canvas> could just be
>>
>> <object type='image/canvas'>
>> fallback
>> </object
>
> Actually, no -- the <video>, <audio>, and <canvas> elements all expose
> elaborate APIs that are specific to the kind of media to which they
> relate. When those elements were introduced, it was thought unwise to
> overload <object> with all these APIs as well as APIs for frames, plugins,
> images, and the like. (Part of the reason <object> is so poorly
> implemented is that it is so overloaded with different behaviours, a
> lesson that I've tried to apply to all the new features in HTML5.)

So that would seem to be an argument for introducing <picture> then. I mean,
earlier I agreed with Anne that it would seem better if <object> would become
interoperable. But if its non-interoperability is an argument to introduce
<video>, <audio> and <canvas>, then it's also an argument for <picture>. (I'm
not denying there are some cons, just that this is a pro for <picture>.)


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>
Received on Tuesday, 3 July 2007 02:20:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:46 UTC