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 <fantasai.li...@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 <https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+is%3Aopen+label%3Acss-anchor-position-2> 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 <https://github.com/w3c/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 > On 4/12/24 08:03, Mason Freed wrote: > > Contact emails > > > * mas...@chromium.org <mas...@chromium.org> * 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> > ? > > > > * Yes https://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 > 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 > <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 blink-dev+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgGMzSh43dYk486vdsWZG0upxwzqw%3DpiL16pCz-Wh0Acw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- > 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+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7fe37aa5-7cf4-40f8-9581-f12ff0817caf%40inkedblade.net?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDiMzooRCLBM4%3DJP2Zw1%3D44RVeNS%3DnjEvJc32SO0GNUuog%40mail.gmail.com.
