Intent to Ship: CSS Anchor Positioning

3,829 views
Skip to first unread message

Mason Freed

unread,
Apr 11, 2024, 7:04:02 PMApr 11
to blink-dev

Contact emails

mas...@chromium.org


Explainer

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CSSAnchoredPositioning/explainer.md

https://xiaochengh.github.io/Explainers/css-anchor-position/explainer.html

https://developer.chrome.com/blog/tether-elements-to-each-other-with-css-anchor-positioning

https://12daysofweb.dev/2023/anchor-positioning


{Note: the explainers above are in chronological order. This feature has been in public discussion since 2021, so there is significant history. As such, the explainers above explain the user problem anchor positioning intends to solve and why it solves them, but in some cases reference an out-of-date API shape. In parallel with this I2S we are working on an updated blog post that uses the latest spec draft syntax.}


Specification

https://drafts.csswg.org/css-anchor-position-1


Summary

CSS anchor positioning allows authors to "tether" an absolutely positioned element to one or more other elements on the page (the "anchors"), in a declarative way, without the use of Javascript. Anchor positioning works performantly when the anchors are scrollable. A common use case is to position a popover such as a tooltip next to the element that invoked it, or a select menu and its popover options list. Before the anchor positioning feature, these use cases required Javascript to dynamically position the popover, and keep it anchored as the invoking element was scrolled, which is a performance footgun and difficult to get right. With anchor positioning, these use cases can be implemented performantly and declaratively.


The anchor positioning feature consists of a large number of CSS properties, which are fully described in the spec (https://drafts.csswg.org/css-anchor-position-1). The key features/properties include:


  • `anchor-name`: sets up an element to be an anchor for other elements.

  • `position-anchor`: describes the "default" anchor that an anchored element should use for anchor positioning.

  • The `anchor()` function: used to refer to the position of the anchor element, in positioning the anchored element. E.g. `top: anchor(bottom)`. In addition to implicitly using the `position-anchor` as the anchor, explicit anchor references can also be used, e.g. `top: anchor(--button bottom)`.

  • The `anchor-size()` function: used to size the anchored element relative to the anchor. For example, `width: anchor-size(width)` would make the anchored element have the same width as the anchor element.

  • `inset-area`: a shorthand for positioning, for common relative positions. E.g. `inset-area: top left`. Many inset-area values are available, making common use cases easy to implement.

  • The “position-try” properties and @ rules: enables “fallback positioning”, which allows multiple potential position options to be considered, with the “best” option automatically selected. The related properties/rules are:

    • `position-try` (and associated longhands): a list of options for positioning the anchored element. The “best” of these options will be selected based on the position of the anchor, the layout of the anchored element, and the available space.

    • `@position-try`: one set of positioning properties to be considered as an option within a `position-try` list. E.g. `@position-try --left-side {right: anchor(left)}`.

    • `position-try-order`: select the position option based on available space, e.g. the one with the `most-block-size`.

    • the “try-tactics”: shorthand values for `position-try` that automatically generate common positioning options, such as `flip-block` to automatically flip to the other side of the anchor in the block direction.

  • The `anchor-center` value, for the self-alignment properties. This value allows easy centering of an anchored element relative to the anchor element.

  • The `position-visibility` property: specifies that the anchored element should be hidden in some circumstances, based on the visibility/availability of the anchor element. For example, `position-visibility: anchors-visible` will hide the anchored element when the anchor is no longer visible.


All of the above features are implemented and fully-tested. Some corner cases are not supported for now:

  • The `anchors-valid` value for the `position-visibility` property is not yet supported. This value has some open spec questions (csswg-drafts/issues/10201) that we feel need more crisp discussion and definition. The remaining values are supported, and the missing value is feature-detectable via `@supports`. We are tracking this in crbug.com/333421963.

  • The interaction of `anchor-name` with content-visibility is not fully implemented, particularly when the anchored element is hidden but the anchor is not. The spec csswg-drafts/issues/10184 has recently been resolved, so we will implement the resolved behavior. We are tracking this in crbug.com/333443429.

  • The `anchor-scope` CSS property is not yet implemented. We are tracking that in crbug.com/40281992.

  • The “last-successful-position-option” portion of the “determine the position fallback styles” algorithm is not yet implemented. We are tracking that in crbug.com/331841274.

  • There is a discussion about expanding `anchor-size()` to be allowed in more properties (csswg-drafts/issues/9827) and once that gets resolved, we will implement the resolved behavior. We are tracking this in crbug.com/333421962.

  • There is a discussion (csswg-drafts/issues/10182) about adding a new "visibility: strongly-hidden" value (which 'position-visibility' forces the element to compute to), and which can be used in animations/transitions. Once that gets resolved, we will implement the resolved behavior. We are tracking this in crbug.com/333477766.


We believe all of these corner cases will not impact early adopters of this feature, will be backward-compatible, and we also plan to add support for them (once any spec issues are resolved) in the coming weeks (with additional I2S or PSA). We further strongly believe that there is great value in launching the feature now, to let developers test the overall feature, discover new use cases (and bugs), and increase the level of feedback we receive to continue to shape the feature going forward.


{Due to chromestatus character limitations, not everything from this email exists in the chromestatus entry. This description is more complete.}


Blink component

Blink>Layout


Search tags

css, anchor, position


TAG review

https://github.com/w3ctag/design-reviews/issues/848


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

Low risk, since this is a new feature. This feature received very robust review at the CSSWG over many meetings and many years, and has had multiple public working drafts posted.


Gecko: Positive (https://github.com/mozilla/standards-positions/issues/794)


WebKit: No signal (https://github.com/WebKit/standards-positions/issues/167)


Web developers: Strongly positive (https://crbug.com/40059176 has 37 stars)

Lots of excited developer blog posts:




Ergonomics

One feature that works quite nicely with anchor positioning is the Popover API, which will soon be supported in all browsers.


There should not be any performance issues, since the API was designed carefully with performance in mind.



Activation

There is an anchor positioning polyfill for some features (see the Limitations section in the linked document), but it may not be up-to-date with the latest syntax changes. 


There are also a few quite common libraries that do "anchor positioning" in userspace, e.g. popper.js / floating-ui. Much of the functionality in those libraries could be implemented using the anchor positioning API, and we have engaged with the authors of these libraries to incorporate important use cases.



Security

N/A



WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No.



Debuggability

DevTools has basic support for anchor positioning, including making sure auto-fallback styles are properly displayed. There is a plan to add advanced support (e.g. showing the current anchor element for an anchor reference) in the future.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes


Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/css/css-anchor-position



Flag name on chrome://flags

CSSAnchorPositioning


Finch feature name

CSSAnchorPositioning


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/40059176


Measurement

https://chromestatus.com/metrics/feature/timeline/popularity/4467


Sample links

https://anchor-tool.com


Estimated milestones

Shipping on desktop: 125

DevTrial on desktop: 104

Shipping on Android: 125

DevTrial on Android: 104

Shipping on WebView: 125


Anticipated spec changes

There are no known spec changes planned that might risk interop. As a large feature, there are (and will likely always be) open issues to expand the feature, add capabilities, tweak corner cases, etc. After landing the initial feature, developers will begin to explore how it works, and will undoubtedly discover new ways to use it, potentially uncovering new feature requests or behavior change requests. This is as-intended, and is the reason we’d like to start shipping this feature now, to get that process started. This is all equivalent to additions/changes made after shipping CSS flex and grid, for example. There is a very small list of open issues, most of which are small editorial issues. A few represent changes needed to the spec, and those are all discussed in the Summary section above. Upon a very careful review, none of the open issues appear to present any type of backwards compatibility issue, if addressed properly.


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5124922471874560


Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/vsPddM3fGj0/m/5s87Yx95BAAJ

Ready for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/vsPddM3fGj0/m/5s87Yx95BAAJ



This intent message was generated by Chrome Platform Status {and edited to provide more context}.


Dan Clark

unread,
Apr 11, 2024, 10:58:18 PMApr 11
to blink-dev, mas...@chromium.org
I'm really excited to see this move forward!

For the TAG review, it's not clear to me that they've had a chance to re-review yet since the last substantial updates. I'm not suggesting that we delay shipping at this stage, but maybe worth sending them a heads-up that this could be shipping imminently so they can prioritize accordingly?

-- Dan

Mason Freed

unread,
Apr 12, 2024, 12:27:17 PMApr 12
to blink-dev, dan...@microsoft.com, Mason Freed
On Thursday, April 11, 2024 at 7:58:18 PM UTC-7 dan...@microsoft.com wrote:
I'm really excited to see this move forward!

Thanks! Me too - exciting after about 4 years of working on it, right? Thanks for all of the help on this, especially early on.
 
For the TAG review, it's not clear to me that they've had a chance to re-review yet since the last substantial updates. I'm not suggesting that we delay shipping at this stage, but maybe worth sending them a heads-up that this could be shipping imminently so they can prioritize accordingly?

So we did ping the TAG review about a month ago, but we didn't get any response. I'll do that again right now - thanks for the suggestion. We will be sure to take their feedback into account as this feature evolves and grows.

Thanks,
Mason

 

fantasai

unread,
Apr 15, 2024, 1:55:56 AMApr 15
to blin...@chromium.org
Speaking for myself only (not as Apple/WebKit), as an individual co-editor of this spec--and from the perspective of having edited many layout specs including Grid and Flexbox--I think Anchor Positioning is not quite ready to ship (though I think it's pretty close).

The spec just went through a significant overhaul, with major changes to syntax, behavior, and interactions among various features. Typically after such changes, a spec needs some time to settle, and also another round of review to flush out additional issues and refine the new design. This is particularly true for layout specs due to their complexity--both the inherent complexity of the feature (we want to ensure it's fully coherent, even after all the changes), as well as the complexity of how it gets used (we want to ensure good usability for the various use cases).

Grid Layout is an example of this: we merged several proposals into the current design, and the spec went through cataclysmic changes as a result. It took another few rounds of revision before we got to something stable, and it was good for authors that, unlike Flexbox, when Grid shipped it was something well-designed, well-refined, and reliable.

What's needed for Anchor Positioning at this time, and I was hoping we could get, is wide review on the revised design:
  • soliciting feedback from authors, to see if there are additional things to tweak for usability, additional use cases we can adjust to accommodate, or other points of difficulty we can resolve.
  • soliciting horizontal review at W3C, particularly wrt accessibility. (I think we handled most internationalization concerns in this last round, and don't anticipate much wrt privacy or security, but accessibility remains a concern.)
  • soliciting detailed review of the revised spec from CSSWG members, to ensure the details are completely, correctly, and reasonably specified, and the feature is self-coherent and integrates well with the rest of CSS.
AFAICT, we haven't actively solicited these reviews yet.

I do think Anchor Positioning is in good shape right now in the sense that I think most major concerns with the earlier design are resolved. I don't anticipate further major changes to the design and implementation. But I do think it's reasonably likely that we'll want to make minor breaking changes to syntax and behavior during this settling period, and I don't want us to be constrained by a shipping Chrome implementation.

(For additional context, my response here is prompted by a non-Apple, non-WebKit CSSWG member messaging me over the weekend and asking "isn't this a bit premature?" So it's not just me/Apple that has some lingering concerns. :)

In terms of scheduling, I think targetting the summer is better: Tab is giving a talk on Anchor Positioning at CSS Day, which I think is a great opportunity to present the full proposal and Chrome's implementation in its latest form and solicit feedback from advanced CSS authors, and there's a CSSWG F2F the following week during which we should be able to resolve any issues remaining or raised during wide review.

(None of what I'm saying here should be a surprise: after we landed most of the changes, I did discuss the timelines with Tab, and my expectation that the spec could likely be basically settled by around June, and that if we kept at it, CR would be possible by the fall.)

On the topic of accessibility in particular, it is not addressed at all in the draft. Whether there needs to be some special affordance in implementations or not, we need to address accessibility requirements and best practices and document them clearly, as we did with Grid and Flexbox. The point at which this feature ships in Chrome is the point at which knowledge of this feature and how to use it will start to spread widely and rapidly. We need to have a solid accessibility story prepared, documented, and evangelized together with the basic how-tos and other DevRel around this CSS feature at the same time as it's released. And I suspect the story here is going to be more complex than Grid and Flexbox.

Again, layout specs are complex, and even minor changes to them are often breaking. Let's make sure what we're shipping is truly excellent, so we don't have regrets later.
Google's CSSWG reps have been in continuous conversation with Apple's reps on this topic through the CSSWG and the WebKit team did respond to the standards position... so "no signal" doesn't seem like a meaningful or accurate summary of WebKit's position. Maybe "generally positive, but with some reservations" would be more accurate? Representing that as "no signal" is misleading.

~fantasai
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgGMzSh43dYk486vdsWZG0upxwzqw%3DpiL16pCz-Wh0Acw%40mail.gmail.com.

Mason Freed

unread,
Apr 15, 2024, 8:57:40 PMApr 15
to fantasai, blin...@chromium.org
Thanks for the detailed reply, fantasai! And also thank you very much for all of the hard work you and Tab have put into this feature to make it what it is. We very much appreciate it.

More inline:

On Sun, Apr 14, 2024 at 10:56 PM fantasai <fantasa...@inkedblade.net> wrote:
Speaking for myself only (not as Apple/WebKit), as an individual co-editor of this spec--and from the perspective of having edited many layout specs including Grid and Flexbox--I think Anchor Positioning is not quite ready to ship (though I think it's pretty close).

The spec just went through a significant overhaul, with major changes to syntax, behavior, and interactions among various features. Typically after such changes, a spec needs some time to settle, and also another round of review to flush out additional issues and refine the new design. This is particularly true for layout specs due to their complexity--both the inherent complexity of the feature (we want to ensure it's fully coherent, even after all the changes), as well as the complexity of how it gets used (we want to ensure good usability for the various use cases).

It sounds from your overall comment here that you think the feature is quite close to “ready” - I’m glad! We agree with that general point. You say you don’t think it’s “quite ready to ship” here and I appreciate that. One thing to note is that we’re very committed to addressing any open issues, either now or after additional issues are discovered. We further strongly believe that shipping the API allows **all** developers to start kicking the tires of the feature to find open issues. It’s possible that issues would be discovered by the CSSWG community via a spec-text-only review, but that’s much more likely to happen when many developers are actively trying to make it work for their application using a real implementation.
 
AFAICT, we haven't actively solicited these reviews yet.

I do believe we’ve been pretty actively soliciting feedback for the past two years as the feature was developed, and we’ve received some great feedback that helped shape the feature, particularly from Apple. Having said that, we plan to participate in the steps to get to CR over time.
 
I do think Anchor Positioning is in good shape right now in the sense that I think most major concerns with the earlier design are resolved. I don't anticipate further major changes to the design and implementation. But I do think it's reasonably likely that we'll want to make minor breaking changes to syntax and behavior during this settling period, and I don't want us to be constrained by a shipping Chrome implementation.

Again, I’m glad you don’t anticipate major changes. And we fully expect to see minor breaking changes as the feature gets wider evaluation by developers. It would be natural to assume some reasonable such changes over the coming months, and Chrome will be open to such changes if they are compelling, even if they’re breaking.
 
(For additional context, my response here is prompted by a non-Apple, non-WebKit CSSWG member messaging me over the weekend and asking "isn't this a bit premature?" So it's not just me/Apple that has some lingering concerns. :)

This is a very large feature, so there is bound to be some discomfort about shipping it, no matter when that shipment happens. I do understand! But we’ve also received a significant number of developers commenting that they were very excited to see this feature finally shipping after all these years.
 
In terms of scheduling, I think targetting the summer is better: Tab is giving a talk on Anchor Positioning at CSS Day, which I think is a great opportunity to present the full proposal and Chrome's implementation in its latest form and solicit feedback from advanced CSS authors, and there's a CSSWG F2F the following week during which we should be able to resolve any issues remaining or raised during wide review.

I think you’re right that these venues will provide great opportunities to discuss the feature and talk about improvements. Indeed, there is a long list of css-anchor-position-2 issues that will provide discussion topics for many meetings to come, I’m sure. 
 
On the topic of accessibility in particular, it is not addressed at all in the draft. Whether there needs to be some special affordance in implementations or not, we need to address accessibility requirements and best practices and document them clearly, as we did with Grid and Flexbox. The point at which this feature ships in Chrome is the point at which knowledge of this feature and how to use it will start to spread widely and rapidly. We need to have a solid accessibility story prepared, documented, and evangelized together with the basic how-tos and other DevRel around this CSS feature at the same time as it's released. And I suspect the story here is going to be more complex than Grid and Flexbox.

Are there particular issues you’re aware of? The only one I’m aware of is csswg-drafts/issues/9356 which talks about display and keyboard ordering. Incidentally, that’s an issue that applies to Grid and Flexbox already, and we’re actively working on a prototype implementation and spec proposal for `reading-order-items`. But as evidenced by that, even Grid/Flexbox aren’t fully “done” yet. Are there other a11y issues related to anchor pos? We’re not aware of any, but please do raise the ones you see.

Your point about having the a11y story documented is a good one. We will make sure to include that story in blog posts, etc. If you have particular points to include, please do share.

Thanks again for the detailed comments!

Thanks,
Mason

 


You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/jGTYNuidPRs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7fe37aa5-7cf4-40f8-9581-f12ff0817caf%40inkedblade.net.

Alex Russell

unread,
Apr 16, 2024, 1:58:08 PMApr 16
to blink-dev, Mason Freed, blin...@chromium.org, fantasa...@inkedblade.net
LGTM1. Excited to see this ship!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/jGTYNuidPRs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+unsubscribe@chromium.org.

Mike Taylor

unread,
Apr 16, 2024, 2:34:51 PMApr 16
to Alex Russell, blink-dev, Mason Freed, fantasa...@inkedblade.net

LGTM2. And thanks to fantasai for giving a more nuanced read on the lack of an official, published WebKit position. I appreciate the rest of the concerns raised, and agree with Mason that getting the feature in front of developers will be a net positive now, vs delaying until some future post-review time.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4b163fec-0afb-436e-af2c-7a3651ae0951n%40chromium.org.

Rick Byers

unread,
Apr 16, 2024, 3:05:56 PMApr 16
to Mike Taylor, Alex Russell, blink-dev, Mason Freed, fantasa...@inkedblade.net
LGTM3 

There's definitely some forward compat risk here, but we know adoption for these sorts of features tends to be slow before reaching all engines, so I'm confident in our ability to make small breaking changes as needed as the spec continues to mature. Seeing how much diligence and review has gone into this after 4 years of work, lacking significant known open issues, and the benefits for web developers, I think it's consistent with the Chromium project value of carefully but urgently pushing the web forward to be shipping this now, despite the discomfort in not yet being perfect.

Thank you Fantasai for the feedback and the additional context on the webkit standards position. Note that we were explicitly asked (by Maciej I think?) to wait for the standards position to be officially set before claiming something other than "no signals" to ensure we're accurately reflecting the position of the WebKit project overall (rather than just the support of some select engineers). But adding additional context to "no signals" is definitely worth doing, thank you for correcting that!

Rick

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/jGTYNuidPRs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4b163fec-0afb-436e-af2c-7a3651ae0951n%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Mason Freed

unread,
Apr 16, 2024, 3:55:26 PMApr 16
to Rick Byers, Mike Taylor, Alex Russell, blink-dev, fantasa...@inkedblade.net
Thank you all! I really appreciate the feedback and support.

Thanks,
Mason

Daniel Herr

unread,
Apr 16, 2024, 4:01:11 PMApr 16
to blink-dev, Rick Byers, Alex Russell, blink-dev, Mason Freed, fantasa...@inkedblade.net, Mike Taylor
If there is some debate as to whether the design is finished and the possibility of breaking changes, but also a desire to let developers try it out in production, why not use an origin trial instead of straight to shipping?

Domenic Denicola

unread,
Apr 16, 2024, 9:00:18 PMApr 16
to Daniel Herr, blink-dev, Rick Byers, Alex Russell, Mason Freed, fantasa...@inkedblade.net, Mike Taylor
Mason, can you confirm that what is shipping is accurately represented by the specification field, i.e., CSS anchor positioning only? In particular, the HTML anchor="" attribute is not included in this I2S?

Mason Freed

unread,
Apr 17, 2024, 12:49:05 PMApr 17
to Domenic Denicola, Daniel Herr, blink-dev, Rick Byers, Alex Russell, fantasa...@inkedblade.net, Mike Taylor
On Tue, Apr 16, 2024 at 6:00 PM Domenic Denicola <dom...@chromium.org> wrote:
Mason, can you confirm that what is shipping is accurately represented by the specification field, i.e., CSS anchor positioning only? In particular, the HTML anchor="" attribute is not included in this I2S?

Yep, great question. The chromestatus is accurate - the thing shipping is CSS anchor positioning, and not the `anchor` attribute. That spec PR is still being discussed, and the implementation in Chrome is behind a different flag (HTMLAnchorAttribute).
 
On Wed, Apr 17, 2024 at 5:01 AM Daniel Herr <danielst...@gmail.com> wrote:
If there is some debate as to whether the design is finished and the possibility of breaking changes, but also a desire to let developers try it out in production, why not use an origin trial instead of straight to shipping?

This is a great question also, and the answer is a few things. We've been at this for several years, and it's reaching the point where we need concrete developer feedback from a wide set of viewpoints. A small number of Origin Trial users will more likely focus on the "core" of the feature, and will not fully exercise the "edges", which is typically where the latent issues reside. Shipping to a wider audience gives a much larger chance to find and resolve these issues. Another issue is that an OT on CSS features can be more difficult to implement on a production site, since CSS is difficult to polyfill, further reducing the pool of developers.

Thanks,
Mason

fantasai

unread,
May 1, 2024, 1:04:39 PMMay 1
to blin...@chromium.org
On 4/16/24 09:57, Mason Freed wrote:
Thanks for the detailed reply, fantasai! And also thank you very much for all of the hard work you and Tab have put into this feature to make it what it is. We very much appreciate it.

And I appreciate all the hard work the Chrome Team has put into implementation and iteration, as this was not an easy feature to fit into CSS's architecture. Also for being open to revision from your original design.

One thing to note is that we’re very committed to addressing any open issues, either now or after additional issues are discovered.

You won't be as open to change after you ship, though, because then (as you yourself write further down!), you'll be weighing the change against breaking compat.

It’s possible that issues would be discovered by the CSSWG community via a spec-text-only review, but that’s much more likely to happen when many developers are actively trying to make it work for their application using a real implementation.

I think you misread what I wrote, so let me quote it again, with some highlighting.

What's needed for Anchor Positioning at this time, and I was hoping we could get, is wide review on the revised design:

  • soliciting feedback from authors, to see if there are additional things to tweak for usability, additional use cases we can adjust to accommodate, or other points of difficulty we can resolve.
  • soliciting horizontal review at W3C, particularly wrt accessibility. (I think we handled most internationalization concerns in this last round, and don't anticipate much wrt privacy or security, but accessibility seems likely to turn up concerns.)
  • soliciting detailed review of the revised spec from CSSWG members, to ensure the details are completely, correctly, and reasonably specified, and the feature is self-coherent and integrates well with the rest of CSS.

    You're responding as if I only made the third point (CSSWG spec review), so let me number my points (so it's easier to pay attention to all of them), and break them down with action items that would implement each one:

    1. The revised design should get feedback from authors. For example by:
      1. Shipping your revised implementation in test builds so devs can try them out and
      2. Posting about the new model in your DevRel channels so they know about it and know to give feedback!
      3. Presenting at e.g. CSS Day, and ideally inviting feedback on an implementation the audience can test out and is excited about using soon, but is still possible to change in response to their feedback.
      4. Posting to the CSSWG blog about the revised spec and inviting feedback from authors (which wasn't done when the spec was republished in March).
      5. and any other channels that make sense.
    2. The feature should get horizontal review at W3C and especially address accessibility. This should include:
      1. Sending request to TAG, i18n, a11y, etc. in the appropriate channels.
      2. Documenting any accessibility concerns, intentions, and best practices in the spec, and addressing issues that come up.
      3. Preparing to teach and promote accessible use of this feature together with appropriate markup.
    3. The edited spec should get a last call review in the CSSWG.
      1. By sending a review request to the CSSWG/www-style noting the revisions that have landed and are ready to review, and, ideally, noting that Chrome intends to ship soon so that reviewers can prioritize accordingly.

    Requesting review after a feature has shipped in production is not very effective, since changes are constrained by compat.

    I think it's particularly important for this feature because the more open the design space, the more we need review; and a new layout model is one of the most open design spaces in the realm of CSS.

    I do believe we’ve been pretty actively soliciting feedback for the past two years as the feature was developed, and we’ve received some great feedback that helped shape the feature, particularly from Apple. Having said that, we plan to participate in the steps to get to CR over time.

    Yes, I acknowledge that; and you've gotten some great feedback from interested authors over those two years. But you haven't gotten that level of review on the feature after it was substantially redesigned, so the feature as you're planning to ship it hasn't had much, if any, review outside the CSSWG.

    Again, I’m glad you don’t anticipate major changes.

    I might not anticipate major changes, but I'm not the only person whose feedback you should be soliciting. If it was just about me, I could get a review done next week...

    And we fully expect to see minor breaking changes as the feature gets wider evaluation by developers. It would be natural to assume some reasonable such changes over the coming months, and Chrome will be open to such changes if they are compelling, even if they’re breaking.

    There's "breaking" in the sense of "the underlying behavior got tweaked a bit, and websites might change, and some sensitive ones might break"...

    And then there's "breaking" in the sense that "we tweaked the syntax again, and previous code is invalid" or "we changed default behavior, so most pages will change layout". These are minor changes from an implementation point of view, but they are not changes that are safe for a shipping implementation.

    (For additional context, my response here is prompted by a non-Apple, non-WebKit CSSWG member messaging me over the weekend and asking "isn't this a bit premature?" So it's not just me/Apple that has some lingering concerns. :)

    This is a very large feature, so there is bound to be some discomfort about shipping it, no matter when that shipment happens.

    Not true: when a feature is solidly specified and reviewed, we typically don't get this kind of reaction from the WG. Writing Modes, Grid Layout, Cascade Layers, there are many features in CSS where I don't recall such hesitancy.

    I do understand! But we’ve also received a significant number of developers commenting that they were very excited to see this feature finally shipping after all these years.

    Of course they are! It's solving a very real problem. They would have been excited even if you shipped off your first draft. But once that excitement wears off, you want them to still find the feature delightful to use 5-10 years later.

    Like Grid. We could have shipped off MSFT's first draft and authors would have been super excited. But I don't think we would have had the consistently positive reaction we have had to the much more developed and polished work that actually ended up shipping.

    In terms of scheduling, I think targetting the summer is better: Tab is giving a talk on Anchor Positioning at CSS Day, which I think is a great opportunity to present the full proposal and Chrome's implementation in its latest form and solicit feedback from advanced CSS authors, and there's a CSSWG F2F the following week during which we should be able to resolve any issues remaining or raised during wide review.

    I think you’re right that these venues will provide great opportunities to discuss the feature and talk about improvements.

    Improvements that you might not be able to incorporate because you are planning to ship before those opportunities!

    Indeed, there is a long list of css-anchor-position-2 issues that will provide discussion topics for many meetings to come, I’m sure.

    Level 2 enhancements is not the topic of this thread.

    On the topic of accessibility in particular....

    Are there particular issues you’re aware of? The only one I’m aware of is csswg-drafts/issues/9356 which talks about display and keyboard ordering.

    That's the main one I'm aware of, but again, you didn't submit for accessibility review...

    Incidentally, that’s an issue that applies to Grid and Flexbox already, and we’re actively working on a prototype implementation and spec proposal for `reading-order-items`. But as evidenced by that, even Grid/Flexbox aren’t fully “done” yet. Are there other a11y issues related to anchor pos? We’re not aware of any, but please do raise the ones you see.

    Grid and Flexbox were designed with accessibility in mind, with the reordering functionality introduced for the purpose of enhancing accessibility. The issue was debated multiple times, and their interaction with reading/tab order was 100% intentional and well-documented in the spec. They shipped working as intended, and authoring materials were able to incorporate best practices accordingly. The new `reading-order-items` feature is to support additional use cases. It's not there to "fix up" a broken accessibility model.

    Afaict, Anchor Positioning's accessibility story is simply fallout from how it happens to work. There's no documentation in the spec (or anywhere else afaict) of design rationale or intended AT behavior, its consequences, or how it's expected to be used by authors in a way that is accessibility-enhancing rather than accessibility-breaking.

    Your point about having the a11y story documented is a good one. We will make sure to include that story in blog posts, etc. If you have particular points to include, please do share.

    "We'll figure it out later" is not a satisfactory answer to "is this feature designed to support, rather than break, accessible layouts and if so how".

    ~fantasai

    Mason Freed

    unread,
    May 2, 2024, 4:44:25 PMMay 2
    to fantasai, blin...@chromium.org
    On Wed, May 1, 2024 at 10:04 AM fantasai <fantasa...@inkedblade.net> wrote:
    On 4/16/24 09:57, Mason Freed wrote:
    One thing to note is that we’re very committed to addressing any open issues, either now or after additional issues are discovered.

    You won't be as open to change after you ship, though, because then (as you yourself write further down!), you'll be weighing the change against breaking compat.

    I stand by what I said - we will definitely be open to well-justified changes after we ship! More inline below. 
    1. The revised design should get feedback from authors. For example by:
      1. Shipping your revised implementation in test builds so devs can try them out and
      2. Posting about the new model in your DevRel channels so they know about it and know to give feedback!
      3. Presenting at e.g. CSS Day, and ideally inviting feedback on an implementation the audience can test out and is excited about using soon, but is still possible to change in response to their feedback.
      4. Posting to the CSSWG blog about the revised spec and inviting feedback from authors (which wasn't done when the spec was republished in March).
      5. and any other channels that make sense.
    I (still) agree with this point. I believe we’ve done most all of these things over the last two years as we’ve been developing this feature. That’s why the feature is so cool at this point! We think it’s now time to expand the group of folks that can give feedback by shipping the initial version of this feature.
    1. The feature should get horizontal review at W3C and especially address accessibility. This should include:
      1. Sending request to TAG, i18n, a11y, etc. in the appropriate channels.
      2. Documenting any accessibility concerns, intentions, and best practices in the spec, and addressing issues that come up.
      3. Preparing to teach and promote accessible use of this feature together with appropriate markup.
    I agree. We’ve done some of that, but we’d be happy to have input on venues that we should additionally contact. We have forthcoming blog posts and documentation, and we’d welcome your input on those in case you think we can improve them in any way.
    1. The edited spec should get a last call review in the CSSWG.
      1. By sending a review request to the CSSWG/www-style noting the revisions that have landed and are ready to review, and, ideally, noting that Chrome intends to ship soon so that reviewers can prioritize accordingly.

    Ok, we will get this process started.

    Requesting review after a feature has shipped in production is not very effective, since changes are constrained by compat.

    I think it's particularly important for this feature because the more open the design space, the more we need review; and a new layout model is one of the most open design spaces in the realm of CSS.

    I do agree that shipped features are more constrained than unshipped ones. However, in the beginning stages of shipping a feature such as this, there is still opportunity to improve or tweak the design if needed.
    And we fully expect to see minor breaking changes as the feature gets wider evaluation by developers. It would be natural to assume some reasonable such changes over the coming months, and Chrome will be open to such changes if they are compelling, even if they’re breaking.

    There's "breaking" in the sense of "the underlying behavior got tweaked a bit, and websites might change, and some sensitive ones might break"...

    And then there's "breaking" in the sense that "we tweaked the syntax again, and previous code is invalid" or "we changed default behavior, so most pages will change layout". These are minor changes from an implementation point of view, but they are not changes that are safe for a shipping implementation.

    If we need to make such dramatic changes after shipping, then we’ll make them! Presumably, though, if we need to decide to do that, then the change must be extremely important and something in the design must have been fatally flawed. Given that we’ve been working with this feature for quite some time (yes with variations in syntax, but fairly consistently in functionality) my hope and assumption is that there aren’t any such fatal flaws in the design. However, if I’m wrong, we’re willing to take the pain of that change. We’d just hope that any such change is approached in the spirit of making developers' lives better, taken as a whole, including the pain of breakage.
    (For additional context, my response here is prompted by a non-Apple, non-WebKit CSSWG member messaging me over the weekend and asking "isn't this a bit premature?" So it's not just me/Apple that has some lingering concerns. :)

    This is a very large feature, so there is bound to be some discomfort about shipping it, no matter when that shipment happens.

    Not true: when a feature is solidly specified and reviewed, we typically don't get this kind of reaction from the WG. Writing Modes, Grid Layout, Cascade Layers, there are many features in CSS where I don't recall such hesitancy.

    I’m sure it’s true that when a feature has been reviewed for an extensive amount of time in the WG, it doesn’t get pushback from the WG. Though in that case we get the other kind of pushback, from developers, about why features take a glacially long time to be added to the web. I guess it’s a matter of striking the right balance between these two.

    I do understand! But we’ve also received a significant number of developers commenting that they were very excited to see this feature finally shipping after all these years.

    Of course they are! It's solving a very real problem. They would have been excited even if you shipped off your first draft. But once that excitement wears off, you want them to still find the feature delightful to use 5-10 years later.

    Like Grid. We could have shipped off MSFT's first draft and authors would have been super excited. But I don't think we would have had the consistently positive reaction we have had to the much more developed and polished work that actually ended up shipping.

    I think it’s a bit unfair to call this “shipping the first draft”. Again, we’ve been working through the nuances of this feature for more than 2 years, and this is hardly the first (or second or third) draft. I think the core feature is quite stable. 
    On the topic of accessibility in particular....

    Are there particular issues you’re aware of? The only one I’m aware of is csswg-drafts/issues/9356 which talks about display and keyboard ordering.

    That's the main one I'm aware of, but again, you didn't submit for accessibility review...

    Ok, let’s continue to work toward improved accessibility. We’ll submit officially for a11y review. 

    Afaict, Anchor Positioning's accessibility story is simply fallout from how it happens to work. There's no documentation in the spec (or anywhere else afaict) of design rationale or intended AT behavior, its consequences, or how it's expected to be used by authors in a way that is accessibility-enhancing rather than accessibility-breaking.

    This section of the anchor-pos spec talks about accessibility, and is similar in spirit and approach to the section that discusses the `order` property for grid/flex. We’d love specific feedback (other than csswg-drafts/issues/9356 where the discussion continues) on any other things we should address.

    Your point about having the a11y story documented is a good one. We will make sure to include that story in blog posts, etc. If you have particular points to include, please do share.

    "We'll figure it out later" is not a satisfactory answer to "is this feature designed to support, rather than break, accessible layouts and if so how".

    I don’t recall saying that, and I cannot find where I might have said “we’ll figure it out later” about any part of this feature, accessibility in particular. We’ve thought about accessibility (see issue 9356 for example), think the feature is ready as-is for an initial launch, and plan to enhance it over time with the features I’ve mentioned.

    Thanks,
    Mason

    ~fantasai

    --
    You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
    To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/jGTYNuidPRs/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.

    Florian Rivoal

    unread,
    May 2, 2024, 10:03:25 PMMay 2
    to blin...@chromium.org

    On 2024/05/03 5:43, Mason Freed wrote:
    > I stand by what I said - we will definitely be open to well-justified
    > changes after we ship! More inline below.

    Despite the best intents, the "well-justified" part of this is going to
    be a very quickly raising bar.

    The same intent was declared [1] about 'text-wrap: balance' not long
    ago, and shortly after it shipped we wanted to tweak it, and Chrome
    pushed back [2] because of compat concerns.

    The people who said then that shipping prior to spec stability was OK
    because making compat breaking changes would be fine if needed were
    sincere. But those who insisted that breaking compat was not worth it
    when we did find things we wanted to change were being reasonable.

    'text-wrap: balance' was a very simple feature, with low complexity, and
    limited impact in terms of potential for breakage. And yet we ended up
    being more constrained than we wished. Anchor positioning is way more
    complex of a feature, so the likelihood we'll discover something we want
    to change is higher, and the impact of potential breakage is higher too,
    since this is a layout feature.

    At the point where a number of sites will have started relying on this
    highly anticipated feature, making breaking changes will be pushed back
    against, with good reasons.

    [1] https://github.com/w3c/csswg-drafts/issues/9102#issuecomment-1649927288
    [2] https://github.com/w3c/csswg-drafts/issues/9102#issuecomment-1658998792

    On 2024/05/03 5:43, Mason Freed wrote:
    > Again, we’ve been working through the nuances of this feature for more
    > than 2 years, and this is hardly the first (or second or third) draft.
    > I think the core feature is quite stable.

    For a layout spec, 2 years is not especially long.

    Moreover, for about half of those 2 years, few people in the working
    group were fully engaged. That's unfortunate, but people's priorities
    cannot always shift quickly, even if they're interested. Fortunately,
    there's now been significant engagement, but that's still recent. Here's
    some imperfect but but illustrative evidence: out of 67 closed issues in
    GitHub, 8 were closed prior to May last year [3], while 59 were closed
    since then [4]. 47 of them were even closed in the last 3 months [5].
    That's absolutely evidence of good progress and engagement, but I
    wouldn't call that stability just yet.

    [3]
    https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+label%3Acss-anchor-position-1+is%3Aclosed+closed%3A%3C2023-05-01+
    [4]
    https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+label%3Acss-anchor-position-1+is%3Aclosed+closed%3A%3E2023-05-01+
    [5]
    https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+label%3Acss-anchor-position-1+is%3Aclosed+closed%3A%3E2024-02-03


    Now, the core concepts of the spec do seem stable at this point. But
    changes don't need to be to core concepts to be breaking.

    All in all, I support fantasai's position: an updated implementation in
    experimental features / beta builds, as well as giving the revised spec
    enough time to gather feedback from accessibility reviews and other
    horizontal groups like the TAG, from web developers after Tab presents
    at CSS-day and from beta builds, and from the WG itself now that the
    spec has been updated, seems appropriate.

    If the request was to wait for as many years as it took to ship Grid or
    Writing Modes, I would understand (and agree with) the desire to ship
    faster than that. But here I think we're only talking about a few more
    months, and for a feature of this magnitude, that seems worth it to
    ensure we don't lock ourselves into a few unfortunate shortcomings that
    could permanently limit its potential.

    —Florian

    Mason Freed

    unread,
    May 3, 2024, 2:55:29 PMMay 3
    to Florian Rivoal, blin...@chromium.org
    I'd just like to reiterate that we are open to making well-justified changes to the API shape over the next few months, as concerns arise. I think that the fact that we're shipping this API makes us more (not less) likely to a) surface the need for these changes, and b) prioritize them appropriately.

    Thanks,
    Mason

    --
    You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
    To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/jGTYNuidPRs/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.

    fantasai

    unread,
    May 12, 2024, 10:30:34 PM (6 days ago) May 12
    to blin...@chromium.org
    On 5/2/24 16:43, Mason Freed wrote:
    > On Wed, May 1, 2024 at 10:04 AM fantasai <fantasa...@inkedblade.net> wrote:
    >
    >> 1. The *revised design* should get feedback *from authors*. For example by:
    >> 1. Shipping your revised implementation in test builds so devs can
    >> try them out/and/
    >> 2. Posting about the new model in your DevRel channels so they know
    >> about it and know to give feedback!
    >> 3. Presenting at e.g. CSS Day, and ideally inviting feedback on an
    >> implementation the audience can test out and is excited about
    >> using soon, /but is still possible to change in response to their
    >> feedback./
    >> 4. Posting to the CSSWG blog about the revised spec and inviting
    >> feedback from authors (which wasn't done when the spec was
    >> republished in March).
    >> 5. and any other channels that make sense.
    >
    > I (still) agree with this point. I believe we’ve done most all of these things
    > over the last two years as we’ve been developing this feature.

    1. Not done.
    2. Completed 2 days ago.
    3. Not done.
    4. Not done.
    5. Unclear.

    "most of these things" is not true.

    > 1. The feature should get *horizontal review at W3C* and especially
    > *address accessibility*. This should include:
    > 1. Sending request to TAG, i18n, a11y, etc. in the appropriate
    > channels
    > <https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review>.
    > 2. Documenting any accessibility concerns, intentions, and best
    > practices in the spec, and addressing issues that come up.
    > 3. Preparing to teach and promote accessible use of this feature
    > together with appropriate markup.
    >
    > I agree. We’ve done some of that, but we’d be happy to have input on venues
    > that we should additionally contact.

    You still haven't done #1, even though I gave you the how-to link.

    > 1. The edited spec should get a *last call review in the CSSWG*.
    > 1. By sending a review request to the CSSWG/www-style noting the
    > revisions that /have landed/ and are ready to review, and,
    > ideally, noting that Chrome intends to ship soon so that reviewers
    > can prioritize accordingly.
    >
    > Ok, we will get this process started.

    What do you think is the "process" for this and why would you wait to start it
    until after you've already shipped?

    > If we need to make such dramatic changes after shipping, then we’ll make them!

    Great! I just spent my weekend reviewing the spec for you. Let's see how
    genuine your offer is.

    > I think it’s a bit unfair to call this “shipping the first draft”.

    I didn't call it one.

    Your responses in this thread are often not to what I've actually been
    writing. Please be less sloppy in your reading, it's kindof obnoxious.

    ~fantasai

    fantasai

    unread,
    May 12, 2024, 10:47:08 PM (6 days ago) May 12
    to blin...@chromium.org, Chris Harrelson, Alan Stearns
    On 4/15/24 01:55, fantasai wrote:
    > Speaking for myself only (not as Apple/WebKit), as an individual co-editor of
    > this spec--and from the perspective of having edited many layout specs
    > including Grid and Flexbox--I think Anchor Positioning is not quite ready to
    > ship (though I think it's pretty close).
    >
    > The spec just went through a significant overhaul, with major changes to
    > syntax, behavior, and interactions among various features. Typically after
    > such changes, a spec needs some time to settle, and also another round of
    > review to flush out additional issues and refine the new design. This is
    > particularly true for layout specs due to their complexity--both the inherent
    > complexity of the feature (we want to ensure it's fully coherent, even after
    > all the changes), as well as the complexity of how it gets used (we want to
    > ensure good usability for the various use cases).

    Here's a list of issues with breaking impact, as I warned was likely once the
    overhauled spec actually got a thorough review:

    - shorthanding relationship of 'position' and 'position-anchor'
    https://github.com/w3c/csswg-drafts/issues/10321

    - position: inset-area() syntax does not reflect CSSWG resolution
    https://github.com/w3c/csswg-drafts/issues/10320

    - revert-layer behavior is wrongly specified
    https://github.com/w3c/csswg-drafts/issues/10319

    - anchor-center alignment should not affect sizing
    https://github.com/w3c/csswg-drafts/issues/10315

    - resolution of 'inset' percentages for multi-track 'inset-area'
    https://github.com/w3c/csswg-drafts/issues/10314

    - default alignments for inset areas are wrong
    https://github.com/w3c/csswg-drafts/issues/10313

    - initial value of 'position-anchor' should be 'auto' not 'implicit'

    Like I said, you can't redesign a spec and expect not to have follow-up
    issues. The revised spec was published on the 26th of March; you didn't leave
    *any* time for review before deciding to ship.

    ~fantasai

    Mike Taylor

    unread,
    May 13, 2024, 10:53:11 AM (6 days ago) May 13
    to fantasai, blink-dev
    I appreciate that this is an important discussion to you and others, but
    it would be good to turn the temperature down on comments like this. We
    like to keep things respectful and constructive on this list (as you
    have in other replies).

    thanks,
    Mike

    Alan Stearns

    unread,
    May 13, 2024, 12:41:14 PM (6 days ago) May 13
    to blink-dev, fantasa...@inkedblade.net, chri...@google.com, Alan Stearns
    Mason, Chris,

    (speaking as the CSSWG co-chair)

    Please prioritize responding to each of these issues.

    Thanks,

    Alan

    Mason Freed

    unread,
    May 13, 2024, 3:06:16 PM (5 days ago) May 13
    to blink-dev, fantasai
    First, I’d just like to correct the record, for the benefit of the folks who have been working for years on this feature (including lots of outreach), and for everyone following this discussion:

    • This feature has been in development since May, 2022, and available for developer trials in Chrome since August, 2022. We have been continuously shipping the feature experimentally for developers to try out, including all revisions, since then. We’ve gathered a significant amount of developer feedback, much of which is public. Four such bits of feedback are listed in the “Dev trial” section of the chromestatus entry