You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're getting the style queries that allow us to query styles of some pre-defined containers.
In my experiments I often wanted not to use the values of the anchors immediately, but to base some other styles based on the current state of the anchors, especially if we could query multiple anchors and compare their positions/dimensions.
Given the current acceptance criteria kinda guarantees that the anchored element is ~independent of the given anchor, I wonder if some part of this could be used in a way similar with style queries?
Main use-case where this could be used in my experiments — the case where currently we have to use the “four quadrants” technique (https://kizu.dev/anchor-positioning-experiments/#the-technique-itself) — this method is more of a hack, but if we could directly compare the offsets of two anchors, then we could switch things up for our single positioned element which would also have its coordinates using min() (that already works, but without an actual ability to know which coordinate is bigger we cannot do anything else).
Maybe this can be worked around without adding a special anchor-query syntax by allowing using the anchor() and anchor-size() for other properties, but that would mostly lead to having some hacky calculations like
So, having a proper at-rule here would be really-really cool.
I would create a different issue for using the anchor values for other properties though, as I think it is still helpful, just not exactly for the purpose described in this issue.
Probably related issue about hiding the popovers when they're offscreen — #7758 — I imagine with a certain combination of rules involving the viewport and the offsets it could be possible to detect the conditions for this use case?
The text was updated successfully, but these errors were encountered:
Disclaimer and additional links
I'm submitting my feedback following my experiments with the current implementation of anchor positioning in Chrome Canary.
I wrote an article about my experiments, but decided to fill most of my feedback as separate issues here.
A quick summary of related links:
We're getting the style queries that allow us to query styles of some pre-defined containers.
In my experiments I often wanted not to use the values of the anchors immediately, but to base some other styles based on the current state of the anchors, especially if we could query multiple anchors and compare their positions/dimensions.
Given the current acceptance criteria kinda guarantees that the anchored element is ~independent of the given anchor, I wonder if some part of this could be used in a way similar with style queries?
Main use-case where this could be used in my experiments — the case where currently we have to use the “four quadrants” technique (https://kizu.dev/anchor-positioning-experiments/#the-technique-itself) — this method is more of a hack, but if we could directly compare the offsets of two anchors, then we could switch things up for our single positioned element which would also have its coordinates using
min()
(that already works, but without an actual ability to know which coordinate is bigger we cannot do anything else).Maybe this can be worked around without adding a special anchor-query syntax by allowing using the
anchor()
andanchor-size()
for other properties, but that would mostly lead to having some hacky calculations likeand won't work for non-numeric values.
So, having a proper at-rule here would be really-really cool.
I would create a different issue for using the anchor values for other properties though, as I think it is still helpful, just not exactly for the purpose described in this issue.
Probably related issue about hiding the popovers when they're offscreen — #7758 — I imagine with a certain combination of rules involving the viewport and the offsets it could be possible to detect the conditions for this use case?
The text was updated successfully, but these errors were encountered: