Require MQ-matching changes to trigger a new round of selection for <source media>

[Nephyrin]

For art-direction purposes, leaving it up to the UA to decide when to select a new for MQ-matching changes may lead to inconsistent layout and entirely different images in different browsers. This is different from e.g. sizes matching changes, which should only affect image density/quality.

See: http://ircbot.responsiveimages.org/bot/log/respimg/2014-04-17#T65978

[yoavweiss]

👍

[tabatkins]

Agreed. I'll try to put up a PR for this over the weekend.

[zcorpan]

It might be somewhat difficult in the spec to differentiate between "<source media>" and "sizes" since we reevaluate the whole thing every time.

[cbiesinger]

I have a blink patch that implements this such that a change in something that affects media queries will rerun the source selection algorithm - https://codereview.chromium.org/287163010/

[yoavweiss]

Discussing this on #blink, the question of timing for triggering these requests came up.
Do we want to define a particular time in which these requests need to be sent?

We discussed waiting for layout (which happens at RAF in Blink), and possibly even waiting for the next RAF.

Also - do you think that the spec should define what happens with "intermediate" breakpoints (e.g. if we have 3 breakpoints with a source for each, and the user resizes her window from the smallest to the largest one). Do we want browsers to avoid the "intermediate" image download? (I'm guessing yes) If so, do we want to define anything around that?

[tabatkins]

We don't define precisely when browsers should reevaluate MQs in CSS; we assume that browsers will do so "promptly", and will skip over changes that only happen transiently between evaluation points.

[zcorpan]

The HTML spec now defines animation frames, and things can be synced with it. We could require that the "environment changes" algorithm be run in sync with animation frames. That would handle not running it when the page is in a background tab.

[yoavweiss]

@tabatkins - any news on that old bug? I believe current behavior in Blink and Firefox matches what we want to define here, but it'd be good to actually have it in the spec ^_^