- From: Adam Barth <w3c@adambarth.com>
- Date: Sun, 10 Nov 2013 14:56:48 -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>
On Sun, Nov 10, 2013 at 1:53 PM, 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] Agreed. I recommend removing viewport switching from srcset and addressing only the device-pixel-ratio use case. > (4) - srcset does not provide any easy way to extend itself for art > direction That's ok. We'll just need to add another mechanism in the future to address art direction. > By contrast, src-N is a superset: it covers (1) and (2), with same syntax > even; it addresses (3); it enables (4). Unfortunately, src-N is no-go because WebKit refuses to implement it. Now, it's possible you'll convince them that it's not "a grotesque perversion of the HTML language" (which does seems a bit hyperbolic), but that seems unlikely to happen in the near term. Given the tenor of that discussion, I'd expect we'll need to come up with a new approach and involve stakeholders from the WebKit community earlier in the design process. > We have Mozilla and RICG behind src-N, and I hope Blink can put its weight > behind it also.. There's certainly interest in src-N from the Blink community, but we're unlikely to ship something here that WebKit refuses to implement. > I hope we can all work with Webkit team to address their > concerns and solve this problem once and for all. Me too. However, I don't want to wait for that to happen. I want to ship something that addresses the device-pixel-ratio use case in the near term and continue discussing how to address the remaining use cases. > 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? It's not. The only use case srcset will address is the device-pixel-ratio use case. Adam
Received on Sunday, 10 November 2013 22:57:45 UTC