Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 83bba6965f882753ecfbea7c0e45ad3b6ea3dd50
https://github.com/WebKit/WebKit/commit/83bba6965f882753ecfbea7c0e45ad3b6ea3dd50
Author: Sammy Gill <[email protected]>
Date: 2025-03-31 (Mon, 31 Mar 2025)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-extrinsically-sized-mutations-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-extrinsically-sized-mutations.html
M Source/WebCore/rendering/RenderGrid.cpp
M Source/WebCore/rendering/RenderGrid.h
M Source/WebCore/rendering/RenderObject.cpp
M Source/WebCore/rendering/updating/RenderTreeBuilder.cpp
Log Message:
-----------
[Grid] Allow extrinsically sized grid to perform simplified layout when grid
items are mutated.
https://bugs.webkit.org/show_bug.cgi?id=290573
rdar://148055966
Reviewed by Alan Baradlay.
When a grid item experiences some types of mutations, such as content
mutations or non-grid specific style changes, it may be possible to
contain the damage within the formatting context established by the item
and not need to propagate this damage into the formatting context of the
grid itself or any ancestors. One such example of content where this is
a case is when a grid item experiences a content mutation but is inside
a grid that is extrinsically sized by perhaps having all fixed or
percentage-based rows and columns. In this case, the damage is local to
the grid item and will have no impact on the GFC and will not change any
of the constraints on the grid item.
This patch attempts to identify these types of damage and respond by
running simplified layout from the RenderView, or any other layout root,
through the grid. We can do this as we are invalidating the containing
block chain and seeing if we find an ancestor that meets this criterion.
If so, we will start marking needs simplified layout on the chain.
The mechanism that is used is a new function on RenderGrid, which
is not meant to be completely exhaustive but focuses on some
simple pieces of content and can be built upon in future patches.
While most of the conditions we are looking at currently are fairly
straightforward, I should probably mention and explain my rationale for
a few notable ones:
1.) We check to see if the grid has a logical width of auto but couple this
with that fact that the grid needs to be participating in block layout/a
BFC. In some formatting contexts, having a logical width of auto may end
up performing some sort of measurements on the box based on the content,
but in this case, it should not, so we can allow it. If we need to check
whether or not the grid is extrinsically sized when it lives inside
another type of formatting context, we may need to revisit this logic to
make it correct.
2.) Checking to see if the grid has an aspect ratio. This is to avoid
the automatic content-based minimum size that may be applied by the use
of the property.
3.) Making sure all of the items are placed within extrinsically sized
explicit (i.e. grid-template-rows/columns) tracks. The purpose here is
twofold. First, if any items need item placement, which could happen by
adding or removing grid items, we should just bail out since at that
point the GFC itself experienced damage and we cannot predict what will
happen. Second, in a previous layout, a grid item may have been placed in
a track that was implicitly created. If that is the case, we need to
figure out how that track was sized since intrinsic values could have
been used for grid-auto-rows/columns, but we bail now for simplicity.
In order to accomplish the above, we needed to shuffle around the logic
in RenderTreeBuilder::attachToRenderGrid so that we mark the grid as
needing item placement before we attach the new renderer to the grid.
This is because we can only determine if all items are placed within
Extrinsic tracks if we do not need to perform item placement. Otherwise,
we could add a renderer to the grid, start marking the containing block
chain, and incorrectly determine we can mark the grid as needing
simplified layout before we mark it as needing item placement.
I also added various tests in grid-extrinsically-sized-mutations.html
to help test that we were still performing layout properly. The tests
include changes to the grid items only along with mutations on the grid
and the constraints imposed upon it by its containing block.
* LayoutTests/imported/w3c/web-platform-tests/css
* LayoutTests/imported/w3c/web-platform-tests/css
* Source/WebCore/rendering/RenderGrid.cpp:
(WebCore::RenderGrid::isExtrinsicallySized const)
(WebCore::RenderGrid::isPlacedWithinExtrinsically
* Source/WebCore/rendering/RenderGrid.h:
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::markContainingBlocksForLa
* Source/WebCore/rendering/updating/RenderTreeBui
(WebCore::RenderTreeBuilder::attachToRenderGrid):
Canonical link: https://commits.webkit.org/292994@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
