- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Mar 2024 17:40:41 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position][css-position] Fixing the animation problem`, and agreed to the following: * `RESOLVED: Specify how styles that are conditionally dependant on layout get recomputed` * `RESOLVED: We will use the same sort of recomputed values for animations on anchor & anchor-size functions` * `RESOLVED: Accept that inset area changes the containing block` * `RESOLVED: Defer magic position animations until level 2` <details><summary>The full IRC log of that discussion</summary> <keithamus> TabAtkins: this is two distinct issues. I had an issue in the works to post, but didn't get it finished before the end of the day.<br> <keithamus> TabAtkins: Presently, when we define container queries we implied how anything effected by the query worked but it's not specified.<br> <keithamus> TabAtkins: At the least chrome and webkit act similarly - so there's a throughline.<br> <keithamus> TabAtkins: The existence of container queries is that computed values depend on layout<br> <keithamus> TabAtkins: They must be computed. If a container query matches, changes the value, and the child has a transition on the property it needs to fire the transition<br> <keithamus> TabAtkins: This is a computed value change. We can't know this until layout is already happening and has reached the container.<br> <keithamus> TabAtkins: So we need to somehow figure out what the values were and patch them in.<br> <keithamus> TabAtkins: This needs to be specified.<br> <keithamus> TabAtkins: The rough description is what i just described; part way through layout when we interleave style and layout, and some point (which we'll specify) you realise the computed values need to change as the result of layout, we compute them, teat them as computed values - figure out trasnitions, inheritance, etc - then continue along as if they<br> <keithamus> were alwyas those values<br> <keithamus> TabAtkins: this is also how we make anchoring work well<br> <keithamus> TabAtkins: With the interleaving - does that sound reasonable to eveyrone? Chrome already does this. WebKit is similar but its not as scoped, they do more work but the end result is the same<br> <keithamus> TabAtkins: I do not know what Firefox does. How it handles these.<br> <keithamus> emilio: we do something very similar to WebKit here.<br> <keithamus> TabAtkins: impl details determine exactly what happens, but does this description work?<br> <emilio> q<br> <emilio> q+<br> <astearns> ack emilio<br> <keithamus> emilio: for webkit and gecko (may have some issues with transitions). Is sort of what you describe but it's not... you update the page layout, then recompute the styles for things that change. I'm not sure specifying it that way... like the interleaving blink has...<br> <keithamus> emilio: if you do the extra work of if something changes then recompute it... I mean it generally sounds the right direction but I'd like to have a read of it before.<br> <keithamus> TabAtkins: yes I'm interested in if this is the right direction<br> <keithamus> emilio: the difference between blink and webkit/gecko, AFAIK, style the page as if no container queries match, then do layout, then for things where container queries change, recompute style, then loop until you get to a stable state. Blink does something more subtle.<br> <iank_> q+<br> <keithamus> futhark: in optimal cases we can pause layout and style the subtree, then continue. In several cases we do also need to do multiple passes. Layout depends on auto widths for eg we may not correctly detect this then have something more similar to gecko/webkit<br> <keithamus> iank_: not exactly the same...<br> <astearns> ack iank_<br> <keithamus> iank_: webkit/gecko are failing tests for behavioural difference. Some subtle differences, because they're revisiting prior states.<br> <keithamus> astearns: are tests written down based on spec or impl?<br> <keithamus> iank_: written in spec.<br> <TabAtkins> (there is no spec to be followed right now)<br> <keithamus> astearns: observability... is this a design decision for how we visit this? Recomputation being observable?<br> <emilio> q+<br> <keithamus> chrishtr: right. Not observable.<br> <keithamus> chrishtr: difference in blink and other two engines, it's a bit more optimised to avoid recomputing.<br> <keithamus> iank_: it's quite a bit faster for degenerate cases, and bugs in other engines. Theoretically could be fixed.<br> <keithamus> chrishtr: just a matter of quality of impl difference?<br> <astearns> ack emilio<br> <keithamus> emilio: main difference is how to prevent cycles, things depending on siblings, ancestors, scrollbars, and so on<br> <keithamus> iank_: not cyclical but previous states.<br> <keithamus> astearns: Do we want a resolution? Computed values getting recomputed?<br> <keithamus> PROPOSED RESOLUTION: Specify how styles that are conditionally dependant on layout get recomputed<br> <keithamus> RESOLVED: Specify how styles that are conditionally dependant on layout get recomputed<br> <keithamus> Zakim, next item<br> <Zakim> I see nothing on the agenda<br> <keithamus> TabAtkins: next up. Anchor and anchor size functions should be dependent on this concept.<br> <keithamus> TabAtkins: right now... the anchor function needs to turn into a length, we're not sure exactly when, but at some point it needs to turn into a length to position your element. You need to layout your anchor first then figure out what the length is. It should be transitionable.<br> <keithamus> TabAtkins: if your anchor moves, you should be able to smoothly transition things. If the element you're referring to, e.g. changing anchor name values, you should smoothly transition to them.<br> <keithamus> TabAtkins: So this is dependent on that too.<br> <keithamus> TabAtkins: Larger bit on animation too, but the interleaving is important<br> <keithamus> emilio: other than animation why do we need it to turn into a length?<br> <keithamus> TabAtkins: it is for animation<br> <keithamus> TabAtkins: for all other purposes it's fine<br> <keithamus> emilio: it feels unfortunate that for all other cases it needs to do the extra work to compute<br> <keithamus> emilio: making it a computed value requires some amount of extra work. Unfortunate to require this. If we need it to be computed, then it makes sense, but ordering & dependencies get very tricky.<br> <keithamus> TabAtkins: It's a more complex relationship than container queries. At the moment it means we don't do as-smart trimming for interleaving because the relationship is more complex.<br> <keithamus> astearns: if we want these things to animate then we have to do something? These things animate descretely... we don't want that. Stuffing these changes into computed values, beause that's how animations work, but I suppose we could say computed values that depend on layout use used values instead? That seems worse<br> <keithamus> TabAtkins: I don't know if that seems worse. We're doing all this for the purpose of animations. If there's a simpler solution I'm happy to explore it.<br> <chrishtr> q+<br> <keithamus> iank_: can't use used values... they're at the wrong phase for animations. To do that would be a big and complicated lift.<br> <keithamus> astearns: we're kind of doing that, not used but recomputed which are closer to computed.<br> <keithamus> iank_: I don't think it's comparable.<br> <astearns> ack chrishtr<br> <keithamus> chrishtr: second what iank_ says. emilio is right in difficulty of interleaving but the coherence and overall complexity is less than creating a new way of doing animations. This is just scoped to doing the interelaving, already had to be done for container queries, animations just fall out of that. Confirmed in prototype in blink. Clean solution.<br> <keithamus> q?<br> <astearns> ack dbaron<br> <keithamus> dbaron: the other scary thing is used values - we don't fully formally defined them vs earlier stages<br> <keithamus> PROPOSED RESOLUTION: We will use the same sort of recomputed values for animations on anchor & anchor-size functions<br> <keithamus> emilio: do we need to define what they resolve to when the anchor is not there?<br> <keithamus> TabAtkins: already in the spec. It's the fallback value, which is zero if not specified.<br> <keithamus> emilio: if your anchor has been laid out... I guess I'm wary of the outcomes that happen when you incrementally do this. An anchor function...<br> <keithamus> emilio: I think container queries have the same issues but this can be sorted in the spec.<br> <keithamus> emilio: when you have a style change and the anchor has been laid out before. That can be dealt with the same way as container queries. Probably fine.<br> <keithamus> TabAtkins: Curious about exactly the case. We can discuss in the issue if you'd like<br> <keithamus> astearns: is there a need to specify how animation from anchor size from initial to actual recomputed value? Or does that fall out<br> <keithamus> TabAtkins: initial value?<br> <keithamus> astearns: if anchor isnt there it falls back to initial value. Something changes such that there is an anchor - is it possible to animate from that to a place in layout?<br> <keithamus> TabAtkins: that behavior should fall out<br> <keithamus> RESOLVED: We will use the same sort of recomputed values for animations on anchor & anchor-size functions<br> <chrishtr> +1 to deferring to level 2<br> <keithamus> TabAtkins: one final bit. Do we want to defer fancy animation stuff? emilio proposed that there are enough holes in the idea of position animation animating the rectangle idea I discussed in the f2f. We want to spend more time thinking about it? I'm okay with this based on above resolutions. Most cases will animate reasonably.<br> <keithamus> TabAtkins: Edge cases should be safe to upgrade to via some kind of opt in.<br> <keithamus> TabAtkins: I propose we kick animation idea to level 2 and work on it later.<br> <astearns> ack fantasai<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/9598#issuecomment-1836854109<br> <keithamus> fantasai: I dont mind if we want to push animatability questions to level 2, but there was a number of follow up changes we were planning to make to inset area, alignment, and other things listed, I don't want to defer. As long as making those changes depend on animation, I'd like us to figure out animation<br> <keithamus> TabAtkins: what might we change on inset area?<br> <keithamus> fantasai: containing block vs only causing auto values to compute<br> <keithamus> TabAtkins: already in the spec<br> <keithamus> fantasai: when? That was in this issue?<br> <keithamus> TabAtkins: it's been in for a while<br> <keithamus> TabAtkins: previously we had inset area work by adjusting auto values of inset properties, causing inset properties to match up. This would allow you to animate between inset areas, to some extent. The Apple proposal instead proposed the inset area changed the containing block, which I pushed back on as it was less animatable.<br> <keithamus> TabAtkins: it's a better behaviour to do the container block change and solve animations some other way. If we're deferring the animations stuff to level 2 it means we're potentially regressing inset area animations. I'm okay with that... if we set inset area back to how... resolves, we don't have a good path to a better future world.<br> <keithamus> TabAtkins: I'm okay with it being less animatable now since we have an idea of how we're going to fix in the future.<br> <keithamus> PROPOSED RESOLUTION: Accept that inset area changes the containing block<br> <keithamus> RESOLVED: Accept that inset area changes the containing block<br> <flackr> q+<br> <keithamus> fantasai: that was my main concern, if we need more time and nothing is blocking then that's fine<br> <astearns> ack flackr<br> <keithamus> flackr: we won't be able to automatically enable these animations right?<br> <keithamus> TabAtkins: current proposal is a position-animation property to trigger the good behaviour.<br> <keithamus> TabAtkins: cannot do it by default as it'd be incompatible with todays behaviour<br> <keithamus> flackr: can change it so certain position types are animatable and others aren't?<br> <keithamus> TabAtkins: yes, this is an argument to defer it so it isn't just focused on anchor<br> <keithamus> flackr: I just want to make sure the upgrade path isn't too difficult<br> <keithamus> astearns: what will be animatable in level 1 vs 2?<br> <keithamus> TabAtkins: level 1- properties animating as normal to the extent of positioning insets, e.g. top and left. but if you switch from top to using bottom that won't smoothly interpolate.<br> <keithamus> TabAtkins: or if you change inset area, or self alignment from align self to justify self. Properties will animate it won;t be descrete, but it wont be smooth<br> <keithamus> flackr: usually authors will rely on transitions so there'd be no animation, change from auto to non auto would be descrete<br> <keithamus> astearns: any concerns with level 1?<br> <keithamus> PROPOSED RESOLUTION: Defer magic position animations until level 2<br> <keithamus> RESOLVED: Defer magic position animations until level 2<br> <keithamus> astearns: Next Clarifying inset area syntax.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9598#issuecomment-1981443500 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 March 2024 17:40:42 UTC