- From: Brian Kardell <bkardell@gmail.com>
- Date: Mon, 1 Jul 2013 15:02:07 -0400
- 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>
- Message-ID: <CADC=+jfV+DEMbubPa217ZiH_Zt3WB13tvz2b9dDQKXL5hfcivA@mail.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