Re: [cssom] Author-defined at-rules

On Thu, Jun 27, 2013 at 6:22 PM, Jon Rimmer <jon.rimmer@gmail.com> wrote:
> With the development of Web Animations and the talk of the "extensible
> web", I've been thinking about new syntaxes for declarative control of
> animations and state machines in CSS. It would be good to be able to
> prototype and polyfill such new syntaxes, but this is difficult within
> CSS. I think that something that would help improve the situation is
> author-defined at-rules.
>
> The idea is straightforward: Provide an API to register script
> handlers for "var-" prefixed at-rules. When encountering a "var-"
> prefixed at-rule within a stylesheet, the CSS parser would consume and
> store the prelude and braced contents (if any), but not attempt to
> further parse or otherwise interpret them.
>
> When the at-rule is considered to be applicable, e.g. immediately, or
> when its containing media query becomes true, the handler is notified
> via a callback and the stored contents passed in. If the at-rule
> becomes inapplicable, the handler is also notified. An API might look
> something like this:
>
> <style>
>     @var-myrule prelude { content }
> </style>
>
> <script>
> var parser = document.getStyleParser('text/css');
>
> parser.addAtRule('myrule', {
>     onActive: function(id, prelude, content, scope) {
>         do something...
>     },
>     onInactive: function(id) {
>         do something...
>     }
> });
> </script>
>
> The "id" parameter would be a unique string identifier generated by
> the browser, e.g. '@var-myrule:1'.
>
> The "scope" parameter would be the DOM element that the stylesheet
> containing the at-rule is scoped to, if any.
>
> The first version of this API could simply pass the prelude and
> content as strings, leaving any parsing and interpretation to the
> handler. Later, it could be enhanced to provide the ability to specify
> how the browser should preprocess the content before passing it to the
> handler. For example, it could be told to tokenize the content, but
> not parse it, and pass a stream of tokens. Or it could be told to
> parse the content as CSS and pass an AST.
>
> Thoughts? Is this possible? Potentially useful? Insane?

I'm with Simon.  I don't understand what this actually buys you.  The
core ability given by your proposal appears to just be the ability to
get a callback called when an MQ starts or stops matching.  That's
already provided by matchMedia("(foo: bar)").addListener(), as Simon
points out.  Whatever data you'd embed in the custom at-rule, just
embed directly in the listener.

~TJ

Received on Friday, 28 June 2013 23:05:42 UTC