css-parser-api
css-parser-api copied to clipboard
WICG
Give parser ability to handle shorthands
Shorthands are one of the CSS niceties that other languages using CSSish syntax should be able to use without a lot of difficulty. One of the options the parser should take is a list of property names that are shorthands, and a callback that will be given those declarations (one at a time) and allowed to return a list of expanded declarations that will actually show up in the generic OM.
Hmmmm... I'm trying to think about this a little bit. Thinking of the other hooks, maybe we should have a register method for the shorthands, rather than overloading the parse method with all of the possible shorthands. This will keep the APIs with paint, layout, etc consistent and still allow you to enumerate them when parsing to fire the callbacks and also allow you to not special case the parse code in the engine for Houdini event registration.
I'm talking about the "generic" parser here, not, like, "custom properties that want to be treated like shorthands for other custom properties". Something like that, yeah, we should add a hook you can register for that gets called sometime during the page's style-lifecycle.
But if you're using CSS syntax for some totally different language, and want to have shorthands exist in your language, the generic parser needs to know about them so it can handle things correctly.
Sure we can allow you to pass in an enum and move from there but whether it's custom properties or you're custom language you're going to need JS and I think it would be nice to have them match that of the other APIs. Additionally, any other Houdini API, such as custom properties, should use this registration to let the parser know how to parse it, they should be building on top of each other, not coming up with two different ways to achieve relatively the same thing. If they can't, then the API isn't low level enough.
They're different use-cases with different affordances. One is specifying how to parse a string into a data structure. Another is about hooking the parsing behavior of all stylesheets on a webpage.
Like, if you attach a grammar to specific properties in the generic parser, will we do that with a .registerProperty() on some object? Or just by some entries in the settings object that we pass to the parser alongside the string?
I feel like your second paragraph with the question is just a summation of the potential implementation approaches or am I missing what you're asking?
Yeah, sorry, that was unclear. I was indeed summarizing possible implementation approaches for a related topic, because I want this to be consistent with that.
And I think that we'd specify the grammars we want with entries in the settings argument, so I think shorthands shoudl work similarly (specifying a callback)
Basically, and this is why I wanted this to use TypedOM, I think our Houdini APIs building on one another makes us Dogfood our own APIs and shows us their weaknesses.
Yes, I'm also 100% intending this to be built on Typed OM (just, a side-branch that covers only the generic types).
And vice versa - the TypedOM .parse() method should be hooking into this at some level or just using this parser rather than having redundant API IMO. Should we have this discussion somewhere else - I don't want to drag these issue threads with 15K ft view Houdini architecture discussions.