[csswg-drafts] [css-anchor-position] Invalidation of last successful position option in cases not in the spec (#12577)

tuankiet65 has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-anchor-position] Invalidation of last successful position option in cases not in the spec ==
[The spec](https://drafts.csswg.org/css-anchor-position-1/#last-successful-position-option) says that the last successful position option is cleared in the following cases:
* when the element is not absolutely positioned anymore
* when the computed value of `position-try-fallbacks` for the element changes
* when any `@position-try` rules referenced by the element's `position-try-fallbacks` changes

But from testing WebKit's implementation against WPT, it seems that some other cases could also trigger invalidation:
1) when the computed value of `position-try-order` changes (WPT `position-try-order` seems to expect this)
2) when the "base style" of the element changes (e.g by adding/removing a class from an element, see https://github.com/web-platform-tests/wpt/blob/719745a09c32182d0b0785a7ac8c393cc44d8c51/css/css-anchor-position/base-style-invalidation.html)
3) when a position-try fallback rule doesn't refer to an anchor, and the base style changes (???) (see https://github.com/web-platform-tests/wpt/blob/719745a09c32182d0b0785a7ac8c393cc44d8c51/css/css-anchor-position/anchor-position-non-anchored-fallback.html)

(1) makes sense to invalidate, but (2) and (3) seems like a bug (or at least, some intended side effect in Chrome?) So I'm looking for clarification on if the tests are correct or not, and if they are, we should include those cases in the spec.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12577 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 6 August 2025 21:12:12 UTC