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
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.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
None
https://wpt.fyi/results/css/css-anchor-position
Shipping on desktop | 128 |
DevTrial on desktop | 128 |
Shipping on Android | 128 |
DevTrial on Android | 128 |
Shipping on WebView | 128 |
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