Something to add to your CSS reset from now on:
```
:root {
interpolate-size: allow-keywords;
}
```
It enables things like transitions from `height: 0` to `height: auto`.
https://developer.chrome.com/docs/css-ui/animate-to-height-auto/
A common piece of feedback I receive on this one is “it’s Chrome-only, so I won’t use it”.
Here’s the kicker: that doesn’t really matter here, as it’s a nice #ProgressiveEnhancement: Browsers without support get the status quo. Browsers with support get the nice transition.
At worst you make the experience better in browsers with support.
https://developer.chrome.com/docs/css-ui/animate-to-height-auto/
By opting-in today, you’re future proofing your code: once other browsers add support for it, their users too will get the nice experience. A free upgrade, hooray!
For you as a developer that means no fallbacks or polyfills to include; just sit back & relax and let the browsers work on it.
By pure chance, this is exactly what I need for my current project! 😮 Thank you! 💜
@bramus wait, this will work without calc-size()? 👀
@keithjgrant yes. Calc-size() is only needed when you want to actually calculate. Otherwise just use interpolate-size and you're good to go.
@bramus This is rad, but isn't animating layout super janky? I spent most of 2014 - 2016 getting yelled at by dev rels on youtube that I shouldn't be animating anything but transforms and opacity to stay on the render layer.
@ericmikkelsen @bramus There's a performance impact, yes. But you can do it.
@deallocated @ericmikkelsen The general advice to avoid animating width/height still stands, but measured here its impact is acceptable.
It will definitely perform better than the JS that was needed to do these kind of animations back in the day.
Also: our engineering team is about to look into animating width/height on the compositor (🤩)
@bramus @ericmikkelsen That would be a dream! Then I wouldn't have to decide between some things being laggy or potentially weird-looking and hard to animate 😅
@bramus @deallocated OMG, if you can animating width and height on the compositing layer, is there anything you can't animate on the compositing layer? I just assumed everything that ended up on the compositing layer had to be fairly static.
@ericmikkelsen @deallocated I don’t know the exact details of the plans here, but I kinda assume it’ll only be possible under certain conditions.
@ericmikkelsen @bramus compared to that js analytics lib marketing had you put in, it’s nothing!
@bramus Thank you! I had no idea!
Sep 24, 2024, 11:36 PM@bramus This will be a great feature some day, but at least for me there is no "from now on": https://caniuse.com/?search=interpolate-size would like to see more browser support disclaimers in these kind of posts, but thanks for the info anyway!
@djenz As noted in the article the lack of browser support doesn’t really matter here, as it’s a nice progressive enhancement: browsers with no support get the rough switch they already see today. Browsers with support (which is Chromium-based ones only at this moment) give you the nice transition.
Sep 25, 2024, 1:17 AM@bramus Caveats: Chrome 129+ only. Experimental. Not supported by Safari or Firefox.
https://caniuse.com/mdn-css_properties_interpolate-size_allow-keywords
@zeh As noted in the article the lack of browser support doesn’t really matter here, as it’s a nice progressive enhancement: browsers with no support get the rough switch. Browsers with support (which is Chromium-based ones only at this moment) give you the nice transition.
Sep 25, 2024, 11:07 AM@bramus it does matter in the sense that it won't be supported, and future adoption is uncertain. No, it won't break anything, but it won't work either. This is not an unreasonable thing to mention.
Lots of new CSS features are about progressive enhancement. This is not different. It's still important for developers to keep in mind what works and when/where, and what doesn't.
The world is not just Chrome/Blink.
@zeh These features are part of official CSSWG resolutions and are ready for other vendors to implement. Sometimes Chrome implements something first, and sometimes Chrome is last. Here, Chrome happens to be first.
The thing with Progressive Enhancement is that you don’t have to care about what works when or where. You put a solid good working base experience in place that works out of the box. But if the browser supports more than just that base, they get a better experience.
@bramus People really don't seem to know about progressive enhancement in 2024
@heydon @bramus I honestly think it's more the case that people don't want to learn new stuff until it's applicable everywhere. More and more that way over time as we get more and more new stuff to learn.
I know that in general I dont bother with new stuff until that point because experience has taught me that *most* of the stuff I care about isn't progressive enhancable.
@mattwilcox @heydon @bramus esp when some of it gets taken away sometimes.
@heydon You should have repeated the message more than just 3 times.
@bramus LOL true
@ksylor @heydon @bramus Same here, I would definitely get a bugfix ticket from a client if something worked slightly differently in one browser vs another. I try pushing back occasionally but normally they're insistent, which means in order to achieve cross browser consistency I often resort to a JS solution or leave it out entirely.
🤞this - miss being able to link to that live url
I made this quick pen a while back whilst contracting to try and show it. Sadly the front-end lead (I think was their title) wasn't convinced.
https://codepen.io/sturobson/pen/VwdENNx/d9009ca412a392e499d3d005ab05ef66
@heydon @bramus I remember having a book called hardboiled webdesign, which was a fantastic read. It advocated that not all websites should look the same in every browser (In those days, mostly referring to things such as border-radius)
I don't know how, but that lesson somewhat got forgotten these last few years... Unfortunately, the domain https://dowebsitesneedtolookexactlythesameineverybrowser.com isn't up and running anymore, so i'll just add a screenshot of what it was "for the kids".
@utilitybend Hardboiled Web Design by @malarkey is awesome! 🤩
@bramus Although I share the sentiment in theory, in practice it is not easy for outsiders to know if a syntax shipped only by Chrome will evolve or not.
@anthony While I do mention the standards positions from other vendors when talking about these features (which were already discussed and resolved upon within the CSS WG meetings), we could and should do better in our written forms here. Thanks for the feedback!
@bramus In my case there's also a political point. I'm tired to see Chrome having the best experience because no one test on other browser. This is not healthy for browser diversity and I don't want to be a web developer in a world where blink is the only rendering engine.
@bramus Weren't there already other (less good) ways of achieving this effect though? If you use this as your only method then you're giving a worse experience to users in other browsers. I don't think that's a huge problem for this kind of animation, but it seems like a valid criticism.
@williamoconnell I think you’re misunderstanding Progressive Enhancement here.
Progressive Enhancement is **not** about giving browsers without support for a feature a worse experience to the user.
Progressive Enhancement is about giving all browsers a good experience at the base and allowing browsers with proper support for a certain feature to providing a *better* experience to the user.
@bramus It is possible (afaik) to build this type of animation in a cross-browser way, so if you choose not to do that then you're sacrificing the experience of non-chromium users vs. if you had picked a different solution. That doesn't make it the wrong choice, but it seems valid to point out.
I don't think progressive enhancement means you should pick the least-compatible implementation for features just because they're non-essential.
@bramus Are there any performance concerns with this, like the browser doing a bunch of repaints to move the content below an item while its height transitions? Or does the implementation already solve for that?
@darin The general advice to avoid animating width/height still stands. In some cases it’s OK, in others it’s bad. Always do a benchmark to be sure.
That said: one of the things our engineers want to look into is animating width and height on the compositor. I have no details what or how they plan to do that, but it’s exciting to know they are about to look into that.
Sep 30, 2024, 3:17 PM@bramus My main fear is dropped frames. Or should we ignore all the old wisdom of never animating layout?
@nmn The guidelines around avoiding to animate `width`/`height` still apply.
Always measure the impact and make a judgment on that. Sometimes it’s fine, sometimes it’s not.
That said:
- By using this CSS approach you can ditch the previously required JS approach.
- Our team of engineers is looking into animate those on the compositor in select conditions.
@bramus remember to only enable this if the reduced motion media query is supported and doesn’t return true.