Re: [csswg-drafts] [css-anchor-position-1] Alternative syntax for auto position fallback (#9196)

The CSS Working Group just discussed `[css-anchor-position-1] Alternative syntax for auto position fallback`, and agreed to the following:

* ``RESOLVED: adopt `position-try-*` with addition of inset-area into pos-try-opts``

<details><summary>The full IRC log of that discussion</summary>
&lt;astearns> zakim, open queue<br>
&lt;Zakim> ok, astearns, the speaker queue is open<br>
&lt;bramus> TabAtkins: we had resolution to figure out details but do sth better for auto fallback<br>
&lt;bramus> … we figured out the details (elika and I)<br>
&lt;bramus> … want to hear about objections and opinions<br>
&lt;bramus> … first, instead of single keyword in pos fallback prop that points to multiple try blocks we now have list of keywords in pos-try-options<br>
&lt;dbaron> [insert whiteboard photo PXL_20240213_181237761.jpg at the end of the previous topic]<br>
&lt;bramus> florian: this is flipping between options on the inset area and that only or on more things?<br>
&lt;bramus> TabAtkins: more; 5 sets of props: inset-area, insets, margins, and sizing props, and alignment<br>
&lt;bramus> … old way: `@position-fallback --foo { @try { … } @try { … } @try { … } … }`<br>
&lt;bramus> … we would go through list 1 by 1<br>
&lt;bramus> … hard to reuse<br>
&lt;bramus> … too much indirection<br>
&lt;fantasai> ... not clear how the automatically-generated fallbacks were interleaved<br>
&lt;bramus> … new way: `@position-try --name { (styles) }`<br>
&lt;bramus> … you make more than 1<br>
&lt;bramus> … put them in `pos-try-options`<br>
&lt;bramus> … `pos-try-options: --one, --two, …`<br>
&lt;bramus> … it goes through each 1 by 1 until 1 is good<br>
&lt;bramus> … also takes keywords, e.g. “flip me in the block axis”<br>
&lt;bramus> … can be combined with custom options<br>
&lt;florian> q?<br>
&lt;florian> q+<br>
&lt;astearns> ack florian<br>
&lt;nicole> q+<br>
&lt;bramus> florian: if you flip to 1 of th efallbacks tha tchagnes the computed values?<br>
&lt;bramus> TabAtkins: yes<br>
&lt;vmpstr> q+<br>
&lt;bramus> florian: in the apple proposal there wasnt this?<br>
&lt;bramus> TabAtkins: they only had ability to change `inset-area`<br>
&lt;bramus> fantasai: now has its own property<br>
&lt;bramus> … like jen pointed out: if you are using inset-area then there is a lot of code you need to write. you could also say inset-area<br>
&lt;fantasai> as part of the list<br>
&lt;fantasai> i.e. position-try-options: [ &lt;dashed-ident> | &lt;try-tactic> | &lt;'inset-area'> ]#<br>
&lt;miriam> +1 to the inset-area extension<br>
&lt;bramus> chrishtr: so this ia future extension?<br>
&lt;bramus> TabAtkins: yes<br>
&lt;astearns> ack nicole<br>
&lt;astearns> q+<br>
&lt;bramus> nsull: like the naming them and comma separated list. could see in a  design system this getting set up and having indiv componetns use them in different orders.<br>
&lt;bramus> … good for reuse<br>
&lt;bramus> +1<br>
&lt;florian> q+<br>
&lt;bramus> nsull: be pretty cool indeed. getting rid of the try blocks is good. felt clunky.<br>
&lt;astearns> ack vmpstr<br>
&lt;bramus> vmpstr: what do the flip keywords refer to? --fo and then flip-block? do I flip the block of the foo?<br>
&lt;dbaron> [whiteboard erased without photo]<br>
&lt;bramus> TabAtkins: say base style was `inset-area: bottom`<br>
&lt;bramus> … will put you below anchor<br>
&lt;bramus> … now `@position-try --top { inset-area: top}`<br>
&lt;bramus> then `@postion-try --left { i-a: left }`<br>
&lt;bramus> … `.popup { pos-try-options: --top, --left }`<br>
&lt;bramus> … or could also say `flip-block` as the value<br>
&lt;bramus> fantasai: this is more insteresting when you are doing things other than inset area<br>
&lt;bramus> TabAtkins: yes …<br>
&lt;bramus> … so (missed) start with `flip-block, --left, --left flip-inline`<br>
&lt;bramus> … so (missed) start with `flip-block, --left, --left flip-x`<br>
&lt;bramus> chrishtr: so the flip is a shorthand?<br>
&lt;bramus> fantasai: a prebuilt try block basically<br>
&lt;bramus> florian: the flip thing not only flips i-a but also margins, insets – the whole set of props<br>
&lt;astearns> (and whatever we end up adding for anchors)<br>
&lt;bramus> TabAtkins: e.g. a margin-top that become margin-bottom upon flipping<br>
&lt;astearns> q?<br>
&lt;bramus> vmpstr: so if you add just flip-x then i twould only filp the base sstyles across the x<br>
&lt;bramus> TabAtkins: yes<br>
&lt;bramus> vmpstr: and flip-start<br>
&lt;bramus> TabAtkins: would flip the margin-top to bottom e tall<br>
&lt;bramus> chrishtr: so 4 keywords?<br>
&lt;bramus> TabAtkins: no … more (missed)<br>
&lt;bramus> chrishtr: so 4 diagonals?<br>
&lt;bramus> TabAtkins: only 1 becase you can combine with other keywords<br>
&lt;bramus> [whiteboard erased without photo]<br>
&lt;bramus> TabAtkins: new example with `pos-try-options: flip-block`<br>
&lt;bramus> … or `flip-start` has same output (?)<br>
&lt;bramus> s/has same output (?)/flips across the diagonal<br>
&lt;bramus> then `flip-block flip-start` will first flip across the block and then the diagonal<br>
&lt;bramus> s/then/…then/<br>
&lt;bramus> chrishtr: and in RTL?<br>
&lt;bramus> TabAtkins: you get the other diagonal<br>
&lt;bramus> chrishtr: why is it called start?<br>
&lt;bramus> TabAtkins: only flipping the start values, not the block values<br>
&lt;vmpstr> is there a "rotate"<br>
&lt;astearns> q?<br>
&lt;bramus> … not married to the name<br>
&lt;bramus> nsull: though it was a good name<br>
&lt;bramus> … what about flip-inline?<br>
&lt;bramus> TabAtkins: only flips the inline values<br>
&lt;bramus> chrishtr: so `pos-try: --name` and special keywords?<br>
&lt;bramus> fantasai: list of options<br>
&lt;dbaron> [whiteboard photo PXL_20240213_183159888.jpg]<br>
&lt;bramus> TabAtkins: name blocks or keywords or …<br>
&lt;bramus> fantasai: can also put inset-area in there int he future<br>
&lt;fantasai> So proposed syntax would be<br>
&lt;bramus> astearns: concerned about it being a list property<br>
&lt;dholbert> q+<br>
&lt;fantasai> position-try-options: none | [ &lt;dashed-ident> || &lt;try-tactic> | &lt;'inset-area'> ]#<br>
&lt;astearns> ack astearns<br>
&lt;fantasai> where &lt;try-tactic> = flip-x | flip-y | flip-inline | flip-block | flip-start<br>
&lt;bramus> TabAtkins: better than the prvious list which was expressed via at-rules<br>
&lt;astearns> ack florian<br>
&lt;bramus> … if and when we get addidtive cascade then this current sytnax will work better<br>
&lt;bramus> florian: if we include the syntax extension to have `inset-area` so that you can skip at-rules then this looks like a good propopsal<br>
&lt;bramus> … flip-start naming is weakest part though. needs bikeshedding<br>
&lt;bramus> … cmoputed value of inset-area propably gonna be a lot simplear<br>
&lt;bradk> q+<br>
&lt;bramus> … right now the active what is the computed value (missed)<br>
&lt;bramus> TabAtkins: if we expose things in cqs we now have a single clearing house of what the list of ?? is. much clear to communicate to author and let them do CQ against it<br>
&lt;bramus> fantasai: (backs that up)<br>
&lt;astearns> ack dholbert<br>
&lt;bramus> dholbert: when flipping across the diagonal from start-start, is there an optoin to do from the opposite diagonal start-end?<br>
&lt;fantasai> s/(backs that up)/having a single list of options rather than multiple sources that automatically generate and interleave in non-obvious ways is imho a lot better/<br>
&lt;kbabbitt> q+<br>
&lt;bramus> TabAtkins: no. you can combine keywords.<br>
&lt;florian> s/if we include the syntax extension to have inset-area so that you can skip at-rules/especially if we include the syntax extension to have inset-area so that you can skip at-rules when you don't need them, and include the || between dashed-indent and try-tactic<br>
&lt;bramus> dholbert: is there an equivalent keyword for flip-start htat uses similar longer names to th eother diag flip option?<br>
&lt;bramus> TabAtkins: no, bc block inline and start toegheter are the start for all other permutations<br>
&lt;florian> s/cmoputed value of inset-area propably gonna be a lot simplear/computed value of inset-area becomes a lot simpler: the active mode is the computed value<br>
&lt;bramus> … not sure how you would spell them longer<br>
&lt;bramus> dholbert: would be nice to reason about<br>
&lt;bramus> TabAtkins: open for good names<br>
&lt;bramus> dholbert: 2nd q: for --name options: would the syntax allow you use a variable that includes a --name?<br>
&lt;bramus> TabAtkins: so `@position-try --left { left:var(--foo) }`?<br>
&lt;bramus> dholbert: no.<br>
&lt;bramus> … in the @position-try name<br>
&lt;bramus> s/@position-try name/position-try-options property<br>
&lt;bramus> TabAtkins: yes, you can assign to variable<br>
&lt;astearns> ack bradk<br>
&lt;bramus> bradk: if it flips, then a bottom margin would become top. Is it just marign or also border and padding?<br>
&lt;bramus> TabAtkins: insets, inset-area, alignment, margins, and sizing props (width and height)<br>
&lt;bramus> … not doing padding and border because implementation reasons<br>
&lt;bramus> iank_: it is something like an internal thing of that box, vs the rest is external<br>
&lt;bramus> … (??) tables. similar to border … painting properties<br>
&lt;bramus> florian: could you use CQs to figure which configuration you are in and based ont hat change padding?<br>
&lt;bramus> TabAtkins: yes. not explored yet but on our list to do … having a way to query whcih fallback you are in<br>
&lt;dholbert> My example with css variables above (which should just work, per discussion) was something like: @position-try --left { ...  }  .my-tooltip { --brand-start: --left; position-try-options: var(--brand-start); }<br>
&lt;bramus> … bare min change styling of children<br>
&lt;astearns> idly wonders if there might be a way of specifying a combination of physical and logical properties such that some flip and some do not<br>
&lt;bramus> … if querying based on fallback set you are in and you are not allowed to change that, then we dont have cyclic prolbems to style yourself either<br>
&lt;bramus> … worst case only children<br>
&lt;bramus> bradk: so you could havbe box shadow change<br>
&lt;bramus> TabAtkins: yes<br>
&lt;bramus> iank_: also ties into tether problem … change pos and style of the tether based on what position it is in<br>
&lt;bramus> florian: interesting … with auto flip you can change a bunch of vlaues to allow them to transition … would a CQ also allow that? E.g. box shadow<br>
&lt;bramus> … is the CQ type of flipping break animation?<br>
&lt;bramus> TabAtkins: no; computed value will change and it will transition<br>
&lt;bramus> … again, completely unspecified today but it works<br>
&lt;astearns> ack kbabbitt<br>
&lt;bramus> kbabbitt: q about grammar …<br>
&lt;bramus> … double || there for dashed items? Is that intended?<br>
&lt;bramus> TabAtkins: no, doenst allow you to repeat … only pick multiple from the set<br>
&lt;vmpstr> i'm wondering if flip-start should be transpose, and whether there's any value in rotate-cw and rotate-ccw as additional values to rotate clock and counter-clock wise<br>
&lt;bramus> kbabbitt: there was an optoin about wher eyou could hav emultiple try tactcis, but dont see how that is possible with current grammar<br>
&lt;bramus> TabAtkins: (clarifies syntax)<br>
&lt;bramus> kbabbitt: oh, got it<br>
&lt;bramus> astearns: want to resolve?<br>
&lt;bramus> TabAtkins: want to talk about next aspect, which is not this complicated<br>
&lt;bramus> … resolution is for later on<br>
&lt;bramus> TabAtkins: so next part, a lot of JS libs allow you to put yourself into area with the most space.<br>
&lt;bramus> … we built that into the spec<br>
&lt;bramus> … `pos-try-order` property<br>
&lt;bramus> … couple of keywords; which size you care about<br>
&lt;bramus> … `most-*`<br>
&lt;bramus> florian: no `most-area`?<br>
&lt;bramus> TabAtkins: no because (missed)<br>
&lt;vmpstr> s/(missed)/ill defined and nobody else offers it/<br>
&lt;bramus> … example: `pos-try-options: --top, --bottom`<br>
&lt;bramus> … want to start with biggest<br>
&lt;bramus> … so `pos-try-order: most-height`<br>
&lt;bramus> … currently, to match behavior of libraries we will also try base styles files and only if there is overflow we try the rest<br>
&lt;bramus> … could add options here to include base style as one of the reorderable options<br>
&lt;florian> q+<br>
&lt;bramus> … more expensive because you need to do mutliple stylings<br>
&lt;bramus> … but possible<br>
&lt;bramus> … achiecable by forcing overflow in base styles<br>
&lt;bramus> fantasai: dont do that! terrible!<br>
&lt;bramus> TabAtkins: could also add option to skip basesyles immediately<br>
&lt;bramus> … gonna skip `pos-try-final` for now<br>
&lt;bramus> … so `pos-try-options` and `pos-try-order` to do ???<br>
&lt;bramus> fantasai: not the size of the pos box we are checking but size of IMCB so you dont have to do layout<br>
&lt;bramus> TabAtkins: yes, to resolve the insets<br>
&lt;bramus> fantasai: show the shorthand<br>
&lt;bramus> TabAtkins: that is order followed by options<br>
&lt;bramus> … “ i want the most-width of these”<br>
&lt;bramus> … `position-try` property<br>
&lt;astearns> ack florian<br>
&lt;astearns> q+<br>
&lt;bramus> florian: in itself pickin gorder makes sense. confused about if you pick the one with tallest heigth first, then you are only gonna pick from smaller options?<br>
&lt;bramus> … might vary on the other axis though<br>
&lt;bramus> … what happens if it fits nowehere?<br>
&lt;bramus> TabAtkins: you can adjust properties in the otpions (e.g. max-ehgith) so you might fit in smaller space<br>
&lt;bramus> …when nothing fits you stick with last successful fallback that we used, so you remain stable if nothing works.<br>
&lt;bramus> … there is `position-try-final` to control this<br>
&lt;bramus> … lets you opt in to falling back to largest or first option<br>
&lt;bramus> … (and more)<br>
&lt;bramus> … can also set it to `hide`<br>
&lt;bramus> … vmpstr has use case for it<br>
&lt;bramus> florian: I dont know if theyse keywords if everything we ever need, but seems good extension points<br>
&lt;bramus> … eg “go clockwise”<br>
&lt;bramus> astearns: look at the shorthand<br>
&lt;dholbert> q+<br>
&lt;bramus> … how wedded are you to having the shorthand?<br>
&lt;bramus> … i dont get the idea that it is going to use the first one if it fits here in this example<br>
&lt;bramus> TabAtkins: it will take ??<br>
&lt;bramus> fantasai: when we first designed this oy have base styles and various fallbacks in optoin list whih concat in complete list: base + transforms<br>
&lt;bramus> … and then you re-sort<br>
&lt;bramus> … so you propose to only re-sort the fallbacks?<br>
&lt;bramus> TabAtkins: by default<br>
&lt;bramus> … bc that is how material design’s anchor lib work and their arg makes sense<br>
&lt;bramus> astearns: so pos-try is only listing th e alternats<br>
&lt;bramus> nsull: do you expect authors to ???<br>
&lt;bramus> TabAtkins: they might<br>
&lt;bramus> … excited to see what we can make easier<br>
&lt;bramus> … similar to well named common cases.<br>
&lt;astearns> ack dholbert<br>
&lt;astearns> ack astearns<br>
&lt;bramus> dholbert: so you choose either most-width or most-height?<br>
&lt;bramus> … no secondarily option for “most space”?<br>
&lt;bramus> TabAtkins: not currently. use-cases needed.<br>
&lt;bramus> … havent seen this in js libs<br>
&lt;bramus> … do we wan tto resolve on this as basis for new model?<br>
&lt;bramus> astearns: can do indiv parts?<br>
&lt;bramus> TabAtkins: would like all<br>
&lt;bramus> florian: to be clear: only as a starting point<br>
&lt;bramus> TabAtkins: yes<br>
&lt;bramus> fantasai: yes<br>
&lt;bramus> nsull: seems like a good improvement overall<br>
&lt;bramus> florian: current thing does not include `inset-area` built in<br>
&lt;bramus> fantasai: can build that in<br>
&lt;bramus> fantasai: proposed resolution: adopt `position-try-*` with addition of inset-area into pos-try-opts<br>
&lt;bramus> astearns: concerns?<br>
&lt;bramus> astearns: objections?<br>
&lt;una> LGTM<br>
&lt;bramus> RESOLVED: adopt `position-try-*` with addition of inset-area into pos-try-opts<br>
</details>


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


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

Received on Tuesday, 13 February 2024 19:01:08 UTC