Skip to content

[css-anchor-position] The "acceptable anchor" algo seems broken #11030

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
jwatt opened this issue Oct 13, 2024 · 4 comments
Closed

[css-anchor-position] The "acceptable anchor" algo seems broken #11030

jwatt opened this issue Oct 13, 2024 · 4 comments
Labels
Closed Accepted as Obvious Bugfix css-anchor-position-1 Needs Testcase (WPT)

Comments

@jwatt
Copy link
Contributor

jwatt commented Oct 13, 2024

The acceptable anchor text contains the following:

  • possible anchor is painted strictly before positioned el, aka one of the following is true:

I don't think some of these cases are correct.

For example:

seems to say that this should work:

<body>
  <div class="anchored" style="position: absolute;"></div>
  <div style="position: absolute;">
    <div class="anchor"></div>  
  </div>
</body>

And:

  • both elements' containing blocks are generated by elements, and positioned el’s containing block is an ancestor in the flat tree to that of possible anchor’s containing block.

seems to say that this should work:

<body>
  <div style="position: absolute;">
    <div class="anchored" style="position: absolute;"></div>
    <div style="position: absolute;">
      <div class="anchor"></div>  
    </div>
  </div>
</body>

In other words, in these two cases we sometimes still require that "possible anchor is earlier in flat tree order than positioned el."

This seems...hard to spec.
@jwatt
Copy link
Contributor Author

jwatt commented Oct 13, 2024

See also #11029

@jwatt
Copy link
Contributor Author

jwatt commented Oct 14, 2024

It's really unfortunate that the term absolutely positioned is formally understood to mean "absolutely positioned" or "fixed positioned", because I think we want to be able to say absolutely positioned in places here and not mean fixed positioned.

@tabatkins
Copy link
Member

No, we don't want to distinguish abspos vs fixpos in that way, because a fixpos can act like an abspos given certain ancestor styles. What you actually care about is whether the containing block comes from the viewport, or something else, and that's the distinction I'm making in the algo.

That said, let me look at your actual feedback. ^_^

  1. Yeah, you're right, the anchor there is transitively relying on the ICB, and after the abspos. That'll need fixing.

  2. Yeah same deal.

But it's not about flat tree - in both of those cases, the flat tree is identical to the DOM tree, because there's no shadows involved. I'll just need to do some finessing about ancestors in the abspos containing block tree.

tabatkins added a commit that referenced this issue May 9, 2025
@tabatkins
[css-anchor-position-1] Copy over the 'penultimate CB must precede th…
cc3c3ef 
…e abspos' text from the next bullet point to cover similar cases here. #11030.
@tabatkins
Copy link
Member

All right, (2) is solved by restoring the text I'd accidentally deleted earlier, and restored when fixing #11170. I solved (1) by just copying the same text over, as the exact same condition applies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed Accepted as Obvious Bugfix css-anchor-position-1 Needs Testcase (WPT)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jwatt @tabatkins @fantasai @nt1m