Skip to content
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

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

Open
jwatt opened this issue Oct 13, 2024 · 3 comments
Open

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

jwatt opened this issue Oct 13, 2024 · 3 comments
Labels
Closed Accepted as Obvious Bugfix css-anchor-position-1

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.

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
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jwatt @tabatkins