W3C home > Mailing lists > Public > public-respimg@w3.org > September 2012

Re: Adaptive Image Element Proposal

From: Kornel Lesiński <kornel@geekhood.net>
Date: Tue, 04 Sep 2012 20:38:15 +0100
To: public-respimg@w3.org
Message-ID: <op.wj4l51h7te2ec8@aimac.local>
On Fri, 31 Aug 2012 02:31:45 +0100, Leif Halvard Silli  
<xn--mlform-iua@målform.no> wrote:

> By the way: How is fallback supposed to be working in the picture
> element?  The draft points to HTML5 with regard to a definition of
> fallback. [1] However, in HTML5, there are at least 3 fallback models:
> 	* img: the element retains its role when we see the fallback
>     * video/audio: we don't get fallback, even if the media format
>       is unsupported.
>     * object: if fallback steps in, then the object looses its default
>       "role", and focus is given to the fallback instead.
> One could say, that as long as picture element is not supported, then
> it is the object model that is operative. (And the duplicate alt model
> works OK - from users point of view - in that scenario.) But how should
> an without support for the mime type of the image react?

I think it should be modelled after <object>. If the image cannot be  
displayed for any reason (invalid mime, bad data, 404, user preference)  
then the fallback/alt content should be displayed instead.

BTW: it appears to me that there's a design pattern in HTML that <picture  
alt> doesn't fit into:

Void elements use alt:
<img alt="alt" /> <input type=image alt="alt" />

But non-void elements use content:
<object>alt</object> <iframe>alt</iframe> <canvas>alt</canvas>  

(while not all of them have fallback behaving the same way, the markup  
pattern is the same)

So a non-void <picture> element with an alt attribute for fallback would  
be an odd one. Since it's non-void, the right place for fallback/alt is  
inside the element.

regards, Kornel
Received on Tuesday, 4 September 2012 19:38:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 4 September 2012 19:38:43 GMT