W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2012

Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)

From: Adam Barth <w3c@adambarth.com>
Date: Sat, 12 May 2012 12:35:43 -0700
Message-ID: <CAJE5ia9uZdsOPjZmqdF5d=0SRWOE7N0YQ0+GndpoE-tnP0sp7w@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Mathew Marquis <mat@matmarquis.com>, whatwg@whatwg.org
On Sat, May 12, 2012 at 11:17 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On May 12, 2012, at 6:28 AM, Mathew Marquis <mat@matmarquis.com> wrote:
>
>> While that information may be available at the time the img tag is parsed, I don’t believe it will be available at the time of prefetching — I’m happy to research this further and report back with citations. I’m sure I don’t have to tell you that “disable prefetching on img tags just in case there are matching sources” is going to be a hard sell to vendors that do prefetch. If we’re left with a solution that fetches the original src before applying any custom source logic, well, we’re no better off than we would be with one of the scores of script-based solutions that have come about in the past year.
>>
>> To your original point, though: as much as you can absolutely make a case that a simpler implementation will benefit developers if inherently more stable, you can’t convince me that `img set` suits the needs of developers as well as `picture`. In fact, even if you were to convince me, it wouldn’t matter. Picture is, for better or worse, what developers want and expect in a “responsive images” element. There’s certainly no shortage of proof of that, on this page alone: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/ At the moment, the Community Group server seems to be down due to excessive traffic.
>
> The key to making the case for the <picture> element or something like it is to cite use cases. Most of the comments on that blog post just give opinions, without use cases backing them up. A lot more weight will be placed on explanations of *why* developers love something (e.g. it lets them do X where they otherwise couldn't, it lets them do Y more easily, etc) than just testimonials that they love it.
>
> Regards,
> Maciej
>
>
> P.S. Your examples in that blog post are not equivalent. Here are two examples  that I believe would be equivalent for resolution adaptation only, presuming a 600x200 image and a 1200x400 scaled version:
>
> <img src="catface.jpg" alt="A cat's face" srcset="catface@2x.jpg 2x">
>
> <picture style="width: 600px; width: 200px" id="catface_picture" alt="A cat's face">
> <source src="catface.jpg">
> <source src="catface@2x.jpg" media="min-device-pixel-ratio: 2">
> <img src="catface.jpg" alt="A cat's face">
> </picture>
>
> Other than more general verbosity, there are a few other other differences that show up:
>
> 1) The <picture> version has to repeat the alt text.
> 2) The <picture> version has to repeat the URL to the 1x asset.
> 3) The <picture> version has to explicitly set a width and height, because it does not have the built-in scaling semantics of srcset and so cannot rely on intrinsic size, since it will end up different between the two images.
> 4) The <picture> version has to use a specific order, while in the srcset version, order doesn't matter.

Does the id="catface_picture" attribute play an essential role in this
example, or is it just extra clutter in the <picture> example?

Adam
Received on Saturday, 12 May 2012 19:36:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:08 GMT