[whatwg] The src-N proposal

[Adam Barth]

On Nov 10, 2013 11:39 AM, "Tab Atkins Jr." <jackalmage at gmail.com> wrote:
>
> On Sun, Nov 10, 2013 at 10:46 AM, Adam Barth <w3c at adambarth.com> wrote:
> > On Sun, Nov 10, 2013 at 9:29 AM, Ilya Grigorik <igrigorik at gmail.com>
wrote:
> >> On Sun, Nov 10, 2013 at 8:59 AM, Tab Atkins Jr. <jackalmage at 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.
>
> Can you explain why?

It's for the reason in the second paragraph of my previous email: I don't
think we'll get agreement about how to address the other use cases in the
near term and I view the device-pixel-ratio use case as important to
address in the near term.

> I believe the RICG's identified use-cases are
> both reasonable and minimal.  If we address *only* the density case
> right now, significant fractions of *existing* responsive images code
> won't be able to migrate to the standardized solution, and will be
> stuck with hacks.
>
> We'll obviously never be able to satisfy 100% of use-cases, nor is
> anyone trying to.  But just density isn't enough, based on the
> observed patterns in the wild.
>
> >> and is the only option that does so. Serving images in our
> >> new multi-device / responsive design world *is* a much harder problem
and
> >> the "complexity" of src-N is simply a reflection of that.. Sticking our
> >> heads in the sand and pretending that this is not the case, or punting
the
> >> problem down the road (as we've already done for the past few years),
is not
> >> a sound strategy.
> >
> > If we wait for agreement about how to address the other use cases, we
> > won't ship anything for a long time.  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.
>
> The RICG and related community has agreed on src-N, and the relevant
> Blink and FF devs have as well.  The only holdout is WebKit,

That's exactly the problem.  The WebKit community has been clear they don't
want to ship src-N.

> but they
> haven't expressed any technical objections, just aesthetic ones.
> (And, not to be rude, but I don't trust the aesthetic judgement of C++
> hackers when applied to the web platform; at least, not over the
> judgement of actual JS and HTML hackers, who are generally fine with
> the look of src-N.  People who write the web rather than write *in*
> the web have a long history of liking terribly-shaped APIs because
> they're more familiar to C++ coders.)  (IE hasn't expressed an opinion
> one way or the other, as usual.)

You might not find their reasons compelling, but that's largely beside the
point.  What's relevant is that they aren't willing to ship src-N.  Maybe
through additional discussion we could find a mutually agreeable approach
for addressing the remaining use cases, but that appears unlikely to happen
in the near term.

> 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.

Adam