Clip replaced elements to their content rect

[SimonSapin]

layout_2020::replaced::ReplacedContent::make_fragment is called in three places for inline-level, block-level, and absolutely-positioned replaced boxes. It returns an arbitrary Vec of fragments for the replaced content which is wrapped into a BoxFragment for the box itself. The latter is responsible the box’s borders, backgrounds, etc. Hopefully, this nesting in the fragment tree will also make it easier to implement object-fit and object-position.

Layout 2020 does not yet implement this bit of spec: https://drafts.csswg.org/css-backgrounds/#corner-clipping

The content of replaced elements is always trimmed to the content edge curve.

(The content edge curve is the content rect, with corners possibly rounded by border-radius.) Note that this is different from the clipping/trimming by the overflow property, which uses the padding rect/edge.

In the current fragment tree however there is no way to tell whether a BoxFragment was generated for a replaced element. We may want to add a boolean field or equivalent, so that display list construction can know which fragments to clip at their content edge.

@mrobinson, I see that clipping for the overflow property is handled by StackingContext rather than BoxFragment. Should we make replaced elements generate a (pseudo?) stacking context?

[mrobinson]

I think what we want to do here is just establish a rounded rectangle clip when building the display list for the BoxFragment and apply it to all children. WebRender supports creating arbitrary chains of clips (things don't have to be defined hierarchically), so perhaps we could simply append a series of clips for the hierarchy of the rounded rectangles onto the clip provided by the stacking context.

[SimonSapin]

Background painting is another case where we have WebRender clips for rounded corners, but those clips apply only to specific display items. My question was around how to make sure that everything in a sub-tree uses that clip.

By the way, per spec replaced elements are clipped even if the corner radius happens to be zero. This is not observable for raster images, but it might be eventually for SVG depending on how we end up integrating Pathfinder to WebRender.

[mrobinson]

For the subtree case, I think we can keep a stack of item-derived clips in the display list builder and use it to create ClipChains either during display list construction or stacking context tree construction.

[SimonSapin]

We presumably already do something similar for nested elements with the overflow property.

That said dealing with the general case may not worth worrying about yet since we have no plan to implement SVG soon, and so far the Vec returned by ReplacedContent::make_fragments is always either empty or has exactly one fragment which is a (raster) image fragment (and therefore does not have child fragments of its own).