On May 12, 2012, at 12:35 PM, Adam Barth <w...@adambarth.com> wrote:
> On Sat, May 12, 2012 at 11:17 AM, Maciej Stachowiak <m...@apple.com> wrote: >> >> On May 12, 2012, at 6:28 AM, Mathew Marquis <m...@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="catf...@2x.jpg 2x"> >> >> <picture style="width: 600px; width: 200px" id="catface_picture" alt="A >> cat's face"> >> <source src="catface.jpg"> >> <source src="catf...@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? Extra clutter. I forgot to delete it after I switched that example from using externally declared <style> to a style attribute. Corrected versions: <img src="catface.jpg" alt="A cat's face" srcset="catf...@2x.jpg 2x"> <picture style="width: 600px; width: 200px" alt="A cat's face"> <source src="catface.jpg"> <source src="catf...@2x.jpg" media="min-device-pixel-ratio: 2"> <img src="catface.jpg" alt="A cat's face"> </picture>
