w3c
[css-anchor-position] The "acceptable anchor" algo seems broken
The acceptable anchor text contains the following:
- possible anchor is painted strictly before positioned el, aka one of the following is true:
- (snip)
- Both elements are in the same top layer but have different containing blocks, and positioned el’s containing block is an ancestor of possible anchor’s containing block in the containing block chain, aka one of the following:
- positioned el’s containing block is the viewport, and possible anchor’s containing block isn’t.
- positioned el’s containing block is the initial containing block, and possible anchor’s containing block is generated by an element,
- 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.
I don't think some of these cases are correct.
For example:
- positioned el’s containing block is the initial containing block, and possible anchor’s containing block is generated by an element,
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.
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.
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. ^_^
-
Yeah, you're right, the anchor there is transitively relying on the ICB, and after the abspos. That'll need fixing.
-
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.
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.