On Thursday, April 11, 2024 at 7:58:18 PM UTC-7 [email protected] 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 <https://github.com/w3ctag/design-reviews/issues/848>, 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 <https://github.com/w3ctag/design-reviews/issues/848#issuecomment-2005169512> 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 -- Dan On Thursday, April 11, 2024 at 4:04:02 PM UTC-7 [email protected] wrote: Contact emails *[email protected]* Explainer *https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CSSAnchoredPositioning/explainer.md <https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CSSAnchoredPositioning/explainer.md>https://xiaochengh.github.io/Explainers/css-anchor-position/explainer.html <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://developer.chrome.com/blog/tether-elements-to-each-other-with-css-anchor-positioning>https://12daysofweb.dev/2023/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 <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 <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 <https://www.w3.org/TR/css-align-3/#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 <https://wpt.fyi/results/css/css-anchor-position?label=experimental&label=master&aligned>. 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 <https://github.com/w3c/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 <http://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 <https://github.com/w3c/csswg-drafts/issues/10184> has recently been resolved, so we will implement the resolved behavior. We are tracking this in crbug.com/333443429 <http://crbug.com/333443429>.- The `anchor-scope` CSS property is not yet implemented. We are tracking that in crbug.com/40281992 <http://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 <http://crbug.com/331841274>.- There is a discussion about expanding `anchor-size()` to be allowed in more properties (csswg-drafts/issues/9827 <https://github.com/w3c/csswg-drafts/issues/9827>) and once that gets resolved, we will implement the resolved behavior. We are tracking this in crbug.com/333421962 <http://crbug.com/333421962>.- There is a discussion (csswg-drafts/issues/10182 <https://github.com/w3c/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 <http://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 <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELayout>*Search tags *css <https://chromestatus.com/features#tags:css>, anchor <https://chromestatus.com/features#tags:anchor>, position <https://chromestatus.com/features#tags:position>*TAG review *https://github.com/w3ctag/design-reviews/issues/848 <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 <https://github.com/mozilla/standards-positions/issues/794>)WebKit: No signal (https://github.com/WebKit/standards-positions/issues/167 <https://github.com/WebKit/standards-positions/issues/167>)Web developers: Strongly positive (https://crbug.com/40059176 <https://issues.chromium.org/issues/40059176> has 37 stars)Lots of excited developer blog posts: - https://kizu.dev/anchor-positioning-experiments/ <https://kizu.dev/anchor-positioning-experiments/>- https://12daysofweb.dev/2023/anchor-positioning/ <https://12daysofweb.dev/2023/anchor-positioning/>- https://blog.logrocket.com/use-css-anchor-positioning/ <https://blog.logrocket.com/use-css-anchor-positioning/>- https://frontendmasters.com/blog/drawing-a-line-to-connect-elements-with-css-anchor-positioning/ <https://frontendmasters.com/blog/drawing-a-line-to-connect-elements-with-css-anchor-positioning/>- https://medium.com/@shriyanspranaybuisness/css-anchor-positioning-ec9f861f4498 <https://medium.com/@shriyanspranaybuisness/css-anchor-positioning-ec9f861f4498>- …and many more*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 <https://github.com/oddbird/css-anchor-positioning> for some features (see the Limitations section in the linked document), but it may not be up-to-date with the latest syntax changes. <https://github.com/oddbird/css-anchor-positioning>There are also a few quite common libraries that do "anchor positioning" in userspace, e.g. popper.js <https://popper.js.org/docs/v2/> / floating-ui <https://floating-ui.com/>. 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? *Yeshttps://wpt.fyi/results/css/css-anchor-position <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 <https://issues.chromium.org/issues/40059176>*Measurement *https://chromestatus.com/metrics/feature/timeline/popularity/4467 <https://chromestatus.com/metrics/feature/timeline/popularity/4467>*Sample linkshttps://anchor-tool.com Estimated milestones *Shipping on desktop: 125DevTrial on desktop: 104Shipping on Android: 125DevTrial on Android: 104Shipping 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 <https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+is%3Aopen+label%3Acss-anchor-position-1>, 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 <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 <https://chromestatus.com/> {and edited to provide more context}. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/491e36ec-58fb-40e2-906d-4ecc97e6d99an%40chromium.org.
