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: Sun, 2 Sep 2012 06:51:30 +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: <20120902065130314037.314dfd21@xn--mlform-iua.no>
Peter Winnberg, Sat, 1 Sep 2012 19:47:40 +0200:
> 2012/8/31 Steve Faulkner:
>> When and if <picture> becomes implemented in browsers then the text
>> alternative can be provided as text in the sub dom:
>> <picture>
>> This is the text alternative
>> <img alt="">
>> </picture>
>> as I have previously mentioned I don't see what the problem is with doing
>> the above now and visibly hiding the text using CSS.

> But here are some problems that I see with the example that Steve sent
> about how to provide the text as part of the sub dom and hiding it
> using CSS.
> A user agent that supports HTML 2.0, but not CSS or ARIA would ignore
> any CSS to hide the text alternative and will present the text
> alternative even if it can load the image.

HTML 2.0 browsers were not always able to show embedded images. So I 
would not say we are going backwards just because a HTML 2.0 browser 
would have displayed both the alternative text and the image, 

> A user agent that supports CSS but not the picture element would
> always hide the text alternative (well depending on which media that
> the CSS was specified for) even if the image cannot be loaded.

This is true. (Though with CSS plus JavaScript, I managed to make 
fallback display when the image fails to load quite simply.)

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 

> Also
> because the image has an empty alt attribute it would be marked as
> presentational. Let’s say that ARIA isn’t supported, then you cannot
> define the relationship between the text alternative and the image
> (and if you could, this could lead us into the reference hidden
> content issue again).

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

But else: If <picture> were to follow the <canvas> model, then there 
did not need to be any <img> in the fallback. Thus, I am not certain 
that it is Steve's intention that the AT user knows that he/she "looks" 
(sic) at a picture ... Clarification and thought is needed.

> But on the other hand, if the alt attribute on the img element is used
> for the text alternative it would work in both of these cases. Even in
> a user agent that only supports HTML 2.0. But then you lose the
> ability to add structure to the text alternative.

Nice summary. But I think the role of the img element in in a canvas 
inspired <picture> element needs clarification. Is it there in order to 
inform that, hey, this is an image? Or would the <picture> element take 
upon itself the role of announcing that it is an image/picture, on its 
own feet? Or isn't it very important - given how <canvas> works - that 
the user knows that is being presented a "picture"?
leif halvard silli
Received on Sunday, 2 September 2012 04:52:03 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:26 UTC