Live data from Hacker News

Don't animate height

granola.ai

181–190 of 276 posts

Re: Don't animate height

#181

> 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…

It's like building a space station with sticks and rocks.

Re: Don't animate height

#182
post #50

Just 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

#183
post #33

Is 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?

I wish. But some sites we are stuck with. EG: bank, HR App, etc.

Re: Don't animate height

#184
post #50

Just 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.

Well, and especially because the “fixed” version is still - if I’ve read correctly - consuming 12% CPU before any user interaction on a page that’s otherwise substantially a plain or possibly RTFish text editor.

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

#185
post #50

Just 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.

I don't understand how you'd fix this, in general, for the browser: the browser can't just assume certain animations will never affect layout.

Re: Don't animate height

#186
post #175
post #95

Earlier 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?

Well I don't know how dartium did it really, but it seems to me like "add a new website implementation language to Chromium" would be a tutorial on Chrome/Chromium's home page.

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

#187

Earlier 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

That's very very sad. Animations can make UX much better when used correctly.

Re: Don't animate height

#188

Earlier 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.

You tried the fix for height recalculation on the SVG that is changing fill and stroke and it didn't fix the issue? I wonder why

Re: Don't animate height

#189
I’d be interested to see the performance of the same visualizer in a canvas or animated svg instead. Forcing these animations through the dom seems a little absurd to me, but I’ve been surprised by web performance before.
Post reply on HN