- From: Brian Kardell <bkardell@gmail.com>
- Date: Mon, 1 Jul 2013 15:13:38 -0400
- To: Simon Sapin <simon.sapin@exyr.org>
- Cc: "www-style@w3.org" <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 Mon, Jul 1, 2013 at 3:06 PM, Simon Sapin <simon.sapin@exyr.org> wrote: > Le 01/07/2013 20:02, Brian Kardell a écrit : >> >> 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... > > > Do you mean the Core Grammar defined in 2.1? > http://www.w3.org/TR/CSS21/syndata.html#tokenization > > Syntax 3’s "component values" are a cleaned-up definition of the same thing. > http://dev.w3.org/csswg/css-syntax/#component-value > > -- > Simon Sapin Yes, I am saying the major skeleton of it as applies to parsing is pretty well guarded and hardly changes... Hardly - but it does. I think Tab's js parser does a serialization of component values - it is actually a little unweildy, I think we can do slightly better than that in terms of friendliness - but yeah, that's the gist... If you could call something that would give you a kind of AST regardless of whether the browser understood their actual details beyond parsing - then 99% of ways you would rationally extend CSS could be accounted for... What's more - most of it could be preprocessed if you wanted to and you could use the JSON forms to do your actual extension which is a lot more efficient anyway. The remaining 1% of things you could change would also changing the parser rules - and those are few and far between and potentially dangerous, so maybe that's ok. -- Brian Kardell :: @briankardell :: hitchjs.com
Received on Monday, 1 July 2013 19:14:07 UTC