[css-anchor-position] Anchor positioning proposal comparison

[stubbornella]

Please let me know if I'm opening this issue incorrectly!

@xiaochengh and I created a feature by feature comparison of the two anchor positioning proposals [1, 2] so we could better understand which features they each support.

As we were doing that, we realized that both had features they could support, but didn't yet. We'd like to explore extending the two proposals to the full feature set. To do so, we need your help, we are likely missing whole features and in some cases wrong about whether the feature is supported by each proposal, so please do add comments with corrections and I'll update the issue accordingly. There are also several where I didn't have enough information to be sure if it was supported. I marked those with a "?"

Feature table

• 🔶 = not currently, but probably could
• ❌ = not currently, would be difficult or impossible
• ✅ = supported

Most features could be supported by either proposal. But, each has weak areas that we can focus on improving before we compare the two.

Feature	Inset-based (current spec)	Grid-based
Named position areas	🔶	✅
Automatic alignment / justification	🔶	✅
Animations and transitions	✅	❌
Transitions between fallbacks	❌	❌
Center alignment	🔶	✅
Tether	🔶	✅
Tether behavior with deeply rounded corners	🔶	🔶
Tether behavior at a diagonal from anchor	🔶	🔶
Multiple anchors (document comments use-case)	✅	❌?
Strong expressiveness for complex cases	✅	🔶
Simple syntax position fallbacks	TBD	✅
Simple syntax for tether to work with position fallbacks	🔶	🔶?
Position fallbacks	✅	✅
Auto fallbacks (auto, auto-same)	✅	🔶
Keyword for aligning to center of anchor	✅	🔶
Styling the anchored element and tether with borders	🔶	✅
Styling the anchored element and tether with shadows	🔶	✅
Styling the anchor to sit on top of the backdrop	?	?
Automatic with no author code, “Tess mode”	🔶	🔶
Fixed position anchored element, scrollable anchor	✅	🔶
Fully logical positioning	✅	✅
Fully physical positioning	✅	✅
Logical / physical combo positioning	❌?	✅
Anchor name scoping	🔶	✅
Position-based styling	❌?	✅

[stubbornella]

Styling the anchor to sit on the backdrop was in one of the examples in the grid-based proposal. It may not have been intended to be included in this feature set. In this case the details button appears to be above a backdrop.

[stubbornella]

Multiple anchors example is a comment in a document which is aligned with it's corresponding text AND below the proceeding comment.

[kizu]

@stubbornella Thank you for this compilation! I'm slowly working on an article with my thoughts about this proposal, and this comparison is very helpful.

TL;DR for what I think: I really like some of the aspects of this proposal, and I think there could be a way to combine both the existing spec and it, merging the best parts of both. I really like the flexibility of the current implementation in Chrome, but I can see how the new exploration covers the areas the current spec lacks in — centering/aligning things, grid-like positioning, the ::tether pseudo-element.

A few quick notes (not exhaustive) regarding the comparison:

1. Re: “Tether” — while there is nothing that is intended directly for its purpose, it is possible to implement almost any kind of tethering with the current specs, not in the neatest way, and with hacks like “four quadrants” instead of the area-specific styles via ::tether(top / right) etc.

2. “Animations and transitions” — the current specs only allow transitions when changing the anchor inside the anchor()/anchor-size(), but not when swapping the values of the anchor-name (which could be more convenient for a lot of cases). A related issue: [css-anchor-1] Transitioning when the anchor element with a given name changes #8181 (comment)

3. “Center alignment” — it is possible to kind of work around its absence, but we don't have anything from the box that works for just one element at the moment. A related issue: [css-anchor-position-1][css-position] Add the “centering” behavior which is now defined as an example in the specs as something built-in #8979

4. “Multiple anchors” — one thing to note is that the main thing that prevents the new exploration from covering this use case is the way the lookup is defined in the https://fantasai.inkedblade.net/style/specs/css-anchor-exploration/#anchor-lookup by using the first element in the scope instead of the last. In my experiments, using the last element was much more convenient for almost every use case I tried, and it unlocks a lot of other use cases like nested dropdown menus.

5. “Styling the anchor to sit on top of the backdrop” — in my experiments, it is possible to work around this by “faking” it by creating a “hole” in the backdrop, either via a very large box-shadow, an outline, or in other ways. See this CodePen: https://codepen.io/kizu/pen/zYMBwNQ

6. “Automatic with no author code, ‘Tess mode’” — can you expand on what this means?

[Loirooriol]

Not sure if it's just me, but the table was confusing because github displays ✖️ and ❌ almost identically (both red), except for a few random cases where they look black. I have edited to use backticks which seem to fix the problem.

[xiaochengh]

“Animations and transitions” — the current specs only allow transitions when changing the anchor inside the anchor()/anchor-size(), but not when swapping the values of the anchor-name (which could be more convenient for a lot of cases). A related issue: #8181 (comment)

To clarify, this issue is more on the Chromium implementation side, not on the spec side. The proposal in #8181 should be sound on its own, but it requires a lot of change to Chromium's current implementation. The change should still be doable, though.

So if someone can convince me that this is a super important must-have part of the feature, then I'll prioritize the implementation in Chromium, which should then be enough to close the spec issue.

[tabatkins]

“Animations and transitions” — the current specs only allow transitions when changing the anchor inside the anchor()/anchor-size(), but not when swapping the values of the anchor-name (which could be more convenient for a lot of cases). A related issue:

To phrase this a little more clearly for others, changing from top: anchor(--foo) to top: anchor(--bar) works (it's a computed-value change, and will trigger a transition) but using top: anchor(--foo) and then changing which element that refers to (by changing the anchor-name property on other elements) doesn't (it's a used-value change right now, only visible when the anchor() function finally resolves into a length, so it's too late for transitions. That is, the computed value of anchor() is the specified value, but the used value is the actual length it's specified to resolve to.

Fixing that is easy on the spec side (as outlined in #8181, it just requires resolving the anchor name into an element reference at computed-value time), but as Xiaocheng said it's harder in our impl right now (but possible).

[tabatkins]

“Multiple anchors” — one thing to note is that the main thing that prevents the new exploration from covering this use case is the way the lookup is defined in the fantasai.inkedblade.net/style/specs/css-anchor-exploration/#anchor-lookup by using the first element in the scope instead of the last.

Afaict the problem is much more fundamental. That change in their proposal (going from the spec's "last" back to "first") was largely incidental; the issue is instead that the grid proposal has no way to refer to multiple anchors at all, and it's not immediately clear how it would be extended to do so.

[tabatkins]

Not sure if it's just me, but the table was confusing because github displays ✖️ and ❌ almost identically (both red), except for a few random cases where they look black. I have edited to use backticks which seem to fix the problem.

Putting them in code helped somewhat but it was still a little hard for me to tell apart. I've swapped the "not currently, but probably could" ✖️ for a 🔶, which I think still reasonably communicates negativity without being quite as strong, and is easily distinguishable from both of the other states.

[xiaochengh]

Given some recent progress, here's an updated comparison table:

Topic	Feature	Inset-syntax	Grid-syntax	Issue / Notes
Positioning	Named position areas	✅	✅	#9145 (resolved, details TBD)
Positioning	Keyword for aligning to center of anchor	✅	🔶
Positioning	Fully logical positioning	✅	✅
Positioning	Fully physical positioning	✅	✅
Positioning	Logical / physical combo positioning	✅	✅	#9268
Positioning	Fixed position anchored element, scrollable anchor	✅	🔶
Positioning	Multiple anchors (document comments use-case)	✅	❌?
Alignment	Center alignment with anchor	✅	✅	#8979 (resolved, some details TBD in #9124 and #9223)
Alignment	Automatic alignment / justification	🔶	✅	#9269
Animations	Animations and transitions	✅	❌
Animations	Transitions on anchor reference changes	🔶	❌	#8181
Animations	Transitions between fallbacks	❌	❌	#8372
Fallbacks	Position fallbacks	✅	✅
Fallbacks	Auto fallbacks by flipping / rotations	✅	🔶	#9196 (resolved, details TBD)
Fallbacks	Position-area list fallback syntax	🔶	✅	#9270
Fallbacks	Position-based styling of descendants	❌?	❌?
Scoping	Anchor name scoping with style containment	🔶	🔶	#9100
Scoping	Anchor naming scoping with a new property	🔶	✅	#9045, also #9045 (comment) and #9045 (comment)
Tether	Tether	🔶	✅	#9271
Tether	Tether behavior with deeply rounded corners	🔶	🔶
Tether	Tether behavior at a diagonal from anchor	🔶	🔶
Tether	Styling the anchored element and tether with borders	🔶	✅
Tether	Styling the anchored element and tether with shadows	🔶	✅
Tether	Simple syntax for tether to work with position fallbacks	🔶	❌?
Tether	Position-based styling of tether	🔶	✅
General	Strong expressiveness for complex cases	✅	🔶
Misc.	Automatic with no author code, “Tess mode”	🔶	🔶
Misc.	Styling the anchor to sit on top of the backdrop	?	?

[mirisuzanne]

Not sure there's anything specific to discuss on this issue at TPAC, since we have individual issues for everything listed here?

[astearns]

It’s likely the breakout session on Wednesday will be enough for this issue

https://www.w3.org/2023/09/TPAC/breakouts.html#b-3d55226e-0fdd-4836-b5fa-edaa77e10d34

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-position] Anchor positioning proposal comparison.

The full IRC log of that discussion

<ntim> TabAtkins: Listed out all the use cases, and what proposals can do them well, not well, etc.
<astearns> updated list: https://github.com//issues/9117#issuecomment-1698431865
<flackr> q+
<astearns> ack flackr
<ntim> flackr: I don't see transitions between anchors, which none of the proposals cover, but is very common
<ntim> una: I see transitions between fallbacks
<ntim> dbaron: look at the second list that astearns linked to
<dbaron> Is there an item in that list for the sidenotes / doc comments use case?
<ntim> TabAtkins: you can animate between 2 distinct anchors, the problem is animating when what an anchor name refers to changes
<ntim> fantasai: transition between two anchor names is in the table
<nicole> https://docs.google.com/document/d/185yzaofuMP2p1KK00e2J0cmL8vAxOY3LF7NxhpjveRo/edit
<ntim> (what flackr was referring to)
<nicole> This is the document of examples
<ntim> TabAtkins: does anyone see something obviously missing in the table?
<dbaron> ntim: "anchor reference changes" is a confusing term because it can mean either "a change to which anchor is referenced" or "the anchor that is referenced changes (e.g., moves)"... and we care about both
<ntim> fantasai: the ability to style based on fallbacks
<emeyer> q+
<dbaron> s/ntim:/dbaron:/
<flackr> q+
<astearns> add https://github.com//issues/9332 to the list
<TabAtkins> https://github.com//issues/9332
<flackr> q-
<astearns> ack emeyer
<ntim> emeyer: multiple anchors is something I'm interested in, there is no issue
<ntim> fantasai: not in the issue, because Tab's proposal already covers it
<ntim> fantasai: Not sure if it's covered, but cascading behavior on the @Try blocks is terrible
<TabAtkins> (it's on th elist of topics to discuss)