Re: [cssom] Author-defined at-rules

OK,

I see this as a way of putting any declarative, presentational
configuration for libraries/polyfills within CSS itself. For example,
consider the following example:

#panel {
    var-janimation: bounce;
    var-dragzone: four-corners;
}

@var-jtimeline bounce {
    0s {
        top: 10px !timing(ease)
    }

    1s {
        top: 10px !timing(ease)
    }
}

@var-dragzone four-corners {
    rect(0, 0, 5%, 5%)
    rect(95%, 0, 100%, 5%)
    rect(0, 95%, 5%, 100%)
    rect(95%, 95%, 100%, 10%)
}

Here, imagine I have a couple of JS libraries: One for animation, perhaps
built atop Web Animations, that lets you define a keyframed animation where
keyframes have a time value and properties support an independently
specified timing function. The second allows a drag zone to be specified
via a configured group of hot-spots.

There is plenty more information that could be embedded within custom
at-rules: layouts, audio cues, formulas, gesture descriptions, etc. That's
the point, and it gets to the heart of the idea of the extensible web and
"use case zero"[1]: Providing capabilities that are generally enabling, not
just targeted at some preconceived use case, and that allow libraries to
integrate with and extend existing infrastructure in a *natural* way. CSS
is notoriously difficult to extend, and this would open it up just a little
bit.

If I write an animation library, why should users have to interface with it
via an imperative API? CSS provides an existing infrastructure for
supplying declarative, presentational configuration. The browser loads
stylesheets from <style> and <link> elements, it handles @imports,
prefetching, caching, media and capability queries, etc. I should be able
to leverage that existing infrastructure and just deal with processing the
new syntax I want to introduce.

If you look at polyfills for CSS features like Regions[2] and FlexBox[3],
they all have a bunch of code to do stylesheet loading and CSS parsing,
just so they can let authors mix polyfilled properties in with regular
ones. It's the same old story: A parallel reimplementation of the platform
is required just to extend the platform, and huge amounts of code to allow
for a declarative API (or else authors have to configure everything via an
imperative API).

Take Web Components. There's nothing they implement that you can't do via
imperative methods, Angular proves that, but it's a whole lot easier when
the platform provides those capabilities. And both Web Components and
Angular prove that a declarative way to *use* things, inline with all the
other code you're writing, is a winner.

Personally, I'm interested in experimenting with declarative state machines
in CSS. The end goal looking something like this:
https://gist.github.com/JonRimmer/5881843

I thought about just firing off a mail to this list saying, "Hey, wouldn't
it be cool if we could have state machines like this?" But then I thought
about the ideas of the extensible web, and I realised it would make more
sense to experiment first as a library, built on top of Web Animations, to
see if the syntax and concepts had merit. I considered how I could build
such a library, and what low level features I would need. The first one
that occurred is the ability to declare custom at-rules, so that is the
issue I raised. It doesn't get me the whole distance, I'd still need to
embed a parser to handle my custom syntax, but I'd be able to leverage all
the stylesheet loading, the media query resolution, and let users of the
library put their configuration right into their CSS.

Frankly, I think it's less a question of "why allow this?" and more "why
not?". The platform should default to providing hooks and extension points
into capabilities like properties and at-rules, unless there are
significant security or performance risks to doing so. Custom properties
were a good start, and I think this would be an excellent continuation.
Everyone agrees new declarative syntaxes are needed for things like
animations, so help people experiment with them by providing the low level
tools necessary.

[1] http://infrequently.org/2013/05/use-case-zero/
[2] https://github.com/adobe-webplatform/css-regions-polyfill
[3] https://github.com/doctyper/reflexie/tree/develop

Jon Rimmer



On 28 June 2013 16:45, Simon Sapin <simon.sapin@exyr.org> wrote:

> 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/css3-conditional/#the-css-interface>
> http://www.w3.org/TR/cssom-**view/#extensions-to-the-**window-interface<http://www.w3.org/TR/cssom-view/#extensions-to-the-window-interface>
> http://www.w3.org/TR/cssom-**view/#mediaquerylist<http://www.w3.org/TR/cssom-view/#mediaquerylist>
>
> Perhaps give an example of how you would use this?
>
> Cheers,
> --
> Simon Sapin
>