- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 1 Jul 2013 13:04:59 -0700
- To: Brian Kardell <bkardell@gmail.com>
- Cc: Simon Sapin <simon.sapin@exyr.org>, "www-style@w3.org" <www-style@w3.org>, Jon Rimmer <jon.rimmer@gmail.com>, François REMY <francois.remy.dev@outlook.com>
On Mon, Jul 1, 2013 at 12:13 PM, Brian Kardell <bkardell@gmail.com> wrote: > 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 > > 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'm against exposing the tokens directly, as least for now. I want to maintain the ability to change tokenization, particularly around delims. Once we expose tokenization, the tokenizer basically freezes forever. > 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. My tokenizer's serialization stuff is meant for ease of debugging, not usability. ^_^ There's a pull request against it right now to expose a more direct serialization that I'll accept after this refactor that I'm in the middle of (to make it match latest changes). ~TJ
Received on Monday, 1 July 2013 20:05:46 UTC