Re: [csswg-drafts] [css-transitions] Transition to height (or width) "auto" (#626)

The CSS Working Group just discussed `[css-transitions] Transition to height (or width) "auto"`, and agreed to the following:

* `RESOLVED: Add calc-size() to css-values-5 and work out details there`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> scribe+<br>
&lt;fantasai> TabAtkins: People have been asking for transition height 0 - auto since beginning of transitions<br>
&lt;fantasai> TabAtkins: also have use cases for other definite heights<br>
&lt;fantasai> TabAtkins: Other one is, not just transitioning from auto, but any of the intrisinc keywords<br>
&lt;fantasai> TabAtkins: to/from zero to any other value is commonly desired, for good shuttering animations<br>
&lt;fantasai> TabAtkins: the most obvious solution is to let people use intrinsic sizing keywords in calc()<br>
&lt;fantasai> TabAtkins: this isn't great, I explain why in issue, short version is<br>
&lt;fantasai> TabAtkins: several layout algorithms branch based on exactly which intrinsic sizing behavior being invoked<br>
&lt;fantasai> TabAtkins: What's min-content/2 vs fit-content/2<br>
&lt;fantasai> TabAtkins: could affect element and/or its neighbors different<br>
&lt;fantasai> TabAtkins: We also have other behavior, e.g. cyclic percentages, which can have intrinsic behavior<br>
&lt;fantasai> TabAtkins: You can interpolate among percentages, but if you interpolate 100% to 0 at 50% you'd still have auto to 0<br>
&lt;fantasai> TabAtkins: creates a jump<br>
&lt;fantasai> TabAtkins: Propose to introduce a new function<br>
&lt;fantasai> TabAtkins: first arg is an intrinsic size calculation<br>
&lt;fantasai> TabAtkins: second arg is a calculation<br>
&lt;fantasai> TabAtkins: it can accept a size keyword<br>
&lt;fantasai> TabAtkins: this forces relying on a single intrinsic size<br>
&lt;fantasai> TabAtkins: and also means you can transition cyclic percentages<br>
&lt;fantasai> TabAtkins: Also, by having as a separate function, this gives us a hook for activating better transition behavior automaticall<br>
&lt;fantasai> TabAtkins: right now, min-content to 100px, it is discrete transition behavior<br>
&lt;fantasai> TabAtkins: having a new function on one end allows us to automatically upgrade both sides to the function<br>
&lt;fantasai> TabAtkins: Can go over more details if ppl have questions, but in general I think this is the right way to go<br>
&lt;fantasai> TabAtkins: would like to introduce to values-5<br>
&lt;lea> q+<br>
&lt;fantasai> TabAtkins: dbaron wants to Intent to Experiment<br>
&lt;Rossen_> ack lea<br>
&lt;dbaron> Intent to Prototype, not intent to Experiment :-)<br>
&lt;fantasai> lea: To make sure I understand, reason of new function is so that there's only one intrinsic sizing keyword and not multiple?<br>
&lt;fantasai> TabAtkins: that's the main one, a few other reasons<br>
&lt;fantasai> lea: would it be possible to use regular calc() and just apply that restriction?<br>
&lt;fantasai> TabAtkins: You have non-keyword intrinsic size things, like cyclic percentage<br>
&lt;fantasai> TabAtkins: you couldn't d othose<br>
&lt;fantasai> TabAtkins: but if we ignore that case<br>
&lt;fantasai> TabAtkins: we could, but it makes for more difficult debugging<br>
&lt;fantasai> TabAtkins: you have to know that the restriction exists<br>
&lt;fantasai> TabAtkins: it's possible to learn, just seems a step further than I would usually want to require for authors<br>
&lt;fantasai> lea: If we use calc(), there's a clear path to relaxing restrictions over time<br>
&lt;fantasai> TabAtkins: I doubt the problems I mention are solveable. The branching on layout algorithms is important<br>
&lt;fantasai> TabAtkins: not likely to change<br>
&lt;fantasai> TabAtkins: so don't think there's a path to mixing in calc() ever<br>
&lt;fantasai> lea: evolution is only one reason, and often group does the impossible later down the line<br>
&lt;fantasai> lea: authors might not hit the restriction, not common in use cases<br>
&lt;fantasai> lea: have to learn a new function<br>
&lt;fantasai> TabAtkins: have to pay a learnability tax<br>
&lt;fantasai> TabAtkins: calc-size() solving other problems better seems worth it to me<br>
&lt;Rossen_> ack dbaron<br>
&lt;fantasai> TabAtkins: folding it into calc() has those problems, and also a different type of learnability hit<br>
&lt;fantasai> dbaron: anotehr case is opt-in to new behavior, the function provides this. If we use calc, we need a separate switch.<br>
&lt;TabAtkins> fantasai: My first impression is that it does make sense to do this as a separate fucntion, for the reasons metnioned<br>
&lt;TabAtkins> fantasai: Like to and from 0, if you're just 0 you'll lose the branching behavior<br>
&lt;TabAtkins> fantasai: This provides a way where even if the calc evaluates to zeor, you're still hanging onto the fact that this is trying to do the intrinsic sizing thing and layout algos will be consistent<br>
&lt;fantasai> Rossen_: any other comments?<br>
&lt;fantasai> TabAtkins: proposed resolution is add calc-size() to css-values-5 and work out details there<br>
&lt;fantasai> Rossen_: objections?<br>
&lt;fantasai> RESOLVED: Add calc-size() to css-values-5 and work out details there<br>
</details>


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


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

Received on Wednesday, 20 December 2023 18:01:50 UTC