[whatwg] The src-N proposal

[Tab Atkins Jr.]

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? 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, 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.)

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.

~TJ