Bug 1666797 Comment 9 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

So there are a few issues that I see here, which makes this testcase difficult to fragment:

 (1) The writing-mode on the `body` and the `html` elements disagree. We're trying to fragment the testcase in the block axis (so, we're fragmenting vertically, because we're following the writing-mode of the html element).  But the vertical axis is the inline axis of the body element, and we don't support fragmenting in the inline axis (other than just regular line-wrapping).  So we don't fragment the content successfully.

 (2) If you address that^ by e.g. adding `html { writing-mode: vertical-rl }`, this still doesn't really help, because the content is styled with a limited `width` and an unbounded `height, and with `flex-direction: column` and `flex-wrap: wrap`. So the block axis is horizontal (right to left), BUT content doesn't actually stack very far in that direction -- when we hit the specified width, we wrap to another horizontal "flex column". This ends up meaning that adding more content increases the height (growing in the content's inline axis).


SO: if you set a writing-mode on the `html` element to address (1) above, this ends up being the vertical-writing-mode equivalent of a page like this one:
`data:text/html,<div style="height:5in; width:30in; border: 5px dotted black">`
...where we've just got a bunch of content that overflows in the inline axis, which we can only fit if the user picks "Fit to page width" as their scale option in our print settings.


If you **don't** set the writing-mode on the `html` element, then the content will overflow in the *document's* block direction, in which case Mats is correct that bug 1640197 should help.
So there are a few issues that I see here, which makes this testcase difficult to fragment:

 (1) The writing-mode on the `body` and the `html` elements disagree. We're trying to fragment the testcase in the block axis (so, we're fragmenting vertically, because we're following the writing-mode of the `html` element).  But the vertical axis is actually the **inline axis** of the body element and its content, and we don't support fragmenting in the inline axis (other than just regular line-wrapping).  So we don't fragment the content successfully.

 (2) If you address that^ by e.g. adding `html { writing-mode: vertical-rl }`, this still doesn't really help, because the content still overflows vertically, because it's styled with a limited `width` and an unbounded `height`, and with `flex-direction: column` and `flex-wrap: wrap`. So the block axis is horizontal (right to left), BUT content doesn't actually stack very far in that direction -- when we hit the specified width, we wrap to another horizontal "flex column". This ends up meaning that adding more content increases the height (growing in the content's inline axis).


SO: if you set a writing-mode on the `html` element to address (1) above, this ends up being the vertical-writing-mode equivalent of a page like this one:
`data:text/html,<div style="height:5in; width:30in; border: 5px dotted black">`
...where we've just got a bunch of content that overflows in the inline axis, which we can only fit if the user picks "Fit to page width" as their scale option in our print settings.


If you **don't** set the writing-mode on the `html` element, then the content will overflow in the *document's* block direction, in which case Mats is correct that bug 1640197 should help.
So there are a few issues that I see here, which makes this testcase difficult to fragment:

 (1) The writing-mode on the `body` and the `html` elements disagree. We're trying to fragment the testcase in the block axis (so, we're fragmenting vertically, because we're following the writing-mode of the `html` element).  But the vertical axis is actually the **inline axis** of the body element and its content, and we don't support fragmenting in the inline axis (other than just regular line-wrapping).  So we don't fragment the content successfully.

 (2) If you address that^ by e.g. adding `html { writing-mode: vertical-rl }`, this still doesn't really help, because the content still overflows vertically, because it's styled with a limited `width` and an unbounded `height`, and with `flex-direction: column` and `flex-wrap: wrap`. So the block axis is horizontal (right to left), BUT content doesn't actually stack very far in that direction -- when we hit the specified width, we wrap to another horizontal "flex column". This ends up meaning that adding more content increases the height (growing in the content's inline axis).


SO: if you set a writing-mode on the `html` element to address my point (1) above, this testcase ends up being effectively a vertical-writing-mode equivalent of a page like this one:
`data:text/html,<div style="height:5in; width:30in; border: 5px dotted black">`
...where we've just got a bunch of content that overflows in the inline axis, which we can only fit if the user picks "Fit to page width" as their scale option in our print settings.


If you **don't** set the writing-mode on the `html` element, then the content will overflow in the *document's* block direction, in which case Mats is correct that bug 1640197 should help.
So there are a few issues that I see here, which makes this testcase difficult to fragment:

 (1) The writing-mode on the `body` and the `html` elements disagree. We're trying to fragment the testcase in the block axis (so, we're fragmenting vertically, because we're following the writing-mode of the `html` element).  But the vertical axis is actually the **inline axis** of the body element and its content, and we don't support fragmenting in the inline axis (other than just regular line-wrapping).  So we don't fragment the content successfully.

 (2) If you address that^ by e.g. adding `html { writing-mode: vertical-rl }`, this still doesn't really help, because the content still overflows vertically, because it's styled with a limited `width` and an unbounded `height`, and with `flex-direction: column` and `flex-wrap: wrap`. So the block axis is horizontal (right to left), BUT content doesn't actually stack very far in that direction -- when we hit the specified width, we wrap to another horizontal "flex column". This ends up meaning that adding more content increases the height (growing in the content's inline axis).


SO: if you set a writing-mode on the `html` element to address my point (1) above, this testcase ends up being effectively a vertical-writing-mode equivalent of a page like this one:
`data:text/html,<div style="height:5in; width:30in; border: 5px dotted black">`
...where we've just got a bunch of content that overflows in the inline axis, which we can only fit if the user picks "Fit to page width" as their scale option in our print settings.  (And as far as I can tell, that "fit to page width" [really, inline-size] feature **does** indeed work here, if you do specify the `writing-mode` on the html element.)

If you **don't** set the writing-mode on the `html` element, then the content will overflow in the *document's* block direction, in which case Mats is correct that bug 1640197 should help.

Back to Bug 1666797 Comment 9