Re: Adaptive Image Element Proposal

Hi Leif, Mat and all,

>> I put together a test of longdesc for responsive images with a
>> variation of Scott Jehl's Picture Fill:
>> http://www.d.umn.edu/~lcarlson/research/scottjehl-picturefill/index.html
>>
>> Test Results:
>> Reveals and works correctly at all sizes from small to extra large
>> (e.g., opens description page
>>
> http://www.d.umn.edu/~lcarlson/research/scottjehl-picturefill/external/carvingdesc.html
>> when activated) in:
>
> Why is it relevant to test how Scott Jehl's Picture Fill technique
> works?

It is relevant to test required discoverabilty mechanisms.

> My question is: Can we expect the same to happen for <picture>, when
> *implemented*?

That would be the goal and expectation.

> We don't know how <picture> will end up functioning, but we should
> assume that its (rendered) graphic resource will overlay the image of
> the child <img> element. If we should expect something else, then
> please - Mat or whoever - gives us reason to believe so. Until then:
> Provide @longdesc and @alt really are crucial, the I come back to the
> conclusion that it is better to drop <picture> and instead go for
> extending <img> with @srcset etc. Because, in that case, there would be
> no doubt thagt the <img> element lands on top.

Mat, is there a way to make sure <img> element lands on top?

> In the debates about <picture> on WHATWG, it seems like Mat's reason
> for going for <picture> rather than for @srcset on <img>, has to do
> with authoring convenience. Then remember that, provided @longdesc and
> @alt is a must, the much debated HTML5 design principles put users
> needs above author needs.

True.

I hope this can all  be worked out with <picture>

Thanks.

Best Regards,
Laura

-- 
Laura L. Carlson

Received on Wednesday, 12 September 2012 12:16:32 UTC