- From: Henri Sivonen <hsivonen@hsivonen.fi>
- Date: Mon, 11 Nov 2013 10:37:53 +0200
- To: Adam Barth <w3c@adambarth.com>
- Cc: Ilya Grigorik <igrigorik@gmail.com>, Yoav Weiss <yoav@yoav.ws>, "Tab Atkins Jr." <jackalmage@gmail.com>, Ian Hickson <ian@hixie.ch>, WHATWG <whatwg@whatwg.org>
On Sun, Nov 10, 2013 at 8:46 PM, Adam Barth <w3c@adambarth.com> wrote: > On Sun, Nov 10, 2013 at 9:29 AM, Ilya Grigorik <igrigorik@gmail.com> wrote: >> On Sun, Nov 10, 2013 at 8:59 AM, Tab Atkins Jr. <jackalmage@gmail.com> >> wrote: >>> It's easy to look at something more complex than what you're used to >>> and dismiss all the excess as unneeded, but it's really, seriously not >>> in this case. The things I'm addressing are the things that RICG >>> research found were common and necessary, no more and no less. >> >> Big +1 to that -- src-N addresses all the RICG use cases in a consistent and >> coherent way.. > > I don't think that's a valuable goal. My preference would be to > address only the device-pixel-ratio use case in this iteration. ... > I'd rather ship something that's > useful today and iterate to improve it in the future than not ship > anything for a long time. Just like AppCache, srcset is not something that you can iterate on. You can't add features without breaking compatibility. Unlike <picture>, src-N isn't substantially harder than srcset to implement, so we might as well address more use cases in one go. I think ignoring some of the use cases while pretending that srcset is the first iteration when it's design is unsuited for iteration is a bad idea. I think srcset should be taken out of the spec ASAP before WebKit ships it and we get stuck with something that doesn't allow iteration. -- Henri Sivonen hsivonen@hsivonen.fi http://hsivonen.fi/
Received on Monday, 11 November 2013 08:38:22 UTC