[css-syntax] Concrete criteria for rule / declaration validity when being produced by a [compliant] parser?

[amn]

parse-css implements certain criteria for determining if a rule is valid: https://github.com/tabatkins/parse-css/blob/c7859c41887409c533beed36956b7976ea0144b4/parse-css.js#L1142-L1167

Since the former was ostensibly written to verify the "soundness" of the current [CSS Syntax] draft, and because I don't see any of the implemented criteria specified in the draft, am I to understand these are specified in other CSS compendiums? A different module, perhaps?

If so, could one say that all CSS rules and declarations are syntactically valid as parsed? I am trying to assess how viable/useful it would be for a more general CSS parser to consider so, at the cost of qualified rules in the parse tree with e.g. a semi-colon (;) in their prelude, among other peculiarities.

[tabatkins]

Yes, the rest of CSS beyond the Syntax spec has the actual grammar definitions of all the rules and declarations. What's in parse-css is a super generic notion of "validity" sufficient to differentiate between qualified rules and declarations when consuming a block's contents.

Of those checks in parse-css, the semicolon check isn't even strictly necessary for that purpose; it's just strictly guaranteed that such a construct will always be invalid in CSS because it's a rule that cannot, by definition, ever be nested, so we will never design a qualified rule that allows a top-level semicolon in its prelude (and no other language hosted on CSS syntax should, either).

The {}-block check for declarations is also slightly stronger than necessary - per Syntax, a non-custom property is allowed to have a {}-block as its entire value, and the parse-css check disallows that. I should probably fix that.

[tabatkins]

(Really, parse-css is slightly behind the spec at the moment.)

[amn]

Thank you for the informative reply, that clarifies it.

[MrHBS]

I am assuming this issue can be closed then?