- From: Stu Cox <stuart.cox@gmail.com>
- Date: Mon, 10 Jun 2013 12:31:37 +0100
- To: Simon Sapin <simon.sapin@exyr.org>
- Cc: Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
- Message-ID: <CAJ-2Ov6CH6cyeDQg9aA2hF3xsccaA0ntALqvQYAEe_GLxEg90A@mail.gmail.com>
I should probably point out that this suggestion probably targets quite a separate use case from the 'macros' Simon suggested. On 10 June 2013 12:29, Stu Cox <stuart.cox@gmail.com> wrote: > I love this idea, but is there actually much scope for new *media* queries > to be defined, given the limited information available to the DOM? > > I'd argue not, and that the Modernizr / theming use cases may be more > common. > > I think there's already a problem with confusion between browser features > and media/device features (e.g. my old favourite: browser supporting the > Touch Events API vs device having a touchscreen). Values set by users in JS > are unlikely to accurately represent a feature of the media. > > > So how about e.g. `@property` instead? > > <script> > document.css.properties.haswebgl = 'WebGLRenderingContext' in window; > document.css.properties.theme = 'night'; > document.css.properties.connectedusers = MyApp.getConnectedUsers(); > </script> > > <style> > @property hasaudioapi { ... } > @property (theme:night) { ... } > @property (min-connectedusers:10) { ... } > </style> > > > I'm totally not precious about that name – just that it shouldn't be > `@media`. > > This would also solve the issue of name conflicts with future media > queries. > > > Stu Cox > > > > On 2 June 2013 13:41, Simon Sapin <simon.sapin@exyr.org> wrote: > >> Le 02/06/2013 20:16, Kenneth Rohde Christiansen a écrit : >> >> Hi, >>> >>> Can you explain to me what you mean with "parse-time declarative >>> macros"? like for instance give an example. >>> >> >> Declarative: when you state what happens but not how it happens, as >> opposed to imperative. In Selectors, :hover is declarative while >> adding/removing a class with mouse events is imperative. >> >> Macro: a kind of variables, but I wanted another term because this is not >> CSS Variables a.k.a. Custom Properties. This is two parts: one that >> associates a name with a value, and one that uses the name, which is >> replaced by the value. >> >> Parse-time: the replacement is done when the stylesheet is parsed, as >> opposed to eg. every time the result of the MQ needs to change. >> >> >> Here is an example with made-up syntax: >> >> @macros { wide: (min-width: 700px) } >> @import "foo.css" $wide >> @media $wide { /* ... */ } >> >> >> This kind of macro could potentially be used anywhere (MQs, Selectors, >> property names …) unlike var() that can only be used in property values. >> >> >> >> In WebKit/Blink the engine >>> knows which media features change as a result of viewport changes and it >>> only reevaluates those when the viewport changes (size, scale/zoom, >>> etc). If the engine knows then invented conditionals change, we could do >>> similar. >>> >> >> Yes, MQs being declarative allows the engine to do that and apply the >> change without going through JavaScript code. >> >> -- >> Simon Sapin >> >> >
Received on Monday, 10 June 2013 11:32:35 UTC