LGTM1. Excited to see this ship! On Monday, April 15, 2024 at 5:57:40 PM UTC-7 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. > > More inline: > > On Sun, Apr 14, 2024 at 10:56 PM fantasai <[email protected]> > 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 >> >> >> * [email protected] <[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> >> ? >> >> >> >> * 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 [email protected]. >> 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 >> [email protected]. >> 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 [email protected]. 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.
