Web-Facing Change PSA: Rename position-try-options to position-try-fallbacks

17 views
Skip to first unread message

Mason Freed

unread,
Jul 1, 2024, 6:38:50 PM (10 hours ago) Jul 1
to blink-dev

Contact emails

mas...@chromium.org, and...@chromium.org

Specification

https://github.com/w3c/csswg-drafts/issues/10395#issuecomment-2192127524

Summary

The CSSWG resolved to rename this property, because "fallbacks" more accurately describes what this property controls. The word "options" is a bit deceiving, since the styles outside of `position-try` blocks will be tested first, and if they result in a layout that fits within the containing block, none of the "options" will get used. So "fallbacks" is a better word to describe this behavior. https://github.com/w3c/csswg-drafts/issues/10395#issuecomment-2192127524



Blink component

Blink>CSS

Search tags

anchor positioning

TAG review

None

TAG review status

Not applicable

Risks



Interoperability and Compatibility

This is a name change, which will result in the old name no longer functioning. So there is a risk of breakage. However, the anchor positioning feature was very recently shipped, and does not have implementation in other browsers. So we feel the risk is quite small currently, but will grow over time. Given that, we'd like to rename this property ASAP to avoid the risk getting too large. The use counter is currently quite low, around 0.01% in June: https://chromestatus.com/metrics/css/timeline/popularity/784 An HTTP Archive search was performed, which showed that almost all usage comes from one Shopify CSS file (`spec-and-compare.css`), and we intend to reach out to Shopify (or hope for a response from one very special Blink API owner) to make sure this will not break Shopify.



Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

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?

None



Debuggability

None



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

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://crbug.com/349600667

Estimated milestones

Shipping on desktop128
Shipping on Android128
Shipping on WebView128


Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5167414571696128?gate=5182169462079488

This intent message was generated by Chrome Platform Status.

Yoav Weiss (@Shopify)

unread,
2:48 AM (2 hours ago) 2:48 AM
to blink-dev, Mason Freed


On Tuesday, July 2, 2024 at 12:38:50 AM UTC+2 Mason Freed wrote:
Summary

The CSSWG resolved to rename this property, because "fallbacks" more accurately describes what this property controls. The word "options" is a bit deceiving, since the styles outside of `position-try` blocks will be tested first, and if they result in a layout that fits within the containing block, none of the "options" will get used. So "fallbacks" is a better word to describe this behavior. https://github.com/w3c/csswg-drafts/issues/10395#issuecomment-2192127524



Blink componentBlink>CSS

Search tagsanchor positioning

TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

This is a name change, which will result in the old name no longer functioning. So there is a risk of breakage. However, the anchor positioning feature was very recently shipped, and does not have implementation in other browsers. So we feel the risk is quite small currently, but will grow over time. Given that, we'd like to rename this property ASAP to avoid the risk getting too large. The use counter is currently quite low, around 0.01% in June: https://chromestatus.com/metrics/css/timeline/popularity/784 An HTTP Archive search was performed, which showed that almost all usage comes from one Shopify CSS file (`spec-and-compare.css`), and we intend to reach out to Shopify (or hope for a response from one very special Blink API owner) to make sure this will not break Shopify.


"very special" :)

It seems like the source of usage is this 3P app: https://apps.shopify.com/spec-compare
I'll send you their contact email so that you can reach out to them directly.

Can you share the HTTP Archive analysis? Manual inspection of the hosts listed in the chromestatus counter didn't reveal much on my end.

Beyond that, I think this would require an intent and maybe a short deprecation period. Even if the only source is this single app, unless the breakage is insignificant, we'd need at least one release overlap between the new and the old values, to avoid a breakage period while users are upgrading from Chromium N to N+1.



Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

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?

None



Debuggability

None



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://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://crbug.com/349600667

Estimated milestonesShipping on desktop128Shipping on Android128Shipping on WebView128

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Reply all
Reply to author
Forward
0 new messages