- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Mon, 11 Nov 2013 11:44:41 +0800
- To: Ilya Grigorik <igrigorik@gmail.com>
- Cc: WHATWG <whatwg@whatwg.org>, Yoav Weiss <yoav@yoav.ws>, "Tab Atkins, Jr." <jackalmage@gmail.com>, Ian Hickson <ian@hixie.ch>, Adam Barth <w3c@adambarth.com>
On Nov 11, 2013, at 5:53 AM, Ilya Grigorik <igrigorik@gmail.com> wrote: > On Sun, Nov 10, 2013 at 12:58 PM, Adam Barth <w3c@adambarth.com> wrote: > >>> I believe you're applying an inappropriately high standard of required >>> agreement to this proposal, compared to what the usual required level >>> is for something to be accepted. >> >> If Blink ships src-N and WebKit ships srcset, we'll have a mess on our >> hands. Authors will end up using both. If they do, they're likely to have >> different behavior in different browsers, which is an interoperability >> problem. >> >> The best solution I see to the above constraints is to ship >> device-pixel-ratio switching via srcset today and to continue to discuss >> how to address the remaining use cases in the future. >> > srcset is a cul de sac with respect to these goals. Let's look at our > options: > > (1) + srcset addresses resolution-switching. > (2) + in theory, srcset provides basic facilities for viewport-switching - > although none of the current implementations support it. > (3) - srcset viewport-switching syntax is a disaster for real-world > scenarios [1] > (4) - srcset does not provide any easy way to extend itself for art > direction > > By contrast, src-N is a superset: it covers (1) and (2), with same syntax > even; it addresses (3); it enables (4). > > Viewport-switching is just as important as res-switching: ultimately both > are about saving bytes, and both have similar footprint in terms of pixels > and bytes shipped. Further, they're not independent problems. After all, > the outcome is that we ship a single file based on both parameters, hence > the two must work together well (-1 for srcset). Finally, UX matters too > (art-direction) and this case must work together with the previous two (-1 > for srscet). > > In short, whatever solution we adopt, it must address all three points in > the long run -- this is not a problem with three independent pieces that > can be solved by three independent specs. We have three inputs, and we have > one output: download X... and I just don't see srcset addressing these > criteria. If someone can show me how srcset can, in fact, do this in > future, then I'd love to hear it. > > We have Mozilla and RICG behind src-N, and I hope Blink can put its weight > behind it also.. I hope we can all work with Webkit team to address their > concerns and solve this problem once and for all. So far, as Tab has > pointed out, the src-N concerns we've heard are all cosmetic, and I think > those discussions are distracting us from the real conversation we should > be having, which is... how is srcset planning to address its shortcomings > in a better way than src-N? We can modify the parsing algorithm so that it can support delimiters for example. - R. Niwa
Received on Monday, 11 November 2013 03:46:07 UTC