As of bug 1681052, we have a "fallback" fragmentation codepath which "slices" certain classes of tall content that spans multiple pages (rather than just having it run off the page and be lost, as it used to be before we introduced that codepath, as described in e.g. bug 534182). Strictly speaking, our slicing behavior is spec-compliant at least for `display:inline-block` and other inline-level container elements that we have to slice. Quoting the css-break-3 spec: > Since line boxes contain no possible break points, inline-block and inline-table boxes (and other inline-level display types that establish an independent formatting context) may also be considered monolithic: that is, in the cases where a single line box is too large to fit within its fragmentainer even by itself and the UA chooses to split the line box, it may fragment such boxes or it may treat them as monolithic. https://www.w3.org/TR/css-break-3/ Also, a bit further along, the spec says (emphasis added): > [...] the UA may also fragment the contents of monolithic elements **by slicing the element’s graphical representation.** https://www.w3.org/TR/css-break-3/#unforced-breaks So: this slicing behavior is allowed by the CSS specs. **Nonetheless**: it's unfortunate if this ends up slicing some text that a user cares about, particularly if other browsers don't slice that text. So, I suspect we'll accumulate bug reports about cases where text is sliced with this codepath. In some cases we can get sites fixed to avoid triggering the fragmentation-fallback (e.g. by removing `inline-block` styling on wrappers), but certainly we won't always be able to do that. We may not be able to implement a real fix for this for a while, but we might be able to mitigate it somewhat, and we should at least track the fact that it's an issue. Hence, I'm filing this bug as a central place for that.
Bug 1759926 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
As of bug 1681052, we have a "fallback" fragmentation codepath which "slices" certain classes of tall content that span multiple pages (rather than just having this content run off the page and be lost, as it used to be before we introduced that codepath, as described in e.g. bug 534182). Strictly speaking, our slicing behavior is spec-compliant at least for `display:inline-block` and other inline-level container elements that we have to slice. Quoting the css-break-3 spec: > Since line boxes contain no possible break points, inline-block and inline-table boxes (and other inline-level display types that establish an independent formatting context) may also be considered monolithic: that is, in the cases where a single line box is too large to fit within its fragmentainer even by itself and the UA chooses to split the line box, it may fragment such boxes or it may treat them as monolithic. https://www.w3.org/TR/css-break-3/ Also, a bit further along, the spec says (emphasis added): > [...] the UA may also fragment the contents of monolithic elements **by slicing the element’s graphical representation.** https://www.w3.org/TR/css-break-3/#unforced-breaks So: this slicing behavior is allowed by the CSS specs. **Nonetheless**: it's unfortunate if this ends up slicing some text that a user cares about, particularly if other browsers don't slice that text. So, I suspect we'll accumulate bug reports about cases where text is sliced with this codepath. In some cases we can get sites fixed to avoid triggering the fragmentation-fallback (e.g. by removing `inline-block` styling on wrappers), but certainly we won't always be able to do that. We may not be able to implement a real fix for this for a while, but we might be able to mitigate it somewhat, and we should at least track the fact that it's an issue. Hence, I'm filing this bug as a central place for that.