Thank you all! I really appreciate the feedback and support. Thanks, Mason
On Tue, Apr 16, 2024 at 12:05 PM Rick Byers <rby...@chromium.org> wrote: > 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 > <https://docs.google.com/document/d/1xkHRXnFS8GDqZi7E0SSbR3a7CZsGScdxPUWBsNgo-oo/edit> > 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 > > On Tue, Apr 16, 2024 at 11:34 AM Mike Taylor <miketa...@chromium.org> > wrote: > >> 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. >> On 4/16/24 1:58 PM, Alex Russell wrote: >> >> 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 <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/4b163fec-0afb-436e-af2c-7a3651ae0951n%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4b163fec-0afb-436e-af2c-7a3651ae0951n%40chromium.org?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/6b9dd254-be2c-4154-871f-4b69de6fb78a%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6b9dd254-be2c-4154-871f-4b69de6fb78a%40chromium.org?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%3DNeDjEL6F46E1xhzQu2Yrq_YMk9Ke0fy0HybyX%2BtwY7C0bbQ%40mail.gmail.com.
