Bugzilla

I suspect there's a special behavior for orthogonal writing-mode on the body vs. html element (for testcase 2) in printing -- it seems to be interoperable at least, since Firefox, Chrome, and Safari all produce only one page of output for testcase 2, vs. three pages of output for testcase 3.

The original site only produces 1 page of output in Firefox, WebKit, and Chrome, for that same reason that testcase 2 does (since the original site is essentially a more-complex version of testcase 2).  (Chrome and to-a-lesser-extent WebKit also have a substantial hang before they arrive at showing you that 1 page of output in their print-preview dialog.)

So: bottom line, I don't think there's a Firefox bug to fix or a clear interop issue to address here.  Essentially: the site in comment 0 isn't really printable in the way that it intuitively looks like it would be, and that's because of its nested orthogonal writing-modes with content flowing off the bottom (inline edge) of a vertical writing-mode element (the side where fragmentation does *not* happen, equivalent to extremely wide content running off the right or left side of the page in a traditional horizontal-writing-mode document).

If someone wanted to write a site like that and they want it to be printable with the content being split vertically across pages, they would need to write their HTML/CSS using a horizontal writing-mode (to get vertical page-splitting) from the root element down-to-and-inlcuding the element that's expecting to be vertically split (the tall flex container).  Inside of that, the content could specify `writing-mode:vertical-rl` for the actual text containers inside of each page; but a vertical writing mode spanning multiple pages is not really going to work, if the content is overflowing vertically.

(See also bug 1806717 for known issues with printing column-oriented wrappable flex containers, which may come into play in certain variants of this site too.  But that's not really related to the core/proximal issue that this site is running up against.

I suspect there's a special behavior for orthogonal writing-mode on the body vs. html element (for testcase 2) in printing -- it seems to be interoperable at least, since Firefox, Chrome, and Safari all produce only one page of output for testcase 2, vs. three pages of output for testcase 3.

The original site only produces 1 page of output in Firefox, WebKit, and Chrome, for that same reason that testcase 2 does (since the original site is essentially a more-complex version of testcase 2).  (Chrome and to-a-lesser-extent WebKit also have a substantial hang before they arrive at showing you that 1 page of output in their print-preview dialog.)

So: bottom line, I don't think there's a Firefox bug to fix or a clear interop issue to address here.  Essentially: the site in comment 0 isn't really printable in the way that it intuitively looks like it would be, and that's because of its nested orthogonal writing-modes with content flowing off the bottom (inline edge) of a vertical writing-mode element (the side where fragmentation does *not* happen, equivalent to extremely wide content running off the right or left side of the page in a traditional horizontal-writing-mode document).

If someone wanted to write a site like that and they want it to be printable with the content being split vertically across pages, they would need to write their HTML/CSS using a horizontal writing-mode (to get vertical page-splitting) from the root element down-to-and-inlcuding the element that's expecting to be vertically split (the tall flex container).  Inside of that, the content could specify `writing-mode:vertical-rl` for the actual text containers inside of each page; but a vertical writing mode spanning multiple pages is not really going to work, if the content is overflowing vertically.

(See also bug 1806717 for known issues with printing column-oriented wrappable flex containers, which may come into play in certain variants of this site too.  But that's not really related to the core/proximal issue that this site is running up against.)

I suspect there's a special behavior for orthogonal writing-mode on the body vs. html element (for testcase 2) in printing -- it seems to be interoperable at least, since Firefox, Chrome, and Safari all produce only one page of output for testcase 2, vs. three pages of output for testcase 3.

The original site (linked in comment 0) only produces 1 page of output in Firefox, WebKit, and Chrome, for that same reason that testcase 2 does (since the original site is essentially a more-complex version of testcase 2).  (Chrome and to-a-lesser-extent WebKit also have a substantial hang before they arrive at showing you that 1 page of output in their print-preview dialog.)

So: bottom line, I don't think there's a Firefox bug to fix or a clear interop issue to address here.  Essentially: the site in comment 0 isn't really printable in the way that it intuitively looks like it would be, and that's because of its nested orthogonal writing-modes with content flowing off the bottom (inline edge) of a vertical writing-mode element (the side where fragmentation does *not* happen, equivalent to extremely wide content running off the right or left side of the page in a traditional horizontal-writing-mode document).

If someone wanted to write a site like that and they want it to be printable with the content being split vertically across pages, they would need to write their HTML/CSS using a horizontal writing-mode (to get vertical page-splitting) from the root element down-to-and-inlcuding the element that's expecting to be vertically split (the tall flex container).  Inside of that, the content could specify `writing-mode:vertical-rl` for the actual text containers inside of each page; but a vertical writing mode spanning multiple pages is not really going to work, if the content is overflowing vertically.

(See also bug 1806717 for known issues with printing column-oriented wrappable flex containers, which may come into play in certain variants of this site too.  But that's not really related to the core/proximal issue that this site is running up against.)

I suspect there's a special behavior for orthogonal writing-mode on the body vs. html element (for testcase 2) in printing -- it seems to be interoperable at least, since Firefox, Chrome, and Safari all produce only one page of output for testcase 2, vs. three pages of output for testcase 3.

The original site (linked in comment 0) only produces 1 page of output in Firefox, WebKit, and Chrome, for that same reason that testcase 2 does (since the original site is essentially a more-complex version of testcase 2).  (Chrome and to-a-lesser-extent WebKit also have a substantial hang before they arrive at showing you that 1 page of output in their print-preview dialog.)

So: bottom line, I don't think there's a Firefox bug to fix or a clear interop issue to address here.  Essentially: the site in comment 0 isn't really printable in the way that it intuitively looks like it would be, and that's because of its nested orthogonal writing-modes with content flowing off the bottom (inline edge) of a vertical writing-mode element (the side where fragmentation does *not* happen, equivalent to extremely wide content running off the right or left side of the page in a traditional horizontal-writing-mode document).

If someone wanted to write a site like the one in comment 0, and they want it to be printable with the content being split vertically across pages, they would need to write their HTML/CSS using a horizontal writing-mode (to get vertical page-splitting) from the root element down-to-and-inlcuding the element that's expecting to be vertically split (the tall flex container).  Inside of that, the content could specify `writing-mode:vertical-rl` for the actual text containers inside of each page; but a vertical writing mode spanning multiple pages is not really going to work, if the content is overflowing vertically.

(See also bug 1806717 for known issues with printing column-oriented wrappable flex containers, which may come into play in certain variants of this site too.  But that's not really related to the core/proximal issue that this site is running up against.)