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

On Jul 1, 2013 2:39 PM, "Simon Sapin" <> wrote:
> 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
>> 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
>> data JSON formatted and easy to load via your prollyfill thereafter.
>> things the browser cannot possibly understand in the CSS is probably not
>> very good idea.
>> This is just my personal point of view, but I believe we should restrict
>> 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
>> 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
> Although I just gave two arguments against, I still think it would be a
good thing to do :)
> Cheers,
> --
> Simon Sapin

We might considet exposing a non-lossy simple OM (not CSSOM, something that
could be parsed with JSON.parse) - I think that would be almost as good.
CSS's forward compat grammar is really good and anything that would change
it maybe should be very managed.  I proposed this in 2011 i think...

Received on Monday, 1 July 2013 19:02:36 UTC