Skip to content

[css-anchor-position-1] "determine position fallback styles" algorithm doesn't consider not using an option #12890

Closed

Description

@tuankiet65

In the "Applying Position Fallback" section, the "determines position fallback styles" algorithm is used to figure out which position fallback option should be used next, when the box overflows in the current style:

To determine position fallback styles for an element abspos:

  1. Let current styles be the current used styles of abspos (which might be the result of earlier fallback).
  2. For each option in the position options list:

1 ) If option is currently abspos’s last successful position option, continue.
...

  1. Assert: The previous step finished without finding a position option that avoids overflow.
  2. Return current styles.

It appears that the algorithm forgets to consider the case when no option is used?

For example, consider a box with three position options:

  • Initially, the box doesn't overflow with the original style, so no position option is applied
  • Then, something happened (style changes or scrolling) that makes the box overflow, so it tried the position option and option 2 works.
  • Later on, some other thing happened that makes the box overflow. If following the algorithm above, it'd only consider option 1/2/3 and not the original style, even though the original style could've worked.

From my experimentation, the following order seems to pass most (maybe all?) WPT tests:

  • Try the last successful position option first
  • Then try the original style without option
  • Then try the options in the position option list except the last successful position option.

Activity

  1. fantasai commented on Oct 2, 2025

    @fantasai
    Collaborator

    I think we should define the "position options list" as including the original style. That it doesn't is really confusing, actually.

  2. tabatkins commented on Nov 5, 2025

    @tabatkins
    Member

    Yes, the base styles are meant to be part of the list. I suspect the current wording mistake is a leftover from when that temporarily wasn't the case (at some earlier point, if you used position-try at all, you just didn't set any relevant base styles at all; the position-try-options list gave all the possibilities).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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