Implement CSSPageDescriptors
Categories
(Core :: DOM: CSS Object Model, enhancement)
Tracking
()
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.
Assignee | ||
Comment 1•6 months ago
|
||
Assignee | ||
Comment 2•6 months ago
|
||
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.
Comment 3•6 months ago
|
||
Ah, you just need to override CSSPageRuleDeclaration::WrapObject
, because it otherwise ends up here.
Comment 4•6 months ago
|
||
This seems to work. We probably want to rename CSS2Properties.webidl or
something but...
Updated•5 months ago
|
Comment 7•4 months ago
|
||
bugherder |
Comment 9•4 months ago
•
|
||
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 aCSSPageDescriptors
rather than aCSSStyleDeclaration
.
- Is that correct?
- According to the spec,
CSSPageDescriptors
explicitly creates properties for a number of@page
settings in both snake and camel case, whereasCSSStyleDeclaration
had setter-getter methods to get properties.
-
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?
-
If I change a value for the page in
CSSPageRule.style
does this change the live styling (I would expect it to). -
The spec defines two properties
marks
andbleed
inCSSPageDescriptors
that when read areundefined
. Is there an intent to implement these to (FMI) -
So basically this interface allows you to get the properties set in an @page rule in your web API right?
-
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?
Comment 10•4 months ago
|
||
Note, I have completed the work assuming the above is true/correct. Updates can still happen if I'm wrong.
Comment 11•4 months ago
|
||
Replying for Emily since she's traveling iirc.
(In reply to Hamish Willee from comment #9)
- Is that correct?
Yes
- 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
likepadding-top
would no longer show up. - Things that were exclusive to
@page
now show up (likepage-orientation
).
- 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.
- The spec defines two properties
marks
andbleed
inCSSPageDescriptors
that when read areundefined
. Is there an intent to implement these to (FMI)
Those are not yet implemented.
- So basically this interface allows you to get the properties set in an @page rule in your web API right?
Basically.
- 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.
Comment 12•4 months ago
•
|
||
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]
Description
•