Re: [cssom] Author-defined at-rules

Le 28/06/2013 02:22, Jon Rimmer a écrit :
> 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?

Although I agree that extensiblity is a good thing in general, I’m not 
sure about this specific proposal.

By itself, going through the CSS parser only to get strings back does 
not seem useful. This proposal only looks interesting when such at-rules 
are in conditional rules, to get notified when the condition changes.

But what would this enable that is not already possible with existing 
APIs like CSS.supports(), window.matchMedia() and MediaQueryList. 
addListener() ? Or what would become significantly easier?

http://www.w3.org/TR/css3-conditional/#the-css-interface
http://www.w3.org/TR/cssom-view/#extensions-to-the-window-interface
http://www.w3.org/TR/cssom-view/#mediaquerylist

Perhaps give an example of how you would use this?

Cheers,
-- 
Simon Sapin

Received on Friday, 28 June 2013 15:46:11 UTC