Re: [cssom] Author-defined at-rules

On 29 June 2013 09:47, Simon Sapin <simon.sapin@exyr.org> wrote:

> Le 29/06/2013 01:52, Jon Rimmer a écrit :
>
>  Frankly, I think it's less a question of "why allow this?" and more "why
>> not?".
>>
>
> Every new feature has a cost in deciding what it is exactly, writing a
> spec, writing tests, implementing it (many times), maintaining it, etc.
>

Yes, which is why low level features like this are needed, so higher level
ones can be built without needing the W3C and browser vendors to go through
that process for every one.


>
> Again, I sympathize with everything you say about extensibility, but I am
> not really moved by this specific proposal. If this is just about storing
> stuff in CSS files remember that you can have whole at-rules in variables
> in you feel like it:
>
> #panel {
>   var-jtimeline: bounce {
>
>     0s {
>         top: 10px !timing(ease)
>     }
>
>     1s {
>         top: 10px !timing(ease)
>     }
>   }
> }
>
> I also expect that variables will make pollyfills easier, in that they
> don’t need a full CSS parser anymore.


Hacks like this and suggestions to just preprocess everything into
JavaScript strike me as the same old approach to extensibility in the web
platform: denying access to the mechanisms that browsers themselves use to
implement features. Browsers obviously have APIs to register at-rules and
parse and interpret their contents, but they don't expose them, so they
remain magic that authors aren't privileged to access.

This feature would begin to explain the magic behind at-rules in a way that
provides extensibility that feels like a natural addition, not a hack or a
run-around. Yes, on its own it doesn't get you much you couldn't do by
other means, but it's a first step in making the mechanisms that power
regular CSS composable and reusable in a declarative way, not just an
imperative one. And with additional capabilities, such as optionally
tokenizing and parsing the at-rule contents, they would let libraries
concentrate purely on the feature they wanted to add, not a lot of
ancillary tasks.

Consider roughly what would be involved in coding a preprocessor that
handled a new animation syntax:

1. Load the CSS files from disk
2. Parse the whole lot, looking for instances of the new at-rules and media
and supports queries that affect them, remembering that there may be other
syntactic additions, such as SASS, LESS or other preprocessor-provided
features, which means it is not 100% valid CSS.
3. Translate the media and support queries into JavaScript.
4. Translate the at-rule contents into JavaScript
5. Write everything out into a valid JavaScript file.
6. Remove the new at-rules from the CSS files, taking care not to affect
anything else, like syntax, comments, whitespace, etc. that might be relied
upon by other preprocessors, and write them to disk.

The only step involved with actually providing the new feature is number 4.
Everything else: loading, parsing, media and feature queries, is already in
the platform, and it should be possible to reuse it in a natural way.

Jon Rimmer