[css-properties-values] CSSOM for multi-name `@property`

In https://github.com/w3c/csswg-drafts/issues/7523#issuecomment-3683970305 we resolved to adopt a comma-separated syntax for `<custom-property-name>` to support registering multiple properties that share the same descriptors in one go. However, we do not seem to have consensus on the best CSSOM to represent this. Opening this so we can discuss without clobbering the shorthand syntax discussed in #7523, though the design should also take it into account. ## Discussion ### Requirements - Existing single-name `@property` rules MUST produce the same CSSOM - Any syntax that only fans out on `name` only (e.g. `CSSPropertyRule.prototype.names`) will have trouble once the shorthand `syntax` syntax is introduced (#7523) - `CSSPropertyRule.prototype.name` is read-only so we don't need to answer the question "how does the setter behave?". That said, it would be _nice_ if the design did not actively get in the way of making it writable later. ### Nice to haves - Roundtripping. Plenty of places where CSS doesn't roundtrip, so not a biggie if it doesn't, but it's _nice_ if it does. - Authors should not need to parse property names and split by commas. This will get very awkward once #7523 is introduced, as they'll now need to parse a full blown microsyntax. ## Options ### Option 1: Expand to multiple `CSSPropertyRule` rules at parse time No `CSSPropertyRule` changes. The rule just expands to multiple `CSSPropertyRule` rules at parse time. Pros: - **No CSSOM changes** - Supports almost any future syntax - Authors don't need to parse any microsyntax - Backwards compatible with existing consumers Cons: - No roundtripping - Making `name` writable later would be hard ### Option 2: `name` includes the full comma-separated list, `names` as a `FrozenArray` Pros: - Serialization roundtrips - Special cases the name fanout, unclear how this expands to the `syntax` shorthand Cons: - Authors need to do their own parsing, which will get even more complex with the shorthand declaration we've been discussing in #7523 ### Option 3: Nested `CSSPropertyRule` `CSSPropertyRule` gains a `cssRules` property which is a `CSSPropertyRule[]`. Its properties represent base values as specified in the actual rule, but child rules can override them. Single-property usage is backwards compatible, consumers need to be updated to read multi-property rules correctly. Pros: - Most faithful representation, objects correspond exactly to what was written - Roundtrips correctly - Scales better to future syntax extensions like shorthand types, nesting etc - Even supports a future writable `name` — it would just generate `cssRules`. Cons: - Biggest lift, incompatible with code consuming the existing schema - Requires additional design decisions for every single descriptor on the root object - What would `name` be? Empty? A comma-separated list? The first name? - What would `syntax` be once we have the shorthand syntax? Empty? A union of all? The first one? - etc ------ I’m moderately strongly against 2, but I'm fine with 1 or 3. I originally recommended 1 as I think it would be unfortunate to gate this feature on a big CSSOM change, but 3 is the "proper" way, and can scale to cover a lot of future expansion.