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

Re: [mediaqueries] User-defined Media Queries?

From: Stu Cox <stuart.cox@gmail.com>
Date: Mon, 10 Jun 2013 12:31:37 +0100
Message-ID: <CAJ-2Ov6CH6cyeDQg9aA2hF3xsccaA0ntALqvQYAEe_GLxEg90A@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:12 UTC