Bugzilla

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](https://drafts.csswg.org/cssom/#csspagedescriptors). In particular:
- [`CSSPageRule.style`](https://developer.mozilla.org/en-US/docs/Web/API/CSSPageRule/style) is now a `CSSPageDescriptors` rather than a `CSSStyleDeclaration`, and derives from `CSSStyleDeclaration`
- The main difference appears to be that `CSSPageDescriptors` explicitly creates properties for each `@page` style in both snake and camel case, whereas `CSSStyleDeclaration` had a property for getting/setting them. 

1. That about right?

My understanding is that:
- Both camel case and snake case versions or the style attributes are created to match the CSS snake case, and more common web API styles for naming.
- These the values in the two cases should match each other
- The old way of doing things in `CSSStyleDeclaration` was not very clear for implementers/users - was there any other reason for the new approach?

2. That about right?
3. Given that CSSPageDescriptors inherits from  `CSSStyleDeclaration` does the old setter/getter approach mean anything for (affect) the new interface?

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

5. So 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?

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](https://drafts.csswg.org/cssom/#csspagedescriptors). In particular:
- [`CSSPageRule.style`](https://developer.mozilla.org/en-US/docs/Web/API/CSSPageRule/style) is now a `CSSPageDescriptors` rather than a `CSSStyleDeclaration`, and derives from `CSSStyleDeclaration`
- The main difference appears to be that `CSSPageDescriptors` explicitly creates properties for each `@page` style in both snake and camel case, whereas `CSSStyleDeclaration` had methods for getting/setting them. 
  - In both cases they essentially reflect the `@page`?
  - You can change the values using these properties right (in web API)?

1. That about right?

My understanding is that:
- Both camel case and snake case versions or the style attributes are created to match the CSS snake case, and more common web API styles for naming.
- These the values in the two cases should match each other
- The old way of doing things in `CSSStyleDeclaration` was not very clear for implementers/users - was there any other reason for the new approach?

2. That about right?
3. Given that CSSPageDescriptors inherits from  `CSSStyleDeclaration` does the old setter/getter approach mean anything for (affect) the new interface?

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

5. So 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?

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](https://drafts.csswg.org/cssom/#csspagedescriptors). In particular:
- [`CSSPageRule.style`](https://developer.mozilla.org/en-US/docs/Web/API/CSSPageRule/style) is now a `CSSPageDescriptors` rather than a `CSSStyleDeclaration`, and derives from `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` (see example code https://pr34960.content.dev.mdn.mozit.cloud/en-US/docs/Web/API/CSSPageRule/style#examples). Are these supposed to be implemented? Is there an intent to?

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

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?

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](https://drafts.csswg.org/cssom/#csspagedescriptors). In particular:
- [`CSSPageRule.style`](https://developer.mozilla.org/en-US/docs/Web/API/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` (see example code https://pr34960.content.dev.mdn.mozit.cloud/en-US/docs/Web/API/CSSPageRule/style#examples). Are these supposed to be implemented? Is there an intent to?

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

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?

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](https://drafts.csswg.org/cssom/#csspagedescriptors). In particular:
- [`CSSPageRule.style`](https://developer.mozilla.org/en-US/docs/Web/API/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? 

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?