W3C home > Mailing lists > Public > www-style@w3.org > September 2013

Re: Media Query Variables

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sun, 15 Sep 2013 10:18:55 -0700
Message-ID: <CAAWBYDAHTHxOB1nKqQMy26EwBAUXKpNuNqHEguyoW9oOZ2-f+A@mail.gmail.com>
To: Kornel Lesiński <kornel@geekhood.net>
Cc: Simon Pieters <simonp@opera.com>, www-style <www-style@w3.org>
On Sat, Sep 14, 2013 at 2:22 PM, Kornel Lesiński <kornel@geekhood.net> wrote:
> On Sat, 14 Sep 2013 19:17:56 +0100, Simon Pieters <simonp@opera.com> wrote:
>>> I don't mind giving authors choice of losing preload scanner if they
>>> prefer all media queries to be in stylesheets.
>>
>> I do mind giving authors a subtle performance footgun.
>
> That's a footgun under assumption that:
>
> - authors will overwhelmingly choose to use variables in external
> stylesheets only (and if they do, then that'll prove it's a very desirable
> feature ;)
> - pushing of CSS with HTML via SPDY/HTTP2 or inlining FEO proxies or page
> preprocessors won't be common enough to mitigate this
> - affected pages won't be hiding image markup from preload scanner by using
> JS-based templating ("MVC" JS apps) or overuse of Web Components
> (<html><my-cool-app/></html>)
> <http://tomdale.net/2013/09/progressive-enhancement-is-dead/>
> - and that 1 RTT delay to start fetching images when CSS is not cached is a
> big problem
>
> So my hope is that it won't become a common footgun. Some pages will get
> increased latency, but that still may be an overall win if easier
> maintenance convinces authors to use smaller media-specific images instead
> of taking other easy route and serving largest <img> to all clients.

Agreed here.  The perf loss of defeating the preload scanner isn't
*that* terrible, and as long as there are easy ways to make it
compatible (such as by doing the definitions in a local <style>, or by
defining a <meta> that can hold them) that can be evangelized, I'm
fine with this.

I'm very much *not* okay with anything that *prevents* people from
defining custom MQs via script or external stylesheet.  The first case
is necessary for doing truly custom MQs based on something you can
determine via JS, which there are lots of minor use-cases for.  The
second case is necessary to prevent this feature from being a weird,
difficult-to-use freak case when you just want to shorten MQs for use
in your own stylesheets.

My preference here, for what it's worth, is to define a <meta> that
can be used to provide simple MQ shortening, like <meta
name=media-query content="foo: (min-width: 500px)">.  This lives
alongside whatever functionality we define for CSS and JS for defining
custom MQs.

~TJ
Received on Sunday, 15 September 2013 17:19:42 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 15 September 2013 17:19:43 UTC