Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Nephyrin opened this issue Apr 18, 2014 · 8 comments
Assignees

Comments

@Nephyrin
Copy link

@Nephyrin Nephyrin commented Apr 18, 2014

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
Copy link
Member

@yoavweiss yoavweiss commented Apr 18, 2014

👍

@tabatkins
Copy link

@tabatkins tabatkins commented Apr 19, 2014

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

@zcorpan
Copy link

@zcorpan zcorpan commented Apr 22, 2014

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

@tabatkins tabatkins self-assigned this Apr 25, 2014
@cbiesinger
Copy link

@cbiesinger cbiesinger commented May 16, 2014

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
Copy link
Member

@yoavweiss yoavweiss commented Jun 25, 2014

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

@tabatkins tabatkins commented Jun 25, 2014

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

@zcorpan zcorpan commented Jan 21, 2015

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
Copy link
Member

@yoavweiss yoavweiss commented May 19, 2015

@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 ^_^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.