[css-anchor-position-1] Snapshotted scroll offset needs to consider both axis separately

[xiaochengh]

(Originally filed as a Chrome bug)

From the current spec, an absolutely positioned element query el has a snapshotted scroll offset if:

• there is a target anchor element given the default anchor specifier of query el
• and at least one anchor() function on query el refers to the same target anchor element

Proposal: See #9239 (comment)

I propose removing the second condition, because:

1. This condition is complicated to check. We need to go through both the base style and all the fallback styles
2. It doesn't work with the new anchor-center alignment keyword, which can be used alone without any explicit anchor() functions
   • This also suggests that the condition isn't future-proof. If we introduce new anchoring syntax in the future, this condition has to grow more complicated
3. Having a valid default anchor without actually positioning it against the anchor is a weird/incorrect usage. I don't see much value guarding against such usage

[tabatkins]

Having a valid default anchor without actually positioning it against the anchor is a weird/incorrect usage. I don't see much value guarding against such usage

I don't quite agree. A final fallback might reasonably be to just position in screen space, for example, without reference to any anchor at all, or position relative to a different anchor. Having the element still get shifted to match the scroll offset of the default anchor element seems weird/bad, and anchor-default isn't settable from the fallback styles so the author wouldn't have any way to stop that from happening.

That said, I sympathize with the "complicated to check", and you're right that anchor-center positions relative to the anchor without any anchor() functions at all, so something definitely has to change.

• The minimal change is to just generalize the condition to check for the element referring to the default anchor element in any way (either via anchor() or via anchor-center alignment, or any future ways we add).
• I'd be okay with removing the check entirely and making it always apply if there was a way for the author to opt out of it. I think allowing anchor-default to be set in fallback styles should be just fine, since it's (almost) identical to just specifying that anchor explicitly in each function. (There's just a few things that only look at the default anchor and don't otherwise have a way to specify what that is, like anchor-center.) (And actually allowing anchor-default to change in fallbacks would actually be good for things like anchor-center, so you could center on a different element. It's weird that, right now, you can't do that.)

---

In conclusion, yeah I'm totally fine with dropping the condition if we also allow anchor-default to be set in fallback styles.

[xiaochengh]

Further feedback from the Chrome bug reporter:

Image a footnote popup that’s fixed-position against the bottom of the viewport, but anchored to one or both sides of an anchoring element. If I understood what you said there in https://bugs.chromium.org/p/chromium/issues/detail?id=1473388#c4, there would be no way to anchor one or more edges of an element while having it be fixed-positioned along a different edge. This breaks my use case, which I like to think is legit.

So this use case requires us to track the scroll position of the anchor in one axis but not the other, which gets the issue even more complicated. As a result:

Updated Proposal: we not only need to keep this condition, generalize it to work with anchor-center, but also have to make it axis-aware: for each axis, there's a snapshotted scroll offset in that axis if there's any reference to the anchor's location in the same axis in the used style (i.e., after position fallback applied).

It's getting quite complicated, but I don't see any other way to make it work.

Btw, compared to this, I'm still not a fan of reviving the anchor-scroll property, because it's still unnecessarily exposing technical details.

[tabatkins]

Afaict, fixed with @xiaochengh's edits in #9347.