Intent to Ship: CSS Anchor Positioning
Mason Freed
Contact emails
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
Search tags
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:
https://frontendmasters.com/blog/drawing-a-line-to-connect-elements-with-css-anchor-positioning/
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 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
Mason Freed
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?
Sample linkshttps://anchor-tool.com
fantasai
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.
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.
~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
More inline:
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).
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.
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.
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
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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.
--
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
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
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.
--
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.
--
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.
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.
Mason Freed
Daniel Herr
Domenic Denicola
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e5f7b2c0-69d0-4fdb-abc7-be25dd2569adn%40chromium.org.
Mason Freed
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?
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?
fantasai
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:
- The revised design should get feedback from
authors. For example by:
- Shipping your revised implementation in test builds so devs
can try them out and
- Posting about the new model in your DevRel channels so they know about it and know to give feedback!
- 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.
- 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).
- and any other channels that make sense.
- The feature should get horizontal review at W3C and
especially address accessibility. This should include:
- Sending request to TAG, i18n, a11y, etc. in the appropriate channels.
- Documenting any accessibility concerns, intentions, and best
practices in the spec, and addressing issues that come up.
- Preparing to teach and promote accessible use of this
feature together with appropriate markup.
- The edited spec should get a last call review in the CSSWG.
- 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
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.
- The revised design should get feedback from authors. For example by:
- Shipping your revised implementation in test builds so devs can try them out and
- Posting about the new model in your DevRel channels so they know about it and know to give feedback!
- 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.
- 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).
- and any other channels that make sense.
- The feature should get horizontal review at W3C and especially address accessibility. This should include:
- Sending request to TAG, i18n, a11y, etc. in the appropriate channels.
- Documenting any accessibility concerns, intentions, and best practices in the spec, and addressing issues that come up.
- Preparing to teach and promote accessible use of this feature together with appropriate markup.
- The edited spec should get a last call review in the CSSWG.
- 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.
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.
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...
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".
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cd946af0-820e-4142-8914-db07a1805979%40inkedblade.net.
Florian Rivoal
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.
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.
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
--
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/bad5411e-814f-478a-9071-971cce1d3232%40rivoal.net.
fantasai
> On Wed, May 1, 2024 at 10:04 AM fantasai <fantasa...@inkedblade.net> wrote:
>
>> 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
>> feedback./
>> 4. Posting to the CSSWG blog about the revised spec and inviting
>> republished in March).
> 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.
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
>
> I agree. We’ve done some of that, but we’d be happy to have input on venues
> that we should additionally contact.
> 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,
> can prioritize accordingly.
>
> Ok, we will get this process started.
until after you've already shipped?
> If we need to make such dramatic changes after shipping, then we’ll make them!
genuine your offer is.
> I think it’s a bit unfair to call this “shipping the first draft”.
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
> 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).
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
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
Please prioritize responding to each of these issues.
Thanks,
Mason Freed
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 attached to my initial post here.
The blog post we published last week is not the first. We’ve been posting about this feature for a while now, starting with a teaser in May 2022, and then our first full blog post in March 2023. Our devrel team has spoken about it at dozens of developer conferences and venues, including CSS Day 2023, and has been gathering tons of valuable developer feedback (both publicly and privately) along the way. (The CSSWG blog appears to be just a list of meeting minutes?)
I have been reading your posts very carefully, and spending significant time writing responses. I’d appreciate you assuming my good faith in these responses.
Second, thank you for reviewing the spec and raising some great issues. We are looking through those now - let’s discuss each of them on the issues instead of here. From our initial review, it looks like they can be addressed, and we are committed to adjusting this feature as needed to make sure it works for developers. That applies to these issues as well.
Thanks,
Mason