feat(react-headless-components-preview): adopt anchored container queries for arrow placement#36112
Conversation
📊 Bundle size report
🤖 This report was generated against 0307f02ca1bc383b15fca2c2dc62ba2113fd7c5f |
|
Pull request demo site: URL |
25dee94 to
f815971
Compare
refactor(headless-popover): refactor implementation
f815971 to
1bd5814
Compare
c18c393 to
3550016
Compare
3550016 to
c11b03b
Compare
|
|
||
| if (win && supportsAnchoredContainerQueries(win)) { | ||
| // Chrome 143+: opt into `@container anchored(fallback: …)` queries. | ||
| node.style.setProperty('container-type', 'anchored'); |
There was a problem hiding this comment.
There was a problem hiding this comment.
we need to be careful with this, as it doesn't remove some JS from the bundle,
and what is more important, consumers have to write two versions of styles, as there is no data-placement attribute when the @container anchored(fallback: …) branch is active
There was a problem hiding this comment.
Addressed in the latest push:
data-placementis now always written (in both branches of thesupportsAnchoredContainerQueries(win)check). Consumers can author a single set of[data-placement="…"]rules that works everywhere.@container anchored(fallback: …)becomes a pure override layer that only flips the arrow when the browser actually activates aposition-try-fallback. The duplicated[data-position]/[data-align]rule set inpopover.module.cssis gone.- On the JS-bundle concern: the observer still has to run on browsers without anchored container queries, so it stays in the bundle. The split into a separate PR (this one) is exactly so we can keep discussing whether the CSS-only path is worth the trade-off.
The refactor changes you LGTM'd are now in #36192.
dmytrokirpa
left a comment
There was a problem hiding this comment.
LGTM, except container queries, can we separate move that change to a separate PR, as we'll probably need more feedback on the idea
|
|
||
| if (win && supportsAnchoredContainerQueries(win)) { | ||
| // Chrome 143+: opt into `@container anchored(fallback: …)` queries. | ||
| node.style.setProperty('container-type', 'anchored'); |
There was a problem hiding this comment.
we need to be careful with this, as it doesn't remove some JS from the bundle,
and what is more important, consumers have to write two versions of styles, as there is no data-placement attribute when the @container anchored(fallback: …) branch is active
Address review feedback on microsoft#36112: when container-type: anchored is supported, data-placement was being removed, forcing consumers to author two parallel rule sets (one keyed on [data-placement], one on [data-position]+[data-align] inside @supports). Now data-placement is always written, so the base [data-placement] rules work everywhere and @container anchored(fallback: …) becomes a pure override layer for new browsers.
c11b03b to
b1ca4c5
Compare
b1ca4c5 to
d6768ac
Compare

Supports the JS-driven
data-placementattribute as source of truth for popover-arrow styling with a CSS-native solution based on Chrome 143+'s anchored container queries (container-type: anchored+@container anchored(fallback: …)). The placement-observer still runs on older Chromium so arrow direction stays correct on older versions.