[whatwg] The src-N proposal

[Adam Barth]

On Sun, Nov 10, 2013 at 1:53 PM, 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]

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