[whatwg] The src-N proposal

[Ryosuke Niwa]

On Nov 11, 2013, at 5:53 AM, Ilya Grigorik <igrigorik at gmail.com> wrote:

> On Sun, Nov 10, 2013 at 12:58 PM, Adam Barth <w3c at 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