Primary eng (and PM) emails
Spec
http://www.w3.org/TR/html-srcset/
Summary
The `srcset` attribute enables authors to adapt image resources to the device'sMotivation
New device form factors and screen DPRs are added to the market on a regular basis. Serving the same image resources to all devices (which may display them in differing dimensions and at different DPRs) is wasteful, and hurts Web performance.
This feature will start resolving this problem, by enabling Web authors to specify multiple resources, with varying DPR qualities, and let the browser pick the resource that matches the device's capabilities.
Compatibility Risk
Low.
This feature is identical to the feature that landed in WebKit recently (The CL is a port of the WebKit code). It is not yet implemented in IE or Firefox.
The feature's syntax include an inherent fallback mechanism for authors, where non-supporting browsers will simply fetch the resource specified in the `src` attribute. (resulting in a sub-optimal, but fully-functional image)
Ongoing technical constraints
None.
Link to “Intent to Implement” blink-dev discussion
There was no previous "Intent to implement", but there was a previous discussion on Blink-dev which was mostly positive.
Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Yes.
OWP launch tracking bug?
http://crbug.com/284722Row on feature dashboard?
Yes.
Requesting approval to ship?
Yes.
> Compatibility Risk
> Low.
Do other browser vendor like srcset? Do they have plans to implement it?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
On Sun, Sep 8, 2013 at 5:58 PM, TAMURA, Kent <tk...@chromium.org> wrote:
Do other browser vendor like srcset? Do they have plans to implement it?WebKit supports it: https://www.webkit.org/blog/2910/improved-support-for-high-resolution-displays-with-the-srcset-image-attribute/
I believe there has been no sign from the other vendors
(maybe because of the controversy with <picture>)
> Compatibility Risk
> Low.
I disagree. The compatibility risk is not low because the specification is still a draft, and there are no shipped products.
Do other browser vendor like srcset? Do they have plans to implement it?
> Compatibility Risk> Low.
I disagree. The compatibility risk is not low because the specification is still a draft, and there are no shipped products.
As far as I can tell, both of those issues are just placeholders for
WHATWG issues that are actually already closed, pending more feedback:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20212
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20209
FWIW, srcset="" is already past last call at the WHATWG (it's in the
"Awaiting implementation feedback" stage).
As far as srcset="" not providing guarantees for art direction: itprovides the same guarantees as CSS. I don't understand why that's not
enough. It's enough for CSS, no?
As far as Client-Hints goes, one thing I see missing from the discussion
is the fingerprinting impact. It would depend on how much is exposed;
obviously if it's just the pixel density then we're already exposing that
so it's a moot case, but if we start adding more and more then the impact
will be proportionally bigger.
Also, I understand that people at the
meeting weren't as skeptical about conneg as others are, but that doesn't
mean there's nobody with those concerns -- just that nobody with those
concerns was present. That's one reason I don't like face-to-face
meetings: they tend to disenfranchise those who don't turn up (e.g. for
health reasons, financial reasons, logistical reasons, etc).
Assuming you mean "ship it", then +1. :-)
> > As far as srcset="" not providing guarantees for art direction: it
> > provides the same guarantees as CSS. I don't understand why that's notSure, but how is this different than CSS?
> > enough. It's enough for CSS, no?
>
> The concern was that the algorithm provides a lot of leeway to the UA to
> select the resource - e.g. you may specify a 2x resource, but UA may
> still pick the 1x resource due to client configuration, or other
> preferences. As such, if your design depends on a "must use this image
> for this layout", this may lead to wrong image being shown.
CSS is entirely optional. A browser is still conforming if it just ignores
all your style sheets. Or if it overrides certain parts because the user
feels like it. This can lead to the entirely "wrong" layout, different
fonts, different sizes, different colours... what's special about srcset?
> The concern was that the algorithm provides a lot of leeway to the UA toSure, but how is this different than CSS?
> select the resource - e.g. you may specify a 2x resource, but UA may
> still pick the 1x resource due to client configuration, or other
> preferences. As such, if your design depends on a "must use this image
> for this layout", this may lead to wrong image being shown.
CSS is entirely optional. A browser is still conforming if it just ignores
all your style sheets. Or if it overrides certain parts because the user
feels like it. This can lead to the entirely "wrong" layout, different
fonts, different sizes, different colours... what's special about srcset?
The CL implementing srcset's DPR switching behind a flag just landed: https://chromiumcodereview.appspot.com/23861003/I'll send a separate "Intent to ship" shortly.
Thanks Yoav, great work implementing this! However, could I throw a spanner in the works and suggest that we hold off shipping this quite yet?
Tab and I recently thrashed out "srcN", an alternative to both srcset and <picture>: http://tabatkins.github.io/specs/respimg/Overview.html
I've explained why it works better than srcset and <picture> here: http://lists.w3.org/Archives/Public/public-respimg/2013Sep/0088.html
Unfortunately, unlike <picture>, it doesn't build on top of srcset, instead it completely replaces srcset.
(the basic srcset syntax becomes a subset of srcN, so we'd certainly be able to reuse Yoav's implementation; it might even be an option to rename srcset to src1 in the current implementation and ship it as is as an incremental step towards src1, though arguably to make feature detection easier it might be better to wait until we've implemented the full srcN syntax?)
Sorry about the late notice - Tab and I only came up with this last Tuesday, when we discussed some of the issues raised at EdgeConf and the Paris meet up.
-- John
I 100% agree that the srcN proposal changes the picture (no pun intended), and we should hold off shipping srcset until the smoke clears.
I'm very excited about the proposal. Thanks for putting it together.
Regarding code reuse, I think will be able to reuse large parts of the srcset implementation for srcN, as well as some parts of the picture prototype implementation. (Mainly the PreloadScanner parts)
Are other vendors interested in srcN? It seemed like we were on the verge of critical mass for srcset...