css-parser-api
css-parser-api copied to clipboard
Shape of "style block" internals
TypedOM exposes the internals of style blocks as .styleMap, because CSS can rely on (1) multiple declarations with the same property name being collapsed to one, and (2) relative order of different declarations in a block is guaranteed to not be significant. The generic parser can't generally rely on either of these; CSSish languages might attach significant to either of these properties.
My first suggestion is that we can still provide a .styleMap, but make it a Multimap - then CSSish languages can pretend there's only a single instance of each property, while languages further out can access all of them if needed. We can also define iteration order to match the written order, so langs that care about it can just iterate the map. Unfortunately, Multimaps expose the first entry of the value list from the "single value" view. This is the opposite of how CSS works, exposing the last as the winning value. (I think iteration works - I believe Multimaps are supposed to be able to control iteration order for each individual value, so multiple values for the same key don't necessarily have to be adjacent in iteration order. This would be required for faithful reflection of GET parameters in urls, for example. Lack of a real Multimap spec is annoying here.)
The only other suggestion I have is to expose the declarations as a simple array; if you want CSS's collapsing behavior, you'd have to specify that in the parser options, rather than getting it "for free" from the data structure.
I like the idea of having it via the parsing options and returning them as a simple array myself.
Yeah, I think that's best too.