Previous discussions / submissions: https://hn.algolia.com/?query=Don%27t%20animate%20height
Don't animate height
251–260 of 276 posts
Re: Don't animate height
#252So good to see a developer who actually cares about resources. Thank you!
I usually develop my apps on a 1300 MHz single-core Intel Atom mini PC from 10 years ago. When something like this goes wrong, the app becomes unusable and I immediately notice it.
Re: Don't animate height
#253Earlier quoted context omitted.
Yes it will. Most of the CSS styling is literally wrappers around draw calls.
Which draw calls result in "changing border width will cause a full page re-flow in some browsers, and bot others"? Which draw calls are "literally any animation will cause the full re-flow of the document unless you make sure an element is not a part of the document, but then you'll have issues with positioning, weird gaps etc." Which draw calls teach you that "well, this primitive animation consumes 15% of CPU, but…
You are being disingenuous. I can always use some hyper specific example to disprove any statement about what is generally true. That doesn't mean that understanding what is typically happening is useless. Which is essentially what your claim is.
Re: Don't animate height
#254My head is sort of reeling from this. If height animations are that expensive today, imagine how expensive (and still commonplace) they were twenty years ago. I fortunately quit animating height quite a long time ago in favor of similar transform techniques, but… wow, still crazy to learn the magnitude of this common operation.
I actually did quite a bit of browser animation 20+ years ago. The trick was (as mentioned elsewhere on this page) to only animate absolutely positioned elements. Even back in the version 4 browsers you could animate hundreds of divs at 20+ fps on a decent computer (with JS of course — CSS animation didn't exist yet).
Re: Don't animate height
#255Earlier quoted context omitted.
Which draw calls result in "changing border width will cause a full page re-flow in some browsers, and bot others"? Which draw calls are "literally any animation will cause the full re-flow of the document unless you make sure an element is not a part of the document, but then you'll have issues with positioning, weird gaps etc." Which draw calls teach you that "well, this primitive animation consumes 15% of CPU, but…
You are being disingenuous. I can always use some hyper specific example to disprove any statement about what is generally true. That doesn't mean that understanding what is typically happening is useless. Which is essentially what your claim is.
> You are being disingenuous. I can always use some hyper specific example
These are not hyperspecific examples. We're literally discussing under an article which has a primitive animation which was, quote, "using 60% CPU and 25% GPU on [a] M2 MacBook"
How is 2D graphics programming helping there?
The article goes on to describe, correctly, layout properties ("The W3C spec is full of these!"), paint properties ("this tiny "bikeshed" SVG which you can find on lots of W3C spec pages. It costs ~30% CPU!") and composite properties.
These are not specific examples. These are literally footguns upon footguns that literally have no corresponding counterpart anywhere.
> That doesn't mean that understanding what is typically happening is useless. Which is essentially what your claim is.
Yes, knowing 2D graphics programming is 100% useless to understand what's happening with CSS and DOM.
Re: Don't animate height
#256Earlier quoted context omitted.
You are being disingenuous. I can always use some hyper specific example to disprove any statement about what is generally true. That doesn't mean that understanding what is typically happening is useless. Which is essentially what your claim is.
> You are being disingenuous. I can always use some hyper specific example These are not hyperspecific examples. We're literally discussing under an article which has a primitive animation which was, quote, " using 60% CPU and 25% GPU on [a] M2 MacBook " How is 2D graphics programming helping there? The article goes on to describe, correctly, layout properties ("The W3C spec is full of these!"), paint properties ("th…
> These are not hyperspecific examples. We're literally discussing under an article which has a primitive animation which was, quote, "using 60% CPU and 25% GPU on [a] M2 MacBook".
No we are not. Someone asked about how one learns some techniques that the OP mentioned (that were simpler than the ones given in the article). I gave some general advice on how one should think about what is happening and some general advice about how to think about performance.
Then you are pretending that none of this is relevant because you are concentrating on the hyper specific stuff in the article (which we are no longer talking about).
I also disagree that this cannot be reasoned about by learning a bit about how graphics works, Cartesian coordinate system and literally turning on the paint flashing tool that is in dev tools. It is literally obvious what is happening when you see it.
> Yes, knowing 2D graphics programming is 100% useless to understand what's happening with CSS and DOM.
In fact it was very helpful to help me to understand what was happening. I literally said to myself "wait a minute, that is kinda like this thing I did in SDL 1.2 in university". You are literally telling me, that something I know to be useful isn't, because you say so. That is unreasonable.
Re: Don't animate height
#257Earlier quoted context omitted.
As an old-school webguy, fixes like this article make me sad. The average front-end person these days has so little respect for the DOM and then gets mystified about why the McMaster-Carr website is so good despite being build with ancient practices.
I just went to the McMaster-Carr home page and right-clicked for "View Page Source". There's a LOT of code there.
Looks like its using YUI (a yahoo UI library) that was deprecated in 2011 in favor of YUI 3 (which is now deprecated as well). https://yui.github.io/yui2/docs/yui_2.5.0/docs/index.html
Im seeing a lighthouse mobile performance of 64 with Javascript execution time, unused js, legacy js on modern browsers, etc. as some of the top reasons.
Re: Don't animate height
#258Earlier quoted context omitted.
MS word on a 133mhz pentium and 16mb of ram needed less than 5s to start. Websites don't need that much resources and should be optimized.... if somehow web developers could read, maybe they'd start doing that.
There are full on CAD apps nowadays on the web. Also, this "looking down" on such a huge group of people is pretty questionable behavior.
There were full-on CAD packages for 133MHz Pentiums.
Re: Don't animate height
#259Earlier quoted context omitted.
That's very very sad. Animations can make UX much better when used correctly.
…how? How do they improve the user experience, at all?
Imagine a list of 10 items that gets shuffled so that the order is completely rearranged. With no animation, it would take a lot of additional cognitive load to find where each item went. With animation, your brain would track the general movement of each item much more easily.
Basically, animation provides additional information about object state. Removing that extra information increases cognitive load.
This isn't to say all animations are useful. Many animations are excessive or completely unnecessary, which is probably what has given you a negative view of them.
Re: Don't animate height
#260Is it possible to restrict this as a user? Like to force webpages to use under a certain amount of render/paint time/resources or else just break so that one dumb tab doesn't use up all my battery? Then I can opt-in to greater resources usage if it's a webpage I actually care about. I've seen the "This webpage is using alot of resources" popup before but I don't think it would happen in this case. Because honestly I…
Probably too late, but uBlock Origin can disable animations (technically fast-forwards to the end, less likely to break the page) for all websites. In the Settings > My Filters tab, add:
!Disable CSS animations globally
*,com##*, ::before, ::after :style(animation-timing-function: step-start !important;transition-timing-function: step-start !important)
!Disable text shadow globally
*,com##*, ::before, ::after :style(text-shadow: none !important)
!Disable image filters globally
*,com##*, ::before, ::after :style(filter: none !important)
!Disable rounded corners globally
*,com##*, ::before, ::after :style(border-radius: 0px !important)