An extended page-rule style object was recently added to the cssom spec: https://drafts.csswg.org/cssom/#csspagedescriptors
This would resolve the weirdness as described in bug 1867106. We have all the information to build these objects from our current style information, we just need to create the actual IDL and binding code.
I expect that at some point a CSSMarginDescriptors object will also be defined and will require similar work.

emilio: (ni'ing as discussed on Matrix) after applying this patch and inspecting a @page rule in devtools, it seems like its .style is still a CSS2Properties. I'm not sure why this is happening.

Ah, you just need to override CSSPageRuleDeclaration::WrapObject, because it otherwise ends up here.

This seems to work. We probably want to rename CSS2Properties.webidl or
something but...

https://hg.mozilla.org/mozilla-central/rev/782c9e2be6b8

FF129 MDN docs for this can be tracked in https://github.com/mdn/content/issues/34702

As I understand it, this change updates FF to match the specification. In particular:

• CSSPageRule.style is now a CSSPageDescriptors rather than a CSSStyleDeclaration.

1. Is that correct?

• According to the spec, CSSPageDescriptors explicitly creates properties for a number of @page settings in both snake and camel case, whereas CSSStyleDeclaration had setter-getter methods to get properties.

2. What's the difference? I mean why are some properties now exposed this way (but not all?) and why is that better than previously? My assumption is that it is more obvious what is going on with the properties declared explicitly, but I was wondering if there is a formal reason?

3. If I change a value for the page in CSSPageRule.style does this change the live styling (I would expect it to).

4. The spec defines two properties marks and bleed in CSSPageDescriptors that when read are undefined. Is there an intent to implement these to (FMI)

5. So basically this interface allows you to get the properties set in an @page rule in your web API right?

6. Lastly, FF did does not appear to implement CSSStyleDeclaration.getPropertyCSSValue() - so my guess is that the reason this change needed to be made was so that you can get the property values. Now we can, and that is the main point to make in the release note?

Note, I have completed the work assuming the above is true/correct. Updates can still happen if I'm wrong.

Replying for Emily since she's traveling iirc.

(In reply to Hamish Willee from comment #9)

1. Is that correct?

Yes

2. What's the difference? I mean why are some properties now exposed this way (but not all?) and why is that better than previously? My assumption is that it is more obvious what is going on with the properties declared explicitly, but I was wondering if there is a formal reason?

CSSPageDescriptors only exposes the @page related properties, CSS2Properties exposed all CSS properties.

• Properties that don't apply to @page like padding-top would no longer show up.
• Things that were exclusive to @page now show up (like page-orientation).

3. If I change a value for the page in CSSPageRule.style does this change the live styling (I would expect it to).

Well, not really, because @page only applies when printing and you can't run script while printing. But it'll affect the page when you print it.

4. The spec defines two properties marks and bleed in CSSPageDescriptors that when read are undefined. Is there an intent to implement these to (FMI)

Those are not yet implemented.

5. So basically this interface allows you to get the properties set in an @page rule in your web API right?

Basically.

5. Lastly, FF did does not appear to implement CSSStyleDeclaration.getPropertyCSSValue() - so my guess is that the reason this change needed to be made was so that you can get the property values. Now we can, and that is the main point to make in the release note?

Hm? We implement getPropertyValue which returns a string. getPropertyCSSValue is not standard, and in fact we removed it in bug 1408301.

Thank you. That's enough to confirm that I have documented this correctly - though I did improve the release note a little. [I don't know where my thinking about getPropertyCSSValue came from - no other evidence of it in my notes]