Re: Adaptive Image Element Proposal

2012/9/2 Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>:
> 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, [[
>
> There was an idea floated in the CSS working group a while back, about
> a CSS selector that could select img elements where the image failed to
> load. Could be relevant in the picture context, no? So I agree: Steve
> should note this as an issue with the canvas-picture model that needs
> attention.

Such a CSS selector might be useful in some cases, but will not help
with the legacy user agent examples I talked about because they will
not support it unfortunately.

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.

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.

> 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.

Received on Sunday, 2 September 2012 21:50:43 UTC