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

Re: Adaptive Image Element Proposal

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Mon, 3 Sep 2012 00:59:02 +0200
To: Peter Winnberg <peter.winnberg@gmail.com>
Cc: Steve Faulkner <faulkner.steve@gmail.com>, Mathew Marquis <mat@matmarquis.com>, HTML WG <public-html@w3.org>, "public-respimg@w3.org" <public-respimg@w3.org>
Message-ID: <20120903005902095239.69fe9ac2@xn--mlform-iua.no>
Peter Winnberg, Sun, 2 Sep 2012 23:50:16 +0200:
> 2012/9/2 Leif Halvard Silli:
>> It is even *more* true if the UA *supports* the picture element.
>> Quoting what Steve said:
>> 
>> ]] i.e. the sub dom content is only visibly displayed in browsers
>>    that do not support canvas, [[
      [...]
> Oh good point. If the script that is responsible for rendering the
> content on a canvas element fails to load (e.g., syntax error or
> unable to download the script) it actually doesn't display the
> fallback content. I guess there could be technical reasons why this is
> difficult to detect, the code spread over several files of which some
> are loaded successfully and there is no reason why the script would
> have to draw anything on the canvas element initially. At least in
> Firefox the fallback for the canvas element is only displayed is
> Javascript is completely disabled.

Sounds like a story about how difficult it is to disable image display 
in Firefox … No, of course you are right that, for single images that 
don't load, then Firefox do load the fallback without you having to 
fiddle with the settings. But still ...

Perhaps the correct way to insert canvas elements would be to be via 
JavaScript, rather than directly in the markup? Thus: augmentative 
authoring.

> But this also seems very inconsistent with how alt text is handled on
> the img element, if the image fails to load the alt text will be
> displayed instead. I guess I should search for previously reported
> bugs that is similar to this and/or report a new bug.

Again: this is not particular to canvas. Same behavior can be seen for 
<audio> and <video>: A bad video URL is wrong does not give you the 
fallback. But I don't know if a canvas-like <picture> would *have* to 
work *exactly* that way, ieth.

>> One conforming way to solve that problem, would to have a no-empty alt
>> attribute. Just fill it with white space or similar. Or even a short
>> text, like "Photo".
> 
> Everything short of the full alt text in the alt attribute on the img
> will still be a sub-optimal solution for legacy user agents. But yes,
> this would at least make sure that it isn’t marked as presentational.

I don't think so. Images are either presentational or 
"un-presentational". So if you want to describe the image for everyone 
without making the image disappear from AT users because of an empty 
@alt, then you must do something - like adding a short dummy text so 
that the image becomes 'un-presentational' and can be identified as the 
object that is being described. I thus do in principle not no see any 
diff between doing that and doing this:

<picture srcset=foo src=bar><img alt=Photo src=img>Text.</picture>
-- 
leif halvard silli
Received on Sunday, 2 September 2012 22:59:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 2 September 2012 22:59:37 GMT