> Instead, we can create the illusion of a changing height by using two rectangles, applying translate to each. Its a very clever solution and props to the engineer, but this being the fix makes me truly despair at where we are as an industry around web UI. That html and css won despite these sorts of counter-intuitive horrors. UI layers that make me feel good reflect intent. I can take an image and write some code t…
Don't animate height
181–190 of 276 posts
Re: Don't animate height
#182Just wrap it in a container with fixed height and "overflow: hidden". Now the layout engine knows that it doesn't need to recalculate positions of elements outside that wrapper, and it's much faster. By the way, the same trick was speeding up large rendering back in the day. As long as you know the size of your rows or columns ahead of time, which kinda defeats the purpose of .
> Just wrap it in a container with fixed height and "overflow: hidden".
That's a fix for a webdev who cares, not a fix for a browser vendor as GP was alluding to.Re: Don't animate height
#183Is 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…
How about just not using that site?
Re: Don't animate height
#184Just wrap it in a container with fixed height and "overflow: hidden". Now the layout engine knows that it doesn't need to recalculate positions of elements outside that wrapper, and it's much faster. By the way, the same trick was speeding up large rendering back in the day. As long as you know the size of your rows or columns ahead of time, which kinda defeats the purpose of .
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.
How is that considered acceptable? It’s still going to drain the battery faster than is justified, even if at a somewhat reduced rate from the pre-fixed case.
The acceptable range would be something like 0 - 1% when no interactions are taking place.
I’d still deploy the fix in the article as an interim solution - better is after all better - but I wouldn’t stop there.
Front-end web devs need to have more respect for power consumption and battery life (proxies by CPU and GPU usage).
Re: Don't animate height
#185Just wrap it in a container with fixed height and "overflow: hidden". Now the layout engine knows that it doesn't need to recalculate positions of elements outside that wrapper, and it's much faster. By the way, the same trick was speeding up large rendering back in the day. As long as you know the size of your rows or columns ahead of time, which kinda defeats the purpose of .
> Just wrap it in a container with fixed height and "overflow: hidden". That's a fix for a webdev who cares, not a fix for a browser vendor as GP was alluding to.
Re: Don't animate height
#186Earlier quoted context omitted.
Well they don't really. What ought to happen is someone just makes a new browser (or adds support in an existing browser) unilaterally on an experimental basis. If it's good enough I imagine it would catch on. The limiting factor is presumably that that's a lot of investment for an experiment, but getting anyone else on board without a successful experiment is going to be impossible. (well, also, you have to have a g…
> A nice starting place would be if one of the major browsers added an easy to use extension point for swapping out languages. (at least I'm not aware of this existing, nor that I've looked) What would that actually mean in practice that would be different from how Dartium did it?
Such that one could throw together, I dunno, news.ycombinator.com/index.z and see if they can do a better job than HTML/CSS.
As far as the actual solution to try for, table stakes is a native implementation of something that looks like React (but presumably reimagined from scratch).
Re: Don't animate height
#187Earlier quoted context omitted.
> In 99% of cases I do not care at all about the "artistic vision" of the UI designer and in the other 1% of cases (say an in-browser game or some useful data-viz) I could choose to allow the tab to go crazy with my resources. I'm with you 100%. Although I'd go one step further and say CSS just isn't needed at all, and should be removed from all browsers. Same goes for WebGL (if you want to play a game, download Stea…
No css at all is pretty extreme, but I'd be on board with disabling css animations
Re: Don't animate height
#188Earlier quoted context omitted.
I was just starting a comment on this but you beat me to it! I believe contain: strict; on the parent element would have been sufficient here.
I tested `contain: strict` on their color changing SVG and didn't see any difference. Profiler says it's still doing layout.