Closed Bug 1890842 Opened 7 months ago Closed 4 months ago

Implement CSSPageDescriptors

Categories

(Core :: DOM: CSS Object Model, enhancement)

enhancement

Tracking

()

RESOLVED FIXED
129 Branch
Tracking Status
firefox129 --- fixed

People

(Reporter: alaskanemily, Assigned: alaskanemily)

References

Details

(Keywords: dev-doc-complete)

Attachments

(2 files)

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.

Keywords: dev-doc-needed

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.

Flags: needinfo?(emilio)

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

Flags: needinfo?(emilio)

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

Attachment #9399485 - Attachment description: Bug 1890842 - Add the CSSPageDescriptors webidl and change CSSPageRule to use it for Style() → Bug 1890842 - Generate CSSPageDescriptors.webidl and change CSSPageRule to use CSSPageDescriptors for Style().
Pushed by emcdonough@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/782c9e2be6b8 Generate CSSPageDescriptors.webidl and change CSSPageRule to use CSSPageDescriptors for Style(). r=webidl,emilio
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/46972 for changes under testing/web-platform/tests
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 129 Branch
Upstream PR merged by moz-wptsync-bot
Regressions: 1908359

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:

  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.
  1. 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?

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

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

  4. 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?

Flags: needinfo?(emcdonough)

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

  1. 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).
  1. 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.

  1. 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.

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

Basically.

  1. 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.

Flags: needinfo?(emcdonough)

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]

Duplicate of this bug: 1867106
See Also: 1867106
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: