Skip to content

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

@tuankiet65

Description

@tuankiet65

The spec 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 tests seem 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, (un)intentional side effects 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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions