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

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

From: Brian Kardell <bkardell@gmail.com>
Date: Mon, 1 Jul 2013 15:02:07 -0400
Message-ID: <CADC=+jfV+DEMbubPa217ZiH_Zt3WB13tvz2b9dDQKXL5hfcivA@mail.gmail.com>
To: Simon Sapin <simon.sapin@exyr.org>
Cc: www-style@w3.org, Jon Rimmer <jon.rimmer@gmail.com>, François REMY <francois.remy.dev@outlook.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
On Jul 1, 2013 2:39 PM, "Simon Sapin" <simon.sapin@exyr.org> 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
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
>

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:31 UTC