1867106 - CSSOM doesn't seem to have @page `size` descriptor wired up to be modified or inspected from script

Status: RESOLVED DUPLICATE of bug 1890842

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

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:

1. Load attached testcase.
2. Check your devtools console (ctrl shift k)

ACTUAL RESULTS:
The last logged line is undefined -- i.e. console.log(document.styleSheets[0].rules[3].style.size is undefined.

Despite that, the previous line does show that if I remove size, we stringify the whole style object as CSS2Properties { size → "3px" }

EXPECTED RESULTS:
We probably should be able to inspect the size descriptor via CSSOM, I think? Unless there's spec text to the contrary (since size has some specialness in terms of not being a real CSS property).

Chrome gives EXPECTED RESULTS fwiw, and it seems native google docs printing relies on that (not just inspecting this value, but also modifying it), in order to dynamically set the user's selected page size for a printed google doc.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 2: dynamically modifying margin-top and size in beforeprint handler

Here's something long the lines of what I think Google Docs depends on.

In this testcase, I'm dynamically modifying @page margin-top and size in the beforeprint handler. The margin-top modification does take effect, but the size one does not (I think because it's simply not wired up, per the undefined result noted in comment 0).

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (testing `page-orientation`)

Not too surprisingly, this affects page-orientation as well -- not just size. Here's a testcase to demonstrate that.

(I don't think Google Docs dynamically sets page-orientation via the CSSOM, but it'd be good to make the same fix there, regardless.)

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Blerg. It's not supposed to be exposed per spec. size is a descriptor and not a CSS property. Blink exposes it even in regular style declarations: "size" in document.body.style is true there.

But then again, style.setProperty does work here, so maybe we just expose these and call it a day?

As a workaround, we could ask google to use setProperty("size", ..) rather than .size, which should work?

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: modified version of testcase 2 (using setProperty)

That should probably work, yeah. Here's a modified version of testcase 2 that does that, which does work as-expected in Firefox Nightly.

Comment 5

[Emily McDonough [:alaskanemily]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

Blerg. It's not supposed to be exposed per spec. size is a descriptor and not a CSS property. Blink exposes it even in regular style declarations: "size" in document.body.style is true there.

But then again, style.setProperty does work here, so maybe we just expose these and call it a day?

As a workaround, we could ask google to use setProperty("size", ..) rather than .size, which should work?

Yeah, I'm thinking about/looking into what it would look like to have size exist only on the style as returned from page-rules. I don't want to put size on all CSS2Properties, and it would be slightly weird to have a different properties object just for page-rules, but that would be more compatible and would let you set size in cases where it makes sense.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

As a workaround, we could ask google to use setProperty("size", ..) rather than .size, which should work?

I asked our Google Docs contact if they could make this change, and they said that'd be fine.

So: that probably lowers the priority here, until/unless we're aware of other content that expects .size to work in this way.

Comment 8

[Jonathan Watt [:jwatt]]

Google is going to update Google Docs to use setProperty, so we don't need this for the Gsuite work.

Comment 9

[Jonathan Watt [:jwatt]]

Emily has filed an issue for the WG to discuss: https://github.com/w3c/csswg-drafts/issues/9685

Thanks, Emily!

Comment 10

[Emilio Cobos Álvarez (:emilio)]

It was pointed out that we had discussed this in https://github.com/w3c/csswg-drafts/issues/5649. I should draft the spec changes but if somebody wants to get ahead please be my guest :)

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Did a first pass at this in https://github.com/w3c/csswg-drafts/pull/9686

Comment 12

[Emily McDonough [:alaskanemily]]

Give we've got support for CSSPageDescriptors now, I think it's safe to close this.

Comment 13

[Daniel Holbert [:dholbert]]

Yup, confirmed this is is fixed, with 2024-07-03 being the first good Nightly. (Nightly 2024-07-02 is "bad".)

I think we can just consider this a dupe of bug 1890842.