Re: [csswg-drafts] [css-anchor-1] More declarative syntax for simple cases (#7757)

The CSS Working Group just discussed `Declarative anchor fallback positioning`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: Declarative anchor fallback positioning<br>
&lt;TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7757<br>
&lt;fantasai> TabAtkins: At previous meeting when introduced anchor positioning<br>
&lt;fantasai> TabAtkins: Emilio brought up that XUL had similar functionality, and had a simple declarative way to express fallbacks<br>
&lt;fantasai> TabAtkins: This is good, current fallback is very complex<br>
&lt;fantasai> TabAtkins: I have a proposal in this thread for solving that<br>
&lt;fantasai> TabAtkins: Can still use full complex positioning if necessary, but this should solve common cases<br>
&lt;fantasai> TabAtkins: Not looking for resolution right now, just wanted to get attention for review and comment<br>
&lt;fantasai> iank_: Can you briefly describe this mode?<br>
&lt;fantasai> TabAtkins: The way you opt into it, rather than declaring a side to align to in the anchor<br>
&lt;fantasai> TabAtkins: Instead you say "auto", and it will automatically choose the opposite side of the property you're setting<br>
&lt;fantasai> TabAtkins: but if you would trigger fallback positioning, we flip around<br>
&lt;fantasai> TabAtkins: and align your bototm edge to the top edge<br>
&lt;fantasai> TabAtkins: so we can do this positoining without affecting layout<br>
&lt;fantasai> TabAtkins: then if neither works, we go to normal fallback rules<br>
&lt;fantasai> iank_: idk that you need auto on opposite side<br>
&lt;fantasai> iank_: how does this interact with maximum number of fallbacks?<br>
&lt;fantasai> TabAtkins: need auto on other side because if not, there's nothing to fall back to<br>
&lt;fantasai> TabAtkins: If you specify this for your top property, we can't switch to using bottom if your bottom is zero<br>
&lt;fantasai> iank_: ok<br>
&lt;fantasai> TabAtkins: wrt maximums, this will be part of that list<br>
&lt;fantasai> TabAtkins: effectively position fallback will have an extra entry, so this will be factored into that maximum<br>
&lt;fremy> q+<br>
&lt;fantasai> iank_: does this mean you need to set on both insets?<br>
&lt;fantasai> TabAtkins: no, set one to anchor and the other to auto<br>
&lt;fantasai> TabAtkins: it will be naturally sized<br>
&lt;fantasai> TabAtkins: we'll swap the properties if we need to for fallback reasons<br>
&lt;fantasai> [note that auto is the initial value]<br>
&lt;fantasai> iank_: You can embed an anchor inside of a calc() expression<br>
&lt;fantasai> iank_: so if you're not using the ?? anchor, what does that calc expression resolve to?<br>
&lt;fantasai> TabAtkins: after doing the flip?<br>
&lt;fantasai> TabAtkins: it resolves to the appropriate other edge<br>
&lt;fantasai> TabAtkins: Luckily because insets are specified in opposite directions<br>
&lt;Rossen_> ack dbaron<br>
&lt;fantasai> TabAtkins: if you use calc() to put you 10px from bottom edge, that same calc will work against the top<br>
&lt;fantasai> iank_: so you're taking the whole calc() and putting it in the other property, and the other property becomes auto?<br>
&lt;fantasai> TabAtkins: yes, we resolve exactly as if you'd done it on the other side<br>
&lt;fantasai> TabAtkins: just as position fallback already works, but we make it automatic for obvious placement<br>
&lt;fantasai> iank_: sounds fine, just concerned about magical swapping of computed values at layout time<br>
&lt;fantasai> TabAtkins: This is exactly position fallback, the same feature, we're just giving you one for free<br>
&lt;fantasai> iank_: not exactly, because you're taking e.g. top is auto, bottom is calc expression with anchor<br>
&lt;fantasai> iank_: the position fallback then is like the top becomes that calc function and bottom becomes auto<br>
&lt;fantasai> iank_: oh, and I see, you're saying that this will automatically populate a fallback position entry with those two things<br>
&lt;fantasai> iank_: okay, that makes sense<br>
&lt;fantasai> iank_: if you can write that as a note, this is how it should be implemented, that would be helpful<br>
&lt;fantasai> fremy: Small question<br>
&lt;fantasai> fremy: because I believe this would be common<br>
&lt;fantasai> fremy: what happens if you do it for top and left, and if so what happens?<br>
&lt;fantasai> TabAtkins: what exactly will happen is a great question, which I have not thought through the implications of!<br>
&lt;fantasai> TabAtkins: I don't have an answer for you yet.<br>
&lt;fantasai> TabAtkins: I don't think it's hugely important what the answer is... worst case maybe generate 3 fallbacks, generating vertical flip, horizontal flip, or both<br>
&lt;fantasai> TabAtkins: will think about it<br>
&lt;iank_> likely want the flips in the logical space vs the physical?<br>
&lt;fantasai> fremy: I guess maybe we can check what tooltips do on iOS/MacOS/Windows<br>
&lt;iank_> block flip vs. vertical flip<br>
&lt;fantasai> +1 iank<br>
&lt;Rossen_> ack fremy<br>
&lt;fantasai> TabAtkins: just wanted to get feedback, this was helpful<br>
&lt;TabAtkins> well, doesn't matter, point is you flip to the opposite side of wherever it's specified<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7757#issuecomment-1325435717 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 23 November 2022 17:36:32 UTC