- From: Kornel Lesiński <kornel@geekhood.net>
- Date: Tue, 04 Sep 2012 20:38:15 +0100
- To: public-respimg@w3.org
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> <video>alt</video> (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 UTC