wiki:CSSContainment

Version 1 (modified by rwlbuis@webkit.org, 3 years ago) (diff)

--

Containment

Here we describe changes needed for supporting various parts of CSS Containment [1].

Size Containment

Size containment calculate size as if there's no content. To implement size containment, we plan to add shouldApplySizeContainment to RenderObject to indicate if this object should be effective to contain: size;, according to [2].

Then cooperating with the layout steps.

  1. Calculating the widths. Some object's width depends on the intrinsic size which effects the minPreferredLogicalWidth and maxPreferredLogicalWidth.

In this case, for size containment, we need to make the intrinsic size not effected by content. It is handled in computeIntrinsicLogicalWidths() which will calculate minLogicalWidth and maxLogicalWidth as if the content is empty.

These objects include RenderReplace, RenderMenuList, RenderListBox, RenderTextControl, RenderFileUploadControl, RenderGrid, RenderFlexibleBox, RenderBlockFlow and so on.

  1. Layout children.
  2. Calculating height. The logical height is changed while layout children. So at the beginning of calculate logical height, the logicalHeight is reset to the empty content height.

For other layout algorithms, like grid, multicolumn and flex layout, we need to calculate the empty content size according to the algorithms.

Layout Containment

Layout containment limits the scope of layout, it makes the contained element opaque for layout purposes; nothing outside can affect its internal layout, and vice versa.

The central method to check whether layout containment should apply to the element will be called 'shouldApplyLayoutContainment'. It will check the conditions from the spec [3], i.e. it generates a principal box, is not an internal table box (other than table-cell), not an internal ruby box and not a non-atomic inline-levelbox.

Following the layout containment box algorithm [4]:

  • The layout containment box establishes an independent formatting context. To implement this, RenderBox::createsNewFormattingContext will have to be adapted.
  • If the computed value of the overflow property is either visible or clip or a combination thereof, any overflow must be treated as ink overflow. Adjust LayoutBox::LayoutOverflowRectForPropagation to not add visual overflow if shouldApplyLayoutContainment is true, since in that case it will be treated as ink overflow.
  • The layout containment box establishes an absolute positioning containing block and a fixed positioning containing block. This needs changes in RenderElement::canContainFixedPositionObjects and RenderElement::canContainAbsolutelyPositionedObjects.
  • The layout containment box creates a stacking context. This requires an additional check in RenderLayer::shouldBeCSSStackingContext.
  • For the purpose of the vertical-align property, or any other property whose effects need to relate the position of the layout containment box's baseline to something other than its descendants, the containment box is treated as having no baseline. The cooperating methods baselinePosition, firstLineBaseline and inlineBlockBaseline will need to be adapted for various kind of renderers to support this.

Layout contained elements act as relayout boundaries, so objectIsRelayoutBoundary should be changed in order for RenderObject::markContainingBlocksForLayout to avoid marking the contained element ancestors.

[1] https://www.w3.org/TR/css-contain-1/
[2] https://www.w3.org/TR/css-contain-1/#containment-size
[3] https://www.w3.org/TR/css-contain-1/#containment-layout
[4] https://www.w3.org/TR/css-contain-1/#layout-containment-box