Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 8345bb765b035fd3de5d91f13c637367cf142e92
https://github.com/WebKit/WebKit/commit/8345bb765b035fd3de5d91f13c637367cf142e92
Author: Sammy Gill <[email protected]>
Date: 2026-08-21 (Fri, 21 Aug 2026)
Changed paths:
R
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/computed-margin-values/block-container-block-end-expected.txt
R
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/computed-margin-values/block-container-block-end-nested-child-expected.txt
R
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/computed-margin-values/block-container-block-end-nested-child.html
R
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/computed-margin-values/block-container-block-end-with-self-collapsing-children-expected.txt
R
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/computed-margin-values/block-container-block-end-with-self-collapsing-children.html
R
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/computed-margin-values/block-container-block-end.html
R
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/computed-margin-values/block-container-block-start-child-with-border-expected.txt
R
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/computed-margin-values/block-container-block-start-child-with-border.html
R
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/computed-margin-values/block-container-block-start-expected.txt
R
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/computed-margin-values/block-container-block-start-self-collapsing-nested-expected.txt
R
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/computed-margin-values/block-container-block-start-self-collapsing-nested.html
R
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/computed-margin-values/block-container-block-start.html
A
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/margin-trim-computed-value-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/margin-trim-computed-value.html
M Source/WebCore/rendering/RenderBlock.cpp
M Source/WebCore/rendering/RenderBlock.h
M Source/WebCore/rendering/RenderBlockFlow.cpp
M Source/WebCore/rendering/RenderBlockFlow.h
M Source/WebCore/rendering/RenderBox.cpp
Log Message:
-----------
[margin-trim] Trimmed margins should not be reflected in computed style
https://bugs.webkit.org/show_bug.cgi?id=321104
rdar://184215336
Reviewed by Alan Baradlay.
The CSSWG resolved that margin-trim does not affect the resolved value of the
margin
properties, so a trimmed margin must still be reported by getComputedStyle.
https://github.com/w3c/csswg-drafts/issues/11506
We wrote 0 into the child's margin box when trimming it, and Style::Extractor
reads the
used margin off the renderer, so trimming leaked into the computed value.
Margin collapsing also has similar behavior with regards to this so we
can resolve this problem by making the underlying trimming logic similar
to the collapsing logic. The code stores various information with
regards to margin collapsing in a helper struct and uses that
information to compute the position of the box but the actual value of
the renderer's margin box field remains the same.
Discarding the margins as they are consumed also fixes a pre-existing bug. The
old code only
zeroed the child's margin box, but the collapsed-through margin that reaches
the container's
height comes from the child's rare data, so a trimming container that cannot
collapse with its
children (one with a block-end border, say) still grew by a margin that
margin-trim had
discarded, even though the child itself was repositioned flush to the trimmed
edge. That
margin is now discarded before MarginInfo sees it.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/margin-trim-computed-value-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/margin-trim-computed-value.html:
Added.
Replaced the existing tests with a new one that contains some subtests
to make sure the new behavior holds.
* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::adjustBlockEndChildrenForMarginTrim):
trimBlockEndChildrenMargins becomes adjustBlockEndChildrenForMarginTrim: its
margin
box writes ran after every child had been laid out and after MarginInfo had
already consumed
their margins, and for block flow descendants the parent reads the collapsed
margins out of
rare data rather than the margin box, so they no longer had any bearing on the
container's
block size by the time they ran. The self-collapsing repositioning it performs
is still needed
to pull such a child back to the trimmed block-end edge when a preceding
sibling's margin has
collapsed through it.
That preceding sibling's margin is itself adjoining the trimmed edge and should
be trimmed as
well, but MarginInfo has already accumulated it, so a container that cannot
collapse with its
children still grows by it. This is not a regression: with the same content the
old code grew
by the larger of that margin and the trimmed child's own margin, so the value
can only get
smaller here (41px before, 32px now, 27px once the FIXME added to
adjustBlockEndChildrenForMarginTrim is addressed). The block-start edge already
handles the
equivalent case through LayoutState::marginTrimBlockStart.
(WebCore::RenderBlockFlow::marginValuesForChild):
Discard the trimmed sides as it hands the child's margins to the collapsing
code. Every
block axis consumer of a child's margins goes through it, so the child's
logical top is
computed with the margin discarded without anything mutating the child. Which
side is trimmed
is answered by shouldTrimChildMargin for a first or last in-flow child, plus
the existing
LayoutState::marginTrimBlockStart flag for a margin that collapses through to a
trimming
ancestor's block-start edge.
(WebCore::RenderBlockFlow::marginBeforeEstimateForChild):
Bail out when the child's block-start margin is trimmed, including when it
collapses through to
a trimming ancestor's edge, so that the estimate agrees with what
marginValuesForChild computes
once the margins are actually consumed. The estimate previously used the
untrimmed margin in the
collapsed-through case and then walked into the grandchildren to collapse
margins that are
trimmed along with it.
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::computeBlockDirectionMargins):
Do not return 0 for a trimmed margin but let the caller determine if
trimming is happening and perform the appropriate logic in that
situation.
Canonical link: https://commits.webkit.org/319612@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications