New issue
Advanced search Search tips

Issue 906885 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Fragmentation of monolithic elements

Project Member Reported by wangxianzhu@chromium.org, Nov 20

Issue description

A monolithic element (https://www.w3.org/TR/css-break-3/#monolithic) is not fragmentable and contains no possible break points, "for example, many types of replaced elements [CSS21] (such as images or video), scrollable elements, or a single line of text content."

For now we don't support monolithic feature for replaced elements and scrollable elements. We may layout an element that should be monolithic in a fragment having no enough space for it, and may slice it into two or more fragments, or clip it in the fragment where it starts.


 
I imagine this is something we'll do ~entirely on the layout side with LayoutNG, and that we won't be spending any time on it for the legacy engine.

The current layout engine doesn't allow content to overflow past the block-end of a column (or overflow before the block-start side of a column, except the first column). Then it will just be sliced.
It's great that this will be fixed by LayoutNG.

I'm keeping Blink>Paint on this bug because I imagine we need to adapt PaintPropertyTreeBuilder and PaintInvalidator currently based on LayoutObject::FragmentData to the new LayoutNG fragmentation data structures. I opened this bug because we need to deal with FragmentClip skipping for monolithic elements in PaintPropertyTreeBuilder for correct clip paint property node hierarchy (bug 803649). 
Issue 903287 is another one that would be fixed by preventing fragmentation
of monolithic elements.

Let's discuss possible solutions on issue 803649.

Sign in to add a comment