RE: Media Queries and optimizing what data gets transferred

> Date: Fri, 25 Jan 2013 14:20:49 +0200
> From: hsivonen@iki.fi
> To: www-style@w3.org
> CC: ilya@igvita.com
> Subject: Media Queries and optimizing what data gets transferred
> 
> Media Queries solve the problem of applying the style rules that are
> relevant to the current state of the user agent. Media Queries don't
> solve the problem of promising to avoid the transfer of data that is
> not relevant to the state of the user agent at the time of the page
> load.

Why is a 'promise' required?  Surely the UA can choose not to download
resources that are not needed?  If anything, some hints for the UA
might be much more useful.

If the UA does not want to leak device configuration state that could be
be used for fingerprinting then it might choose to download all resources.

Really, media queries are a really poor design direction and should be
deprecated not enhanced.  Development would be better put into fluid
design support, allowing media queries to be avoided entirely.

For example, rather than adding a media query for screens that need
high contrast images, add support for image color transforms that can
applied by the UA when needed.

> It turns out that Web authors want the latter problem to be solved also.

Why is this any business of the authors?  Surely it is a matter for the UA
which resources it chooses to use.
 
> What inspires me to write this e-mail to www-style today is a proposal
> from Google that seeks to work around this problem on the HTTP level.
> I think working around the design of Media Queries on the HTTP level
> is the wrong solution. I think it would be much better to adjust the
> way Media Queries work so that they don't need to be worked around.

Agreed, a shockingly poor proposal.  The response should 'adapt' to the
URL and/or the request body, but not to a hint of device characteristics
in a header.

...
> To my knowledge, that there is a problem to be worked around has not
> been raised at the CSS working group. I think it would be terribly sad
> if Chrome went ahead and deployed an HTTP-based workaround before the
> CSS working group even has a chance to address the problem. That's why
> I'm raising this issue now here.

Glad someone did.
 
> I understand that there are various situations where the user can do
> things such as print, zoom or change screen orientation and browsers
> have a good reason to already have downloaded the data that ends up
> applying according to Media Queries after such a user-initiated change
> of user agent state. That is, *I* understand why Media Queries work
> how they work. However, to the extent Web authors prioritize the
> avoidance of data transfer over the design's ability to dynamically
> adapt to such changes of state, I think it would be better to give Web
> authors that control with Media Queries instead of having Web authors
> take that control by other means (JavaScript libraries or HTTP-level
> solutions—either cookie-based or supported by the browser as in the
> Client-Hints proposal).

The solution is to avoid media queries.  Use fluid designs for layout.

Design to support the UA making a choice of which resources to load.
Media queries are a poor solution, a stop gap measure, please deprecate
them.

> Thus I propose that Media Queries gain a way to be flagged as
> evaluated only at page load time such that the browser promises to the
> Web author that it won't eagerly download data that's not applicable
> in the state the browser is in during the page load.

The UA may have good reason to download resources, such as
avoiding being fingerprinted, or wanting to be ready for an orientation
change, or ready for zooming operations, to be ready to operate
offline, etc.

Just learn how to write fluid webpages.
 
> Reasons why I think introducing an HTTP-based solution would be worse
> than adjusting CSS include:
>  * HTTP caches don't know what the negotiation logic is, so they need
> to check with the origin server for each Client-Hints header value
> that they don't already have a cache key.

Yes, it breaks caching.

...
>  * It's bad to have to add server-side logic when CSS almost has the
> feature authors want but not exactly.

Yes, agreed.

Thank you for the heads up.

cheers
Fred