[whatwg] The src-N proposal
w3c at adambarth.com
Sun Nov 10 14:56:48 PST 2013
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
>> 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
> (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 
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
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
> 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
> 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.
More information about the whatwg