Exposing CSS tokens to the platform (was: [cssom] Author-defined at-rules)

Le 01/07/2013 18:35, François REMY a écrit :
>> [Tab Atkins giving a more formal proposal]
>
> My concern is that this does not solve the problem at all, because what do
> you do if you want to nest some newly-generated at-rules? Do you have to
> parse again their content, recursively? If you goal is to end up parsing
> things in JavaScript at the end, you're better do it once, and have all your
> data JSON formatted and easy to load via your prollyfill thereafter. Putting
> things the browser cannot possibly understand in the CSS is probably not a
> very good idea.
>
> This is just my personal point of view, but I believe we should restrict CSS
> post-processing to things that just cannot be done in the pre-processing
> world. Creating SVG via CSS is really on the edge because you can generate
> your data url using a preprocessor, but that's not super-cool either.

I agree that just getting strings is underwhelming. I would be in favor 
of exposing tokens or "component values" as defined in css-syntax. This 
would make further parsing much easier.

The thing is, currently implementations can do things a bit differently 
than described in css-syntax and still get away with it (ie. still be 
conformant.) Exposing tokens to the platform could force on them choices 
that were previously implementation details.

Also, exposing tokens will make much harder to change the tokenizer, as 
we did recently to add a <column> token. (See Selectors 4 column 
combinator.)

Although I just gave two arguments against, I still think it would be a 
good thing to do :)

Cheers,
-- 
Simon Sapin

Received on Monday, 1 July 2013 18:38:41 UTC