[whatwg] The src-N proposal

[Ilya Grigorik]

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?

[1] http://www.xanthir.com/b4Su0