Intent to Implement and Ship: HTMLImageElement's srcset attribute (DPR switching)

[Yoav Weiss]

Primary eng (and PM) emails

yo...@yoav.ws

Spec

http://www.w3.org/TR/html-srcset/

Summary

The `srcset` attribute enables authors to adapt image resources to the device's
display characteristics. This intent refers to the DPR switching parts (the 'x' qualifier), which have rough consensus around them.

Motivation

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/284722

CL issue: https://codereview.chromium.org/23861003/

Row on feature dashboard?

Yes.

Requesting approval to ship?

Yes.

[Tab Atkins Jr.]

LGTM, this is a non-controversial and useful subset of the spec syntax.

~TJ

[TAMURA, Kent]

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.

--
TAMURA Kent
Software Engineer, Google

[Rik Cabanier]

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

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Yoav Weiss]

On Mon, Sep 9, 2013 at 4:34 AM, Rik Cabanier <caba...@gmail.com> wrote:

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

I'm hoping to get commitment from other browser vendors during tomorrow's responsive images meetup .
 

(maybe because of the controversy with <picture>)

 

Note that the DPR part (i.e. the 'x' qualifier, which this "intent" is about) is, as Tab stated, a non-controversial subset of the srcset attribute.

 

> Compatibility Risk

> Low. 

I disagree.  The compatibility risk is not low because the specification is still a draft, and there are no shipped products.

 

While it's true that Safari has yet to ship a version with srcset support, I'd consider the implementation and public support of the feature to be good indicators that it will.

Also, I'm not sure other WebKit ports haven't shipped any versions from the time this has landed until now.

Would you consider it safer to ship it under a runtime flag unless commitments from other vendors are made? If so, I can make the changes and modify this "intent" to "intent to implement" only.

[Adam Barth]

I think it's appropriate to implement srcset at this time, but I would like to see either the spec be more mature or another implementation before shipping the feature.  My guess is that by implementing srcset behind a runtime flag, we can encourage other implementors and the standards process towards those goals.

Adam

[Dimitri Glazkov]

On Mon, Sep 9, 2013 at 9:29 AM, Adam Barth <aba...@chromium.org> wrote:

> I think it's appropriate to implement srcset at this time, but I would like
> to see either the spec be more mature or another implementation before
> shipping the feature. My guess is that by implementing srcset behind a
> runtime flag, we can encourage other implementors and the standards process
> towards those goals.

+1. LGTM to implement, pls file a separate intent when ready to ship.

[Ian Hickson]

On Mon, 9 Sep 2013, TAMURA, Kent wrote:
>
> I disagree. The compatibility risk is not low because the specification
> is still a draft, and there are no shipped products.

The specification isn't a draft, it's in the "Awaiting implementation
feedback" stage.

On Mon, 9 Sep 2013, Adam Barth wrote:
>
> I think it's appropriate to implement srcset at this time, but I would
> like to see either the spec be more mature or another implementation
> before shipping the feature.

The specification is as mature as it can get without implementation
feedback.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

[Dimitri Glazkov]

On Mon, Sep 9, 2013 at 2:52 PM, Ian Hickson <i...@hixie.ch> wrote:

> The specification is as mature as it can get without implementation
> feedback.

Can you help me understand how I could determine this myself? The spec
link has a large red banner at the top, warning that it's a work in
progress. The editor's draft has today's last edit date.

:DG<

[Ian Hickson]

I'm not sure which specification you mean.

srcset="" is part of the HTML standard:

http://www.whatwg.org/specs/web-apps/current-work/#attr-img-srcset

The box on the right says "Awaiting implementation feedback".

[Ian Hickson]

On Mon, 9 Sep 2013, Ian Hickson wrote:
>
> srcset="" is part of the HTML standard:
>
> http://www.whatwg.org/specs/web-apps/current-work/#attr-img-srcset
>
> The box on the right says "Awaiting implementation feedback".

Uh, the box on the left. In the margin.

[Dimitri Glazkov]

On Mon, Sep 9, 2013 at 3:05 PM, Ian Hickson <i...@hixie.ch> wrote:
> On Mon, 9 Sep 2013, Ian Hickson wrote:
>>
>> srcset="" is part of the HTML standard:
>>
>> http://www.whatwg.org/specs/web-apps/current-work/#attr-img-srcset
>>
>> The box on the right says "Awaiting implementation feedback".
>
> Uh, the box on the left. In the margin.

Ah, I see. Yoav linked to http://www.w3.org/TR/html-srcset/ at the
start of this thread, so I was using that.

:DG<

[Yoav Weiss]

I've updated the CL, adding runtime flags.

[Rik Cabanier]

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?

From today's meeting, it looks like mozilla is also working on it: http://www.shanehudson.net/2013/09/10/responsive-images-meeting-notes/

The competing <picture> proposal dropped their solution for switching on pixel density.

 

[Shane Hudson]

I'm glad you found my notes useful! I would like to quickly clarify that the `picture` proposal didn’t contain a competing solution for DPR, and instead relying on `srcset` for that purpose. The agreement at the recent meetup was that `picture` should focus on the art-direction use case and `srcset` should continue to focus on DPR (which has been deemed high priority).

[igri...@google.com]

> Compatibility Risk

> Low. 

I disagree.  The compatibility risk is not low because the specification is still a draft, and there are no shipped products.

 

Based on discussions at the Paris meetup the conclusion was that srcset should be ready to go to last call -- there are two outstanding issues, neither of which are blocking because art direction case is effectively out of scope for srcset.

DPR-switching via srcset is available in webkit nightlies, and Mozilla / IE didn't have any objections to it either. In effect, I think we've all converged on srcset for DPR-switching. Other parts of the spec may require a bit more implementation experience. For more details, my notes and takeaways from the event: https://docs.google.com/document/d/1gWy8ZpRcZjt6_00ISxTo3j2umrLEUQI_kutTCFEqOB4.

Given the above, I think the current CL (DPR-switching) is low risk, and something we should consider shipping... and then experiment with resolution-switching as a separate effort -- there is no need to couple the different use-cases.

ig

[Ian Hickson]

On Fri, 13 Sep 2013, igri...@google.com wrote:
>
> Based on discussions at the Paris meetup the conclusion was that srcset
> should be ready to go to last call -- there are two outstanding

> issues<https://www.w3.org/bugzilla_public/buglist.cgi?product=HTML%20WG&component=The%20srcset%20attribute&resolution=--->,

> neither of which are blocking because art direction case is effectively
> out of scope for srcset.

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

> DPR-switching via srcset is available in webkit nightlies, and Mozilla /
> IE didn't have any objections to it either. In effect, I think we've all
> converged on srcset for DPR-switching. Other parts of the spec may
> require a bit more implementation experience. For more details, my notes
> and takeaways from the event:
> https://docs.google.com/document/d/1gWy8ZpRcZjt6_00ISxTo3j2umrLEUQI_kutTCFEqOB4.

The main use case for height-based stuff is vertical text environments,
same as the 'height' feature in Media Queries.

As far as srcset="" not providing guarantees for art direction: it
provides the same guarantees as CSS. I don't understand why that's not
enough. It's enough for CSS, no?

The art direction use case was a big factor in the requests from Web
authors. I don't see much value in it myself, but I think we do Web
authors a disservice if we ignore thier use cases, especially since we are
going to such lengths to try to convince them that we actually care about
their feedback. :-)

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

[Ilya Grigorik]

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

Thanks for clarification. Yet more reasons why we should consider pushing this along faster. :)

 

As far as srcset="" not providing guarantees for art direction: it

provides the same guarantees as CSS. I don't understand why that's not
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. Granted, some of this more hypothetical at this point, since this depends on how different UA's implement this asset selection logic -- if they always select the right "x" resource, then this is not an issue.

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.

We're only talking about pixel density.

 

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

We should take this up on the CH thread to avoid going offtopic, but very briefly: the primary concern so far is that once a new header is added, it's very expensive / near impossible to remove it. I believe this can be mitigated entirely through a simple opt-in mechanism - aka, only sites that want to use CH would trigger it. I'll followup with more details on this on the CH thread.

[Ian Hickson]

On Fri, 13 Sep 2013, Ilya Grigorik wrote:
>
> Thanks for clarification. Yet more reasons why we should consider
> pushing this along faster. :)

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

Sure, but how is this different than CSS?

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?

[Ilya Grigorik]

Assuming you mean "ship it", then +1. :-)

Yes, ship it!

 

> > As far as srcset="" not providing guarantees for art direction: it

> > provides the same guarantees as CSS. I don't understand why that's not
> > 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.

Sure, but how is this different than CSS?

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?

Fair enough. Personally, I think that's a reasonable position to take.

[Yoav Weiss]

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

Sure, but how is this different than CSS?

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 problem here is in the author and user expectations level.

Ideally, we'd want two distinct options:

1. Viewport based resolution switching - the author "guaranties" that the image resources differ from each other only in quality and dimensions - the provided image is essentially the same image, with the same proportions. In this case, the browser can have more liberty in "downgrading" the image for the user in order to speed the page up, save battery or the user's data plan, etc.

In term of user-experience, the user will see a perfectly legible, that fits the layout, but in lower quality than expected.

2. Art-direction - In this case, the provided resources can be different crops of the same "master" image, but they are likely to have different proportions. "downgrading" the resource in this case, while providing the same speed, battery and data plan savings, can often mean a bad user experience since the image's proportions may not match the layout (most likely resulting in a distorted image), or unfitting the layout (e.g. a close-up low-quality crop of the original image).

Separating the 2 cases would help to match everyone's expectations: Authors would have more confidence (even if not a guaranty, as you stated) that their users will receive the image they intended for them to receive, possibly in somewhat lower quality, and users will have more confidence that a "save bandwidth" option, that may use image downgrading once srcset lands, will be less likely to result in broken layout, or distorted images, only in lower quality ones.

Another problem with srcset and art-direction is that the viewport dimensions are specified in pixels, which may create a discrepancy between the layout and the provided image resource when the user has an untypical default font size (Kindle users are one example. Visually impaired users are another). Many authors define their layout MQs in EMs in order to better serve these users. Art-direction with current srcset will mean these users are likely to receive image resources that don't fit their layout.

I'm sure these art-direction related issues can be resolved within srcset (e.g. by adding some 'artdirected' flag, and a 'viewport width according to ems' unit) in the future. As long as they're not, I think it's better to say srcset doesn't (yet?) support art-direction, than have content that mixes the resolution-switching and art-directions cases, preventing future browser optimization in the resolution switching case.

[Yoav Weiss]

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.

[w...@marcosc.com]

On Saturday, September 21, 2013 7:23:34 AM UTC+1, Yoav Weiss wrote:

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.

Nice one :)

Mozilla also intends to implement hopefully a little bit later this year.  Person implementing on the Moz side will be John Schoenick.

Please track: https://bugzilla.mozilla.org/show_bug.cgi?id=870021

[Christian Biesinger]

Thanks for all your work on this!

-christian

[John Mellor]

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

[Adam Barth]

Are other vendors interested in srcN?  It seemed like we were on the verge of critical mass for srcset...

Adam

[Ian Hickson]

On Sun, 29 Sep 2013, John Mellor wrote:
>
> 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

If you want work like this to affect the spec, please don't make the same
mistake that the <picture> proposal proponents made: discuss the proposal
from the very start on a multi-vendor forum with browser vendors and the
relevant spec editor, i.e., wha...@whatwg.org.

[Yoav Weiss]

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)

[w...@marcosc.com]

On Sunday, September 29, 2013 1:49:20 AM UTC+1, Adam Barth wrote:

Are other vendors interested in srcN?  It seemed like we were on the verge of critical mass for srcset...

Mozilla is interested, but I need to bounce it around internally a bit more. We are not a big fan of srcset, but it seemed like it provided a good evolutionary path. srcN kinda changes the game a bit so we need a few weeks to poke at it before we make a decision on how we are going to proceed.

Hixie's suggestion of sending the srcN spec to the WHATWG for discussion would probably be good. Few more eyes on this can't hurt.

[Tab Atkins Jr.]

On Sat, Sep 28, 2013 at 5:49 PM, Adam Barth <aba...@chromium.org> wrote:
> Are other vendors interested in srcN? It seemed like we were on the verge
> of critical mass for srcset...

Note that srcN is not blocking on srcset - if we decided to still ship
srcset, and then later decided to ship srcN, srcset just joins src in
defining the fallback images (used when none of the srcN media queries
match).

On Sat, Sep 28, 2013 at 6:36 PM, Ian Hickson <i...@hixie.ch> wrote:
> On Sun, 29 Sep 2013, John Mellor wrote:

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

> If you want work like this to affect the spec, please don't make the same
> mistake that the <picture> proposal proponents made: discuss the proposal
> from the very start on a multi-vendor forum with browser vendors and the
> relevant spec editor, i.e., wha...@whatwg.org.

Yup, I just wanted to socialize it with the respimg people first, to
make sure there wasn't something obviously wrong. People seem very
positive about it, so I'm ready to bring it up in WHATWG.

~TJ