[css-transitions] Transition to height (or width) "auto"

[keithjgrant]

(Edited: current resolved-on proposal is at #626 (comment))

https://drafts.csswg.org/css-transitions/#animtype-rect

It would be incredibly useful to be able to transition to (or from) height: auto. As it stands now, you need to jump through a bunch of hoops in JavaScript to simulate it. This is used frequently for transitioning in alert boxes, opening accordions, etc, but it seems silly that JavaScript is required.

I’m sure there must be discussion about this in the old mailing list, but I’d love to be privy to it here.

[AmeliaBR]

Adding here what I replied to @keithjgrant via Twitter:

In order to interpolate to/from an auto or other keyword value, you need to have a way of describing the intermediary state. For lengths, intermediary states can usually be described via a calc() function. 10% of the transition from 50px to 20em is calc(0.9*50px + 0.1*20em). So the most generic approach to supporting transitions with keywords would be to allow the keywords to be used in calc(), with a real-time substitution of the current computed value that the keyword would create.

Sure, there are edge cases where the performance would inevitably be horrible (e.g., if you are transitioning to/from auto at the same time you are also changing things that would cause the current computed value of auto to change), but that shouldn't be reason to prevent its use in more sensible cases.

[nico3333fr]

@keithjgrant yes, this is a real problem.

For the moment, we set up transitions on max-height value (using magic numbers for values, max-height = enough_and_pray_the_content_is_not_that_tall), and if you want to do it including accessibility pov, you have to transition on visibility (as display is not possible, cf this accordion https://a11y.nicolas-hoffmann.net/accordion/?animated=1 ) with a delay... really complicated for something that should be simple. :)

[rickyp-ms]

Looking around the web, you can easily see that this is a constant problem for developers. Velocity.js even notes this specific missing feature in its first paragraph of why it exists (https://fabric.io/blog/introducing-the-velocityreact-library). I can probably give a ton of references (on request) of developers rendering an element, measuring it, setting it's height to 0 then animating to that specific height. Even JQueryUI does a similar measurement technique just to get this to work and it's been around for almost a decade now.

What can we do as the larger software development community to petition this change and make sure it gets in on the next iteration?

Do we need to have more people come here and upvote this bug? Do we need to email a specific individual? Let us know so we can let you know what we need most.

[k2snowman69]

I too am curious what we (the web programming community in general) can do to petition a change in the spec... I've got a few issues I know I could get quite a few people backing.

[birtles]

I caught up with @dbaron about this recently and it seems a likely way forward is to make 'auto' into a computed value. As well as enabling animation with auto, that would also make it possible to write expressions like calc(auto + 10px). While that might not be trivial to implement, since there is interest from authors' and, I believe, browser vendors, it seems promising.

(One way to push this forward would be to submit a patch to one of the open-source browsers for this. Once you've proven the technical feasibility of this, it's easier to argue for it to be added to the spec.)

[dbaron]

auto is already a computed value; the thing that needs to happen is adding support for auto to calc().

[k2snowman69]

Awesome I'll start looking into it using Firefox since I think theirs would be the easiest source code to get a hold of. That said, it may take me a while due to lack of cpu resources (my computer is a 2 core 2.4ghz processor... it's going to take a while to build).

[nilssolanki]

Thank you very much for bringing this up. We currently work around this by reading out an elements scrollHeight and transitioning to that height, only to revert the element height to auto on transitionend. So making this a platform feature would be fantastic.

[craigfrancis]

It has been suggested that we use max-height: max-content.

But trying to get the browsers to implement either has been very difficult, as the CSS animations are typically done between 2 known values, which is why animation usually needs to be done with something like max-height: 500em.

As an aside (and for some of the background on this), I've been trying to get browsers to support auto-height <iframes> and <textarea>s, which will work in pretty much the same way:

https://github.com/craigfrancis/iframe-height

https://discourse.wicg.io/t/feature-request-animating-max-height-height-based-on-content/1403

[Jakobud]

+1. Not being able to transition on height: auto and display: <anything!> (You can't even do a transition-delay on display) has always been a big pain.

[k2snowman69]

Just FYI I'm currently out of the country and I'm also checking with my legal department to see if this is something I'm allowed to do due to where I work (non-compete and helping competitor issues). I'll be back in town on the 20th.

@nilssolanki That's the same trick we're using and it's just annoying.

@Jakobud I would say animating display is a bit out of the bounds of this request and may also have a few edge cases that would be interesting (animating inline to block?).

[k2snowman69]

My legal department has come back to me informing me that I'm unable to currently work on this request due to non-compete legal stuff. That said, I'll have to (frustratingly) recuse myself of any code writing for this feature.

Just to note, I also asked a google groups question here if anyone is interested in taking this up. It should give a basic guide to how I was planning on tackling the problem.

https://groups.google.com/forum/#!searchin/mozilla.dev.tech.layout/auto%7Csort:relevance/mozilla.dev.tech.layout/fFuJqwXvu2I/6_mt7HmhDAAJ

[danegraphics]

Just want to make sure this is still happening.

This is actually rather important because, yes, we can precalculate a value for height and other properties using javascript and things like document.getElementById(elementID).scrollHeight+'px' , but sometimes we need the property to have an auto value after the animation/transition so that we can make changes inside and around the element that the element will respond to appropriately.

For example, I have an element that transitions from a height of 0 to a height of 'auto'. After the transition is completed I want the height of the element to be able to adjust correctly to the changing elements inside of it without me having to recalculate it myself.

So if it really is just adding auto compatibility to the calc() function, as @dbaron has mentioned, is someone working on that, and if not, how would one do so?

[k2snowman69]

To my knowledge no one has picked up this work and I'm still barred due to legal constraints. But if you download the source code and read the conversation here:
https://groups.google.com/forum/#!searchin/mozilla.dev.tech.layout/auto%7Csort:relevance/mozilla.dev.tech.layout/fFuJqwXvu2I/6_mt7HmhDAAJ

It should give you a few locations to pinpoint where you would need to make the changes you need. Not sure if those are all of them but it should give you a starting point for learning the code base.

Good luck, I hope you do take this up because it would be an amazing addition!

[tabatkins]

I'd have to review to make sure that 'auto' doesn't have any special behaviors that make it incompatible with explicit lengths in some situations. That is, any place where the layout system does special things if the width/height is "auto", such that replacing the "auto" with its equivalent absolute length would give a different result.

[craigfrancis]

I can't remember the source, but it was recommended we use height: max-content rather than auto... this might have started from you TJ.

Where it would be nice if we could use this keyword for iframe's and textarea's as well.

[danegraphics]

@k2snowman69 I would love to take this on and get it done. My question is what all would I need to change? I understand that there are the specification pages that explain how the transitions should be interpolated, and that those should be changed if this is added, but is there also some actual coded function or set of functions that would need to be modified? If so, where can I find them?

@tabatkins Do you know of any situations where that would be the case? (that auto acts differently than it's explicitly stated px size?)

[jcrben]

Linked to this discussion in an answer at Stackoverflow where I point out that transition to height: max-content does seem to work in Chrome: https://stackoverflow.com/a/45203565/4200039 nevermind, deleted the answer as I think I got confused somehow - doesn't seem to work

How can I transition height: 0; to height: auto; using CSS? is currently the top-voted question in the css-transitions tag, with nearly 5 times as many votes as the third-highest.

Also, what's the story with bugzilla these days as far as CSS? There's this bug - pointed here.

[danegraphics]

While height is easy to get to the calculated auto through max-content, it would be best if this were to work for multiple properties such as width (there is no setting comparable to auto) and others. It is impossible to use javascript to get width to work properly without manually doing the math to remove the L&R margins, padding, and border from the 100% calculation, and other properties have similar setting problems.

Using the pre-calculated auto value as the target setting for each property that has an 'auto' option, while actually setting it to 'auto', would be the best method from what I can see.

PS: The data from Stackoverflow suggest that this is the most requested feature for the next CSS update. Using Stackoverflow's highly voted issues would probably be a good place to look for other features that might be good to include in the next version.

[jonjohnjohnson]

I used to really really want this feature, but over the years have found myself being content with transitioning a transform in many cases, while having a parent element set in inaccessible ways...

.parent {
  pointer-events: none;
  visibility: none;
  overflow: hidden;
}
.element {
  pointer-events: auto;
  visibility: visible;
  transition: transform ease .375s;
  will-change: transform;
}
.transformed .element {
  transform: translateY(-100%);
}

Here, the -100% seamlessly takes care of the auto height and transitions a texture over possibly invaliding layout during a height transition. Not saying this is the silver bullet for the issue, but offering what I've found to be a more performant option for most cases. And furthermore, if we did get the ability to transition to/from auto, I'd rarely use it over this approach. Though, this obviously doesn't handle the case where you'd want flow content to move along with the "height" transition, which again, is not as performant.

[steveaylwin]

@jonjohnjohnson do you have a codepen/jsfiddle example of this anywhere and if not would you mind posting an example here? Many thanks

[jonjohnjohnson]

@cohsteve Quick -> https://jsfiddle.net/rwozw4bs/

Also, read up on FLIP animation methodology to see how you *could approach animating transforms while simulating the movement of flow content. https://aerotwist.com/blog/flip-your-animations/

[keithjgrant]

@jonjohnjohnson A transform effect works for absolutely positioned elements. But if the element is statically positioned, it still takes up space in document flow when scaled down to height 0.

Transitioning max-height was also mentioned above, but this too has a problem: the timing function is unreliable, since part of the transition will continue well after the max-height has reached the actual height of the element.

[jonjohnjohnson]

@keithjgrant correct. I find the gains from transforming a texture and not invalidating layout worthwhile, as opposed to the *few times I find myself wanting to animate within a flow.

[danegraphics]

Just making sure that this project hasn't been abandoned.

@dbaron, I see you are also the one assigned to the Mozilla ticket as well? (https://bugzilla.mozilla.org/show_bug.cgi?id=571344)

(I don't mean to be so pokey about this. I just keep running into designs where having this would immediately make the desired-but-impossible possible. So I hope that a fix for this bug will come soon.)

[benface]

Thanks for the explanation @tabatkins, that makes a lot of sense. I guess relying on JS for that use case is not the end of the world.

[benface]

Just thinking out loud though: maybe this is something that could be added to the View Transitions API?

[benbucksch]

CSS mostly pretends time doesn't exist

I understand, but isn't time an inherent component of any animation and transition? In other words, if you want to do CSS transitions, then CSS must know about time. It's inherent.

The CSS engine would need to know that "auto" has been re-calculated, and save the old and new concrete value in pixels, and save the time of change along with it (i.e. 3 integer/float values). Then you can transition between those: start time and start value = before change, end value = after change, end time = start time + length of transition as given in CSS.

[tabatkins]

Yes, transitions introduces a limited notion of time. But it relies on computed values changing; at the time we recompute computed values, that's when we check if the value is different than it was previously and kick off transitions. (Or start an animation, due to the 'animation' computed value changing to specify one, etc.)

We don't know what value auto resolves to until we do layout, which happens after computed values.

[benbucksch]

If CSS transition can only currently only transition from the concrete values that the CSS author specifically wrote (e.g. 14px or calc(10px + 3em) = 83px), and cannot transition from values computed from the layout flow (height: auto considering content = 430px), then yes:

It appears that this is exactly what this bug is about. You explain well why we have the bug. Thank you. Given that this is the root of the bug, it seems natural that this fundamental limitation has to be lifted, if we want to fix this bug here properly.

It seems to me from what you say that the biggest implementation problem is the trigger. This may require some new internal API in the CSS engine, back from the layout part, to allow for the trigger. After layout, the engine needs to notice that the concrete value for auto changed, and trigger something. Once triggered (and if there is an auto-transition on the element), use the saved previous value, the new value, and current time, and start the transition between those.

I think this most closely matches the mental model that CSS authors have and expect when they transition an auto value. This definition is also much more easy to understand than the other alternatives suggested here. But maybe I'm missing something why this impossible.

[tabatkins]

Yes, that's the fundamental restriction. It cannot merely be "lifted", however - the restriction isn't artificial, it's in the nature of how CSS works. I showed two examples of how we can work around it in certain limited circumstances, but a general solution is dramatically more difficult. It's not something I'm going to be spending time working on right now, that's for sure - there's way more stuff that is equally or more useful, and doesn't require either a fundamental rearchitecting of CSS or giving up on important performance guarantees.

[benbucksch]

In my suggestion, it would need a callback from the layout engine to the overall CSS engine when an auto value changed. I can see why that's unpleasant, but not a "dramatic" "fundamental rearchitecting of CSS".

[benface]

@benbucksch – No offense, but maybe you should read the spec if you are that interested in contributing in that way? 😅

[benbucksch]

I had the feeling that after 8 years of discussion, we're finally touching the root of the problem. But, alright, I'll mute.

[Loirooriol]

The problem is not just with the "trigger". The problem is that interpolations are currently based on computed values, and you want to interpolate used values instead. As I have said several times in this issue, that's an entirely different model, that would need to be properly defined.

[danegraphics]

I once again submit the suggestion to create a keyword similar to auto that is computed and non-cyclical so that it can function just as any other calculated value during transitions.

It doesn't need to be exactly the same as auto, but close enough to fill in the use cases that CSS devs have been desperately asking for for the last decade and a half.

[danegraphics]

At this point, we've gone in circles on the fundamental limitations that make this difficult.

We know the goal, and we have ways of achieving it. We just need to pick one.

Of the suggestions, either we create a clunky and unintuitive partial (no auto to auto) solution by adding functions that interpret auto differently, or we make something that is more intuitive and complete (can do auto to auto) that still gives the desired result, even if it doesn't use auto specifically.

I am still in favor of the latter.

[benface]

or we make something that is more intuitive and complete (can do auto to auto) that still gives the desired result, even if it doesn't use auto specifically.

Where did anyone with sufficient knowledge of the CSS specs claim this was possible? 🤔

[tabatkins]

Yes, let's please close down this thread of conversation. The use-case in the OP has been solved, and this additional use-case, if it's solveable at all, requires a substantially different effort. This issue is not the appropriate place to discuss that.

[danegraphics]

[removed original]

I'll just put the suggestion in a different thread. I just realized that we can "why not both?" these ideas.

I'll also take the time to make sure that my proposal is clear and detailed, and not just vague and poorly worded as I have done in this thread.

Thank you all for the help, and I look forward to the existing proposal being implemented.

[dbaron]

The question came up a number of times earlier in the discussion: why not just support animation from keywords to lengths? I said that I'd do a bit of research on the compatibility of doing this and report back. I think at this point I've done sufficient research to determine that supporting animation between width keywords and lengths/percentages isn't web compatible.

How did I determine this? In addition to the work I've been doing on calc-size(), I implemented a second hidden feature flag in Chromium to support this keyword animation. Thus anyone with current (though not necessarily future, since I will probably delete the code for this hidden feature at some point) Chrome Canary can test the effects using --enable-blink-features=CSSCalcSizeFunction,CSSSizingKeywordAnimation on the command line. (The first of these flags is also enabled by enabling "Experimental Web Platform Features"; the second one is not.) (See the CL that added this flag.)

I also wrote a CL to gather data on sites that hit this codepath and an additional CL to print out some diagnostics when this happens. I used cluster telemetry (see second doc) to use the first of these CLs to gather data on which sites in a list of top 1000 sites hit my counter on loading. I then used the second CL, combined with devtools, to try to understand what part of the site was hitting the counter and whether there were visible regressions from enabling transition/animation support between these values. Note that this technique was not foolproof -- sometimes I might just fail to see the visual difference even if one was present, or even fail to figure out the right elements to look at. I didn't go all the way through the list of sites that hit my counter, but I went partway through (see full data below).

The full data I have are in this hand-edited CSV file with my notes for the ones that I analyzed. (expand for details)

blink/LengthAnimationOneKeyword/value,blink/LengthAnimationTwoKeywords/value,page_name,notes
8.0,,http://www.163.com (#25),"Attempts to animate values on images from auto to 100%.  I don't see the visual effect but I also didn't figure out which images were involved."
1.0,,http://www.stackoverflow.com (#41),"The ""Every developer has a tab open to Stack Overflow"" animation has a rather visible glitch when it starts where the surrounding text briefly compresses around the word developer.  It animates auto to both the calculated height and width when starting the animation for the first time.  It is a span with flex layout."
1.0,,http://www.mail.ru (#49),"Couldn't repro when loading live site."
3.0,,http://www.aliyun.com (#73),"Toolbar dropdowns on https://www.alibababcloud.com/en at the top of the page (with wide window) have a height animation that isn't present without the flag enabled.  It's not necessarily a bad effect, but it's a visible change."
256.0,,http://www.3dmgame.com (#81),"Similar img element animations to 163.com, can't see visual effect."
4.0,,http://www.deepl.com (#86),"Couldn't reproduce on live page."
45.0,,http://www.alibaba.com (#102),"Seems related to the carousels on the page with class=next-slick-slide, but couldn't see a visual difference."
1.0,,http://www.gitee.com (#153),"An ant-tabs-ink-bar animating between 0px and auto.  Can't see the visual effect."
2.0,,http://www.intuit.com (#194),"Carousel controls animating between auto and 392px. (Self-Employed / Small Business / Consumers) carousel.  The words Small Business have an unexpected and undesirable animation of the white background behind them during page load, though only visible with a very tall window or having the page zoomed out."
1.0,,http://www.ups.com (#244),"DIV with id accordion_2_0_content animating between 0 and auto.  This is the expanded item in the Rates Updates section, which actually expands as the page opens.  It's only visible on opening the page if zoomed way out or on a very tall window.  Opening/closing the item is visibly different, but perhaps better with the feature enabled."
1.0,,http://www.hp.com (#284),"Animating BODY between auto and 100%.  I don't see a visual difference."
5.0,,http://www.target.com (#289),"Animating multiple DIVs without any class/id between auto and lengths, some zero, some nonzero.  Can't spot the difference."
3.0,,http://www.varzesh3.com (#304),"Animating 3 DIV class=owl-stage from auto to very large lengths.  These are for the carousel at the top of the page, the carousel just below it, and a carousel further down.  Doesn't appear to be anything visually broken."
2.0,,http://www.marca.com (#329),"Animating an A with class ue-c-carousel__show-more from 1px to auto, and a DIV with id didomi-host from auto to 0.  Could not find the former in the page; the latter has to do with the consent popup when the page loads, and I couldn't see any visual glitches with that."
20.0,,http://www.riotgames.com (#344),"Constant animation of elements from auto to a small length that decreases over time and then resets to 8px.  Couldn't figure out which elements."
1.0,,http://www.cricbuzz.com (#393),"DIV with ID main-menu_search from auto to 30px.  This is the magnifying glass icon near the right side of the top toolbar.  With animations enabled there's an undesired animation of this widget revealing itself from left to right rather than being present when the page loads."
1.0,,http://www.geeksforgeeks.org (#418),
9.0,,http://www.dell.com (#423),
1.0,,http://www.globo.com (#427),
1.0,,http://www.ithome.com (#431),
1.0,,http://lenovo.com.cn (#432),
3.0,,http://www.asurascans.com (#442),
,2.0,http://www.asana.com (#457),
5.0,,http://www.ctfile.com (#492),
8.0,,http://www.disneyplus.com (#582),
1.0,,http://www.service-now.com (#608),
2.0,,http://www.feimaoyun.com (#618),
2.0,,http://www.bitly.com (#638),
10.0,,http://www.outbrain.com (#646),
3.0,,http://www.dhl.com (#649),
7.0,,http://www.acs.org (#666),
1.0,,http://www.wps.cn (#667),
1.0,,http://epfindia.gov.in (#670),
7.0,,http://moegirl.org.cn (#696),
7.0,,http://pchome.com.tw (#704),
2.0,,http://www.squarespace.com (#720),
1.0,,http://www.bytedance.com (#723),
10.0,,http://www.58pic.com (#747),
1.0,,http://www.onelink.me (#797),
1.0,,http://www.todesk.com (#800),
9.0,,http://www.irs.gov (#821),
2.0,,http://www.bit.ly (#824),
1.0,,http://www.semrush.com (#825),
1.0,,http://www.buzzfeed.com (#826),
2.0,,http://www.aol.com (#839),
7.0,,http://sat.gob.mx (#841),
2.0,,http://www.td.com (#844),
33.0,,http://www.criteo.com (#899),
5.0,,http://www.t-online.de (#906),
4.0,,http://sjtu.edu.cn (#944),

Note that this is a very conservative sample because it only looks at loading of site homepages. Many transitions and animations happen in response to user interactions, and happen on pages other than the homepage.

I found the following site homepages that showed visible differences when enabling transitions and animations between sizing keywords and lengths/percentages:

• On http://www.stackoverflow.com "Every developer has a tab open to Stack Overflow" animation has a rather visible glitch when it starts where the surrounding text briefly compresses around the word "developer" (which later animates into other words). It animates auto to both the calculated height and width when starting the animation for the first time. [ Edit: see video with page reload in the middle, glitch is just after reload. ]
• On https://www.alibababcloud.com/en (which is what http://www.aliyun.com redirects to, at least in the US) the toolbar dropdowns have a height animation that isn't present without the flag enabled. This isn't clearly good or bad in my opinion, but it is noticeably a different opening effect.
• On http://www.intuit.com in the labels for the (Self-Employed / Small Business / Consumers) carousel, the words "Small Business" have an unexpected and undesirable animation of the white background behind them expanding horizontally from the center during page load, though only visible with a very tall window or having the page zoomed out pretty far on load (because it's not above the fold with a reasonable size window). [ Edit: see video of page reload, showing glitch. ]
• On http://www.ups.com the accordion in the Rates Updates section (which expands as the page opens, well below the fold, thus causing the issue to happen during page load) has a different height animation. In this case I think the height animation is actually quite a bit better with the feature enabled. So this is a case where enabling the feature might make an existing page work better. [ Edit: see video of existing behavior and video of behavior with sizing keyword allowed. ]
• On http://www.cricbuzz.com the search widget (text input and magnifying glass) on the right side of the top toolbar has a clearly undesirable animation as the page loads, revealing the widget from left to right rather than having the widget just be present. [ Edit: see video of page load in new tab. ]

The first and fifth issues above (and perhaps also the third, but it's less visible on the home page because it happens only below the fold) might be close to bad enough to mean we'd have to revert the feature if we tried to ship it. However, more significantly, I think this list of issues suggests there's a long tail of many more issues across many other sites that I didn't examine, which I think makes it clear that we couldn't just ship support for transitions/animations between sizing keywords and lengths/percentages, and that it has to have some sort of opt-in (which, in the current proposal, is use of the calc-size() syntax).

[tabatkins]

Thank you so much for the exploration, @dbaron ! That's more than I expected!

I agree, then - while the results are mixed, there's enough obvious bad results that it seems like a net negative to have this operate by default. I plan to keep the current spec as it is, then, where you need at least one of the transition endpoints to be a calc-size() to trigger the calc-size()-based interpolation.

[tabatkins]

Agenda+ just to confirm with the group that, per dbaron's research, supporting direct "0px to auto" interpolations are indeed not going to be possible, and authors have to "opt into" transitioning with calc-size() by wrapping at least one of the values in calc-size() to start with.

(But the syntax is designed such that you can literally just slap the calc-size() around the value and it works; there are useful defaulting rules to figure out whether calc-size(N) is meant to be calc-size(N, size) or calc-size(none, N), and they mean that all transitions work out-of-the-box if they're possible at all.)

[css-meeting-bot]

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

• RESOLVED: Animation to/from keyword sizes requires an opt-in, so by default only get transition ifa t least one side gets calc-size()

The full IRC log of that discussion

<khush> > if that returns pseudo-element animations?
<khush> flackr can confirm. I think it's supposed to.
<fantasai> -> https://github.com//issues/626#issuecomment-2071016522
<fantasai> dbaron: We discussed calc-size() proposal. One question was whether we could, instead of or in addition to calc-size(), write what people want to write
<fantasai> dbaron: concern was compat, but did we check
<fantasai> dbaron: one thing I followed up with, since I had implemented, I could implement the natural behavior where you could just transition '0x' to 'auto'
<fantasai> dbaron: I could figure out what could break
<fantasai> dbaron: There's more details in the comment in the issue, but basically what I did was a very conservative study
<fantasai> dbaron: ran through loading top 1000 sites with a special build
<fantasai> dbaron: Even with that limit, I found multiple pages that would break with this change
<fantasai> dbaron: [gives some examples]
<fantasai> dbaron: Several pages animating widths and heights from zero that was not expected
<fantasai> dbaron: at the same time, there was a page on ups.com with an animation that got better
<fantasai> dbaron: but conclusion was, given this very small and conservative sample shows multiple pages that are broken
<flackr> q+
<fantasai> dbaron: we know it's not web-compatible
<fantasai> dbaron: so we know we can't just support CSS tranistion from 0px to auto and equivalents
<fantasai> dbaron: given that, what I want to get out of this is to restate more firmly that we want to move forward with calc-size()
<fantasai> dbaron: given alternative, which would have better developer ergonomics, is not compatible
<astearns> ack flackr
<fantasai> flackr: agree we can't just do it automatically
<fantasai> flackr: what about having a more generic opt-in for authors?
<fantasai> flackr: calc-size() require for each item to change the styling
<fantasai> flackr: whereas a switch could opt in your whole page
<fantasai> dbaron: we could consider something like that
<fantasai> dbaron: maybe use transition-behavior, which is designed to do that
<fantasai> dbaron: it's reset by the transition shorthand
<fantasai> flackr: it's also about transitions only, not animation
<fantasai> dbaron: I think we can do both
<fantasai> dbaron: current behavior with calc-size(), to get the animation you have to wrap at least one endpoint in calc-size()
<fantasai> dbaron: I also do worry about global overrides
<fantasai> dbaron: because pages are built from smaller components
<astearns> ack fantasai
<fantasai> fantasai: Agree with flackr
<TabAtkins> I'm completely fine with a value that can turn on the transition behavior for general values, fwiw, so long as the default behavior requires using calc-size() on at least one side.
<fantasai> fantasai: I think putting in transition-behavior is good, not global, easy to incorporate into transitions and gets reset whenever you do a different ransition
<fantasai> fantasai: for animations, could consider something in the @Keyframes rule, so that it gets associated with the keyframes and used wherever the keyframes get used
<fantasai> astearns: but agree that doesn't preclude using calc-size()
<fantasai> fantasai: yes
<fantasai> TabAtkins: Proposed resolution, by default, only get transition if at least one side gets calc-size()
<fantasai> RESOLVED: Animation to/from keyword sizes requires an opt-in, so by default only get transition ifa t least one side gets calc-size()
<fantasai> s/ifa t/if at/
<fantasai> dbaron: At this point it's prototyped in Chromium, but it's getting more stable and closer to matching spec at this point

[martinthomson]

Can you do calc( ( calc-size(min-content) + calc-size(max-content) ) / 2 ) ? Why not?

[dbaron]

No.

In terms of the spec (defining that you can't do it), you can't because calc-size() is not defined to be a math function that's valid inside of calc(). It's defined as a separate toplevel production (<calc-size>) that needs to be specifically allowed by each property that accepts it. The only other place that accepts it is that it is accepted recursively as the basis (but not as the calculation).

In terms of rationale (why shouldn't it be allowed), it's because many layout algorithms in CSS depend not just on the mathematical values of these properties but also have conditionals that branch on what are essentially type checks on the value. This alternative is a bit less general than allowing full calc() math on intrinsic sizing keywords, but avoids the need to go and rewrite a bunch of existing layout algorithms (tables, flex, grid, and I think also multicol) to avoid branches. This rationale is discussed a bit in the section on Allowing intrinsic sizing keywords inside of calc() in the explainer (a subsection of "Considered alternatives"), and also the following paragraph from earlier in the explainer:

In other words, when a CSS-based layout algorithm (for example, block layout, flex layout, grid layout, table layout, or multicolumn layout) has something that in pseudocode would be expressed as "if the value is a percentage" or "if the value is the fit-content keyword", then that pseudocode now examines the basis of any calc-size() value. However, when the layout algorithm needs the mathematical value resulting from the value, then the calculation is used.

[LeaVerou]

I wonder if it would be more web-compatible to only transition between these values when a width/height transition is explicitly requested, rather than when implicitly included via all (either explicit or omitted).