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

Re: [mediaqueries] User-defined Media Queries?

From: Yoav Weiss <yoav@yoav.ws>
Date: Fri, 31 May 2013 21:47:34 +0200
Message-ID: <CACj=BEjTwGYV7va5k9xU-5iyq29S4u_GQKi+UqHv2WVurA09hw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Chris Eppstein <chris@eppsteins.net>, Yehuda Katz <wycats@gmail.com>, www-style list <www-style@w3.org>
As the initiator of the previous thread on the subject, I like this
proposal.
It will certainly enable authors to DRY their current media queries, as
well as extend them in creative ways.

What worries me about this proposal is the preloader. Currently only
external CSS can be loaded (and preloaded) according to MQs, but there's no
reason to stop there. Different layouts per MQ will require loading of
different resources per MQ, be it content images, external JS, background
images, fonts, etc.
Even if we want to download all the page's resources, to have them
available in case the MQ will change, we should not preload unnecessary
resources and block other, required resources. They should be downloaded,
as they do today, as low priority resources, if they're downloaded at all.
I would love if such a proposal would take the preloader into consideration
and enable such MQ definitions in a restricted inline
script, that must be placed at the HTML's top, before any other resource
that require loading (but possibly after an inline CSS with an @viewport
directive) that the preloader can recognize.

An (extremely hand-wavy) example design for that might be a CSP-permitted,
limited inline script (distinguished using an attribute) that runs inside a
worker, with read-only access to `window` (in order for it to make its MQ
decisions). That script will immediately return a future to the parser.
(Not sure how)
That future will contain the list of media query values to the parser, once
the worker finished running. The parser can then continue to parse the
HTML, and query the future the next time that it encounters a custom MQ, to
understand if it's true or false.
That query may cause some fairly-limited blocking in some cases, but
probably not in most.

Thoughts?


On Fri, May 31, 2013 at 9:26 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Fri, May 31, 2013 at 11:53 AM, Chris Eppstein <chris@eppsteins.net>
> wrote:
> > I don't think we need to move away from the property/value pair syntax
> that
> > is already in use:
> >
> > @media (name: huge) or (name: medium) { ... }
>
> This wouldn't be - I was assuming that a string would be the media
> query name, and you can assign document.css.media.foo any string value
> and test for it in the media query, like:
>
> <script>
> document.css.media.foo = "bar";
> </script>
> <style>
> @media ("foo": "bar") { ... }
> </style>
>
> But a bare string, just like a bare media query, would match if the
> value was true only.
>
> ~TJ
>
>
Received on Friday, 31 May 2013 19:48:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:30 UTC