Re: [csswg-drafts] [css-anchor-position-1] Define interaction with the cascade in `@position-try` (#9149)

The CSS Working Group just discussed ``[css-anchor-position-1] Define interaction with the cascade in `@position-try` ``, and agreed to the following:

* `RESOLVED: fallback styles live in a new "Position Fallback Origin". They revert like Animation styles (back to User origin)`

<details><summary>The full IRC log of that discussion</summary>
&lt;chrishtr> TabAtkins: we resolved earlier that rules from position fallbacks interact with the cascade in some way<br>
&lt;chrishtr> TabAtkins: now we want to define that<br>
&lt;chrishtr> TabAtkins: propose that rules applied by a posoition-try have a new origin after author origin and before animation origin<br>
&lt;chrishtr> TabAtkins: this lets such rules win over all author rules but lose to animation, important etc<br>
&lt;chrishtr> TabAtkins: revert keyword would also revert to user origin, just like animations<br>
&lt;emilio> q+<br>
&lt;Rossen_> ack emilio<br>
&lt;chrishtr> emilio: can can rules in this origin change position?<br>
&lt;chrishtr> TabAtkins: yes<br>
&lt;chrishtr> emilio: s/position/transition/<br>
&lt;chrishtr> TabAtkins: only once all of the cascade has finished is there a transition to start<br>
&lt;chrishtr> emilio: details of that seem fiddly. Seems the right behavior but needs edge case testing and spec text to make sure it's clear<br>
&lt;chrishtr> TabAtkins: current spec says to go through them in sequence and only declare the element's real style once all have done<br>
&lt;chrishtr> emilio: these things used to not be done until after layout?<br>
&lt;chrishtr> TabAtkins: these are inputs to layout and so are used styles<br>
&lt;chrishtr> emilio: but how does that cause transitions?<br>
&lt;chrishtr> TabAtkins: uses the same mechanism we discussed before<br>
&lt;TabAtkins> > These modified styles are applied to the element via interleaving, so they affect computed values (and can trigger transitions/etc) even tho they depend on layout and used values.<br>
&lt;chrishtr> emilio: that causes interleaving then?<br>
&lt;chrishtr> emilio: performance may be an issue, but if that's what we want ok<br>
&lt;chrishtr> futhark: it's quite similar to container queries - might need to repeat style multiple times due to interleaved style and layout across containers<br>
&lt;dbaron> futhark: ... before starting transitions<br>
&lt;chrishtr> chrishtr: emilio was asking about performance concerns also?<br>
&lt;chrishtr> emilio: my question was about remembering rules from before and how are we supposed to do that?<br>
&lt;chrishtr> futhark: in Chromium that is part of the cascade implementation generally<br>
&lt;chrishtr> futhark: we need to handle that regardless for regular animations<br>
&lt;chrishtr> futhark: I forget the exact way that important overriddes animations?<br>
&lt;chrishtr> emilio: animations override important. but if we're just reusing the regular cascade then it's fine<br>
&lt;chrishtr> futhark: what we do is to insert these trys into the cascade as appropriate and re-run it<br>
&lt;chrishtr> emilio: still a bit concerned about performance, but it's fine<br>
&lt;chrishtr> futhark: some optimizations can be applied since the try blocks are more scoped<br>
&lt;chrishtr> emilio: haven't read the exact spec text but seems fine to me<br>
&lt;chrishtr> fantasai: wanted to say that this is the most reasonable place in the cascade to put these rules, other than possibly somehow inlining them somewhere, not sure<br>
&lt;astearns> let’s try to get as much of these fiddly details into a spec as we can<br>
&lt;chrishtr> fantasai: but that possible alternative sounds complicated<br>
&lt;chrishtr> fantasai: we should minimize what goes into these try blocks and put other features elsewhere<br>
&lt;chrishtr> fantasai: this way we can maximize the % of styles that end up in their regular place in the cascade<br>
&lt;chrishtr> fantasai: for inset and margin it's reasonable to put them in position-try, but for more stylistic items they should go in the cascade proper outside of a position-try rule whenever possible<br>
&lt;fantasai> s/somewhere/where the position-try declaration that sources them lives/<br>
&lt;fantasai> s/other features/other declarations/<br>
&lt;TabAtkins> proposed reoslution: fallback styles live in a new "Position Fallback Origin"<br>
&lt;TabAtkins> proposed resoultion: They revert like Animation styles (back to User origin)<br>
&lt;chrishtr> RESOLVED: fallback styles live in a new "Position Fallback Origin". They revert like Animation styles (back to User origin)<br>
</details>


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


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

Received on Wednesday, 20 March 2024 15:39:53 UTC