[css-position-4] Add "afterRemoval" steps to top layer removal algorithms #12850
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lukewarlow
reviewed
Sep 24, 2025
keithamus
force-pushed
the
add-afterremoval-steps-to-top-layer-removal-algorithms
branch
from
bff8cc6 to
7b2e190
Compare
keithamus
force-pushed
the
add-afterremoval-steps-to-top-layer-removal-algorithms
branch
from
7b2e190 to
a95da45
Compare
lukewarlow
reviewed
Sep 24, 2025
lukewarlow
reviewed
Sep 24, 2025
6 tasks
jakearchibald
approved these changes
Sep 24, 2025
|
This should get approval from someone else before it lands 😄 |
|
Non-editorial LGTM. This should wait till the HTML PR is ready and get merged together probably? Not sure who is the spec editor for this CSS spec but they should check this PR too. |
|
I have requested review from both spec editors. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refs whatwg/html#11694.
The spec for implicit anchors is slightly wrong, as the timing of when an implicit anchor can be removed is awkward.
Implicit anchors for elements in the top layer need to be removed after transitions, otherwise the anchor positioning may cause reflow.
Chrome "cheats" and skips reflow if the implicit anchor is being removed, but this can cause glitches if the anchored element reflows during this transition, as it will appear to move around the page (losing its implicit anchoring) when reflow is triggered.
Rather than doing this, I propose we add a "list of steps |afterRemoval|" to the "request an element to be removed from the top layer (immediately)" steps. This way we can use this as a callback to determine when the implicit anchor association should be removed.