- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 11 Jun 2025 16:23:39 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor] Detecting active @position-fallback`.
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> futhark<br>
<JoshT> futhark: we can have fallback positions with @position rules<br>
<JoshT> ... to position based on available space<br>
<JoshT> ... there is desire to style differently based on which fallback is chosen<br>
<JoshT> ... to do so with container queries<br>
<JoshT> ... I have made an explainer. got positive feedback from the TAG<br>
<JoshT> ... the next step is to get a resolution and feedback. resolve to work on it?<br>
<JoshT> ... and to what level to add it to?<br>
<astearns> ack fantasai<br>
<JoshT> fantasai: this is super needed. I think concerned from usability PoV, fallbacks being numbered is not great<br>
<JoshT> futhark: explainer came to a different conclusion. chrome impl uses numbers for simplicity<br>
<lea> What if we name them? `@try top { ... } @try bottom { ... }` etc<br>
<JoshT> fantasai: for position-area values, I think we want to ask 'are you in this mode or the other mode'. relative to the position.<br>
<lea> q?<br>
<lea> q+<br>
<JoshT> ... so if my dropdown is in the top and then bottom, I don't want to index to what order it's in<br>
<JoshT> ... with position-area, you've got the mapping with logical and physical<br>
<emilio> Is it well defined what happens if you do cycles? Or does the new anchor type also imply size containment or so?<br>
<JoshT> ... you want to say if it's inline-start, I want to query if it's left or right<br>
<JoshT> futhark: we discussed should we map to try and names. if we map to position-area, should it match a query for position-area<br>
<lea> q-<br>
<JoshT> fantasai: I think we should query not the fallback, but the region. map between logical and physical, or the name of a position try<br>
<JoshT> ... and then you could add a flip block or flip inline<br>
<JoshT> ... and that would be easier to use and get you what you want: to query the physical location<br>
<JoshT> astearns: could you have more than one fallback in a particular direction<br>
<JoshT> fantasai: you query which one is active<br>
<lea> q+<br>
<JoshT> ... together if you have four items to try, I can query the same way the first and the third position. I think it should be queried based on details of the position<br>
<JoshT> ... like anchor area colon, position: block-start, if i have specified that or the fallback, whatever that is<br>
<JoshT> ... the position try values would be their own named custom srea<br>
<miriam> q+<br>
<astearns> ack lea<br>
<JoshT> ... that's why I use the name of the position try rule<br>
<JoshT> lea: are there any more use cases than arrows?<br>
<JoshT> ... do you just need to know where the element is positioned?<br>
<TabAtkins> q+<br>
<JoshT> ... what you really want is how the element is positioned<br>
<JoshT> ... otherwise it's too specific to anchor positioning<br>
<JoshT> ... we should look at the ergonomics of how we make the arrows. with this API, what does it look like to make arrows? it might look awkward<br>
<JoshT> miriam: I'm curious about the details, whether it involves containment, but I can take it to an issues<br>
<astearns> ack miriam<br>
<JoshT> futhark: we need style containment for counters.<br>
<astearns> ack TabAtkins<br>
<JoshT> TabAtkins: response to lea. needs to be tied to position try because you don't know where the thing you're putting the arrow on is<br>
<JoshT> ... for a tooltip, that needs to be flush<br>
<astearns> ack fantasai<br>
<JoshT> ... needs to be tied to the styles used. could experiment for other stuff. but for this use case, this design is what's required<br>
<JoshT> fantasai: I think this proposal connects really well with the teather proposal<br>
<JoshT> ... to make them easier to do<br>
<lea> Makes sense. Speaking of use cases, there's also transitions: you want a different transition depending on relative position (e.g. growing from the top or from the bottom)<br>
<fantasai> s/teather/tether/<br>
<JoshT> astearns: we can open up issues to discuss these things. can we wait until we've discussed the things that come up in the ussues<br>
<lea> q+<br>
<lea> q-<br>
<JoshT> fantasai: should go in anchor-positioning-2.<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8171#issuecomment-2963456372 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 June 2025 16:23:39 UTC