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

[cssom] Author-defined at-rules

From: Jon Rimmer <jon.rimmer@gmail.com>
Date: Fri, 28 Jun 2013 02:22:19 +0100
Message-ID: <CA+ZDCiA-eBVsGRwjW9a04SaQjoCCJ0BFhNB-X+074JWAKRvswA@mail.gmail.com>
To: www-style list <www-style@w3.org>
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?

Thanks,
Jon Rimmer
Received on Friday, 28 June 2013 01:22:46 UTC

This archive was generated by hypermail 2.3.1 : Friday, 28 June 2013 01:22:50 UTC