- From: Yoav Weiss <yoav@yoav.ws>
- Date: Fri, 31 May 2013 21:47:34 +0200
- 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>
- Message-ID: <CACj=BEjTwGYV7va5k9xU-5iyq29S4u_GQKi+UqHv2WVurA09hw@mail.gmail.com>
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