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.

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

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.

The proposal comes in the form of a slide deck
https://docs.google.com/presentation/d/1y_A6VOZy9bD2i0VLHv9ZWr0W3hZJvlTNCDA0itjI0yM/edit
and an RFC-style draft
https://github.com/igrigorik/http-client-hints/blob/master/draft-grigorik-http-client-hints-00.txt

In the slide deck, slide #4 treats the design of Media Queries as a
problem to be worked around and slide #6 identifies the JavaScript
library for working around the problem.

The slide deck then goes on to propose an HTTP-based solution instead
of proposing a modification to Media Queries.

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.

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

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.

For example, a nolive attribute could be introduced to indicate that
the MQ is not meant to be re-evaluated live as the UA state changes.
E.g.
<link rel=stylesheet nolive media="screen and (max-device-width:
800px)" href="foo.css">
to make it so that the MQ is evaluated at load time and not
re-evaluated if the user zooms or rotates the device. Therefore,
foo.css can be left unloaded if the MQ does not match at page load
time. Don’t pay too much attention to the details of this example. I’m
sure the WG is better at designing the particulars. I’m just outlining
some solution to show that it’s possible to come up with one.

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.
 * If the origin server doesn't get ETags right, intermediate caches
end up having a distinct copy of the data for each distinct
Client-Hints header value even if there is a smaller number of
different data alternatives on the origin server.
 * Pushing the resource selection logic in the browser and presenting
the browser with different URLs to choose from allows HTTP
intermediaries to operate simply with URL cache keys. Also, no special
logic is needed on the origin server.
 * Sending any HTTP header incurs extra traffic for all the sites that
don't pay attention to Client-Hints. That would be the whole Web at
least at first. That is, an HTTP-based solution involves a negative
externality for non-participating sites.
 * If we later find out that Client-Hints hasn't become popular enough
to justify the extra traffic, we will be unable to unbloat the HTTP
requests, because there's always *some* site that would break in the
face of such unbloating.
 * It's bad to have to add server-side logic when CSS almost has the
feature authors want but not exactly.
 * It's conceptually bad in terms of the learnability of the Web
Platform that a slight adjustment to the desired behavior would
involve changing the solution the author needs to apply to a
completely different technology in the stack (from MQ to HTTP
negotiation).
 * http://wiki.whatwg.org/wiki/Why_not_conneg

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 25 January 2013 12:21:24 UTC