#1182: WG Revision: CSS Anchor Positioning Level 1

Visit on Github

Opened Dec 23, 2025

Specification

https://www.w3.org/TR/css-anchor-position-1/

Explainer

https://ishadeed.com/article/anchor-positioning/ is a pretty good intro at this point

Links

  • The WG's request for this TAG review: https://github.com/w3c/csswg-drafts/issues/13265
  • TAG review of the previous version of this specification, if any: https://github.com/w3ctag/design-reviews/issues/848
  • A description of what has changed since our previous review: Introduced position-area and position-visibility properties, introduced anchor-center alignment, renamed anchor-default to position-anchor, redesigned the fallback mechanism to use new position-try-* properties, and made many adjustments to layout details and algorithms. In short, the API has been thoroughly redesigned though the anchor() functions remain mostly intact.

The specification

Where and by whom is the work is being done?

  • GitHub repo: https://github.com/w3c/csswg-drafts/issues
  • Primary contacts:
    • Elika J. Etemad (@fantasai), Apple, co-editor, co-implementer
    • Tab Atkins, Jr. (@tabatkins), Google, co-editor
  • Organization/project driving the specification: Google, Apple
  • This work is being funded by: Google, Apple, Mozilla, Igalia
  • Primary standards group developing this feature: CSSWG

Feedback so far

You should also know that...

We're asking for a re-review of the spec because it has gone through substantial changes since the FPWD. At this point we have some detailed technical issues to work through, but expect the spec to go to CR largely in this form. The TAG may waive this review if you feel it is not needed.

Interesting points to consider from the TAG perspective are the points of integration with HTML, see in particular the position-anchor property as part of determining the anchor box. We also ended up requiring the position-area property to resolve auto margin values to zero because this was the only way to address confusing interactions with the HTML default UA stylesheet for popovers in a backwards-compatible way. (It had been noted that these rules could cause integration problems when they were being developed, but anchor positioning wasn't developed enough to rely on it back then, so HTML pushed ahead with what they had.)

One of Mozilla's main concerns with this spec is the Layout & Style interleaving requirement for resolving anchor() values. See https://www.w3.org/TR/css-anchor-position-1/#anchor-pos This aspect was left out of Interop 2025 testing for that reason.

<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1182

Discussions

Log in to see TAG-private discussions.

Discussed Jan 12, 2026 (See Github)

Xiaocheng: Want to have Matthew drive this review, as I was involved in the spec process, and I’m obviously very positive. I proposed a lot of ideas. My question is, there was a concern raised by Mozilla, but I think it is wrong, and I’m trying to confirm this.

Lola: Matthew, are you okay driving this? Do you need another reviewer?

Matthew: APA is looking at this at the same time, we are working on suggestions for the A11y considerations section, and should be done on that fairly soon. Not sure if we commented on this before. Will keep you all updated. Core thing that it does is really good for accessibility. Seems like a nice feature. There were a couple of concerns about the accessibility considerations section. We are working on some suggestions, more on this soon.

Comment by @xiaochengh Jan 15, 2026 (See Github)

Hi @fantasai,

One of Mozilla's main concerns with this spec is the Layout & Style interleaving requirement for resolving anchor() values.

As I understand this is not correct due to the requirement of acceptable anchor element, which allows us to resolve all anchor() functions during the layout stage.

Could you clarify?

Discussed Jan 19, 2026 (See Github)

Xiaocheng: I’d like Matthew to drive this review.

Matthew: As said last week, APA is looking at it, we want things specifically to put in the a11y considerations section. No additional concerns or updates since last week, we’ll be wrapping it up from an APA perspective before next week. Will mention it in Slack if anything comes up, no active updates otherwise.

Hadley: More broadly than a11y, no other feedback?

Matthew: Trying to do that from TAG perspective, but looking forward from additional insights from CSS experts.

Hadley: Want to clarify the status regarding TAG activity. You are part-way through that?

Matthew: Yes.

Discussed Jan 26, 2026 (See Github)

Matthew: I had mentioned that APA was providing feedback on accessibiliyt considerations. I wasn't concerned about most of it. Overall it seems like a good trend, moving stuff out of javascript into CSS, more declarative etc. So, no pure CSS concerns. But from APA's view, it crates a trap for developers, because it removes boilerplate code but you stil have to do the js if you're doing this with custom elements, you have to do the keyboard handling and ARIA etc. So how much does it save developers? It's probably a net positive, but smaller than it might have been.

APA worry that people will think "we just do this and it's accessible", but it isn't. APA will be emphasising that.

So this is moving in a positive direction, but we do need to make developers aware it's not a "get out of javascript free" card.

I don't know if Xiaocheng has extra thoughts? He was involved in writing the spec. It's due on the 30 January, which is the last day of their face to face. The next one is April.

Hadley: so the TAG view on this is that it's fine, assuming the accessibility issues get sorted with APA?

Matthew: yes. We need to set those expectations with developers. Guidance, not normative.