This is why I do everything on a canvas nowadays.
Don't animate height
231–240 of 276 posts
Re: Don't animate height
#232Earlier quoted context omitted.
> How long would the development cycle take, if everything is to be written in C? Once upon a time I worked on a website backed by C. Development times were not appreciably longer. We had a in-house templating language for generating HTML (also written in C). That implementation got to the complexity point to where even the original devs did not want to touch it to add anything. But in terms of add a new screen colle…
Interesting. If this is the case, I do wonder why we do not see more of this. Were you around for the original design phase? Why was C chosen? Did you and yours collect performance metrics to see if anything meaningful was gained?
I was not around for the original design. Plus this was very early in my career. It was also early web, around the year 2000.
The architecture involved a custom Apache httpd module to handle requests. That most likely drove the decision to use C.
The system was eventually rewritten in Python, after I had moved on.
I'm not aware of any performance metrics.
Re: Don't animate height
#233Is 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…
> 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…
You can disable CSS in your browser. The fact that you even complain about this tells me that you didn't didable, yet you damned it to be removed. Pretty hypocritical of you.
Re: Don't animate height
#234Earlier quoted context omitted.
> How long would the development cycle take, if everything is to be written in C? Once upon a time I worked on a website backed by C. Development times were not appreciably longer. We had a in-house templating language for generating HTML (also written in C). That implementation got to the complexity point to where even the original devs did not want to touch it to add anything. But in terms of add a new screen colle…
C on the modern web would terrify me. Devs are bad enough with interpreted languages, I can't imagine most of them using a language with a howitser sided footgun.
Yes we had a couple good issues in there.
In particular I remember one bug where a pointer to a local variable was returned by a function. It worked on our development environment which was apparently more forgiving than our production environment.
Why were they different? Because they were actual servers and the production one was the expensive DEC Alpha while the development server was something less expensive (my memory fails me as to the exact machine).
Re: Don't animate height
#235Earlier 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?
Answering because I know the answer, even though I disagree:
There are some situations where having some animation can "attract attention" to parts of the UI, for guidance ("there's some info text here"), feedback ("operation complete"), state changes, timing. All this of course doesn't apply to decorative animations.
With that said: a lot of the situations I mention above are manufactured. They are often because of changes happening away from the mouse, or because the interface is brittle or too slow, and the user doesn't have confidence that something really happened, or because the organization of elements is not functional and things are too far apart that the user might miss something in a totally different part of the screen.
IMO, with enough thinking you can come up with alternative interfaces that don't require animations at all.
Re: Don't animate height
#236My personal call would be to use SVG for this - you can do CSS animations there just fine without triggering layout. Not a frontend expert but don't see why that wouldn't work.
Re: Don't animate height
#237Earlier quoted context omitted.
They're generally static documents that could be served independently, and thus cached, like an image. Many times, though, they're served up inline in the JavaScript code that templates the html, and thus is cached less aggressively, especially if the FE is deployed frequently.
Ok, I want to add a pencil icon here, the pencil should be #ccc, here is #ddd, there is rebeccapurple, and over here it should be the same color as the container color. Please write a nodejs server that produces those tiny images, don't forgot to correctly set the caching headers...
Yeah, this is what I was referring to and is my main use for embedding SVGs.
For really simple ones, the size of the icon isn't a whole lot bigger than a CDN/object storage URL. And if you reuse it a couple times, it might even be a net bandwidth reduction.
Re: Don't animate height
#238I’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.
Did throw together a quick SVG example - on my computer, a dummy page with just this animation spends 1ms rendering, so basically a solved issue - and cleanly.
Re: Don't animate height
#239The lesson should be don't use Electron, animating height in AppKit has no problem
Re: Don't animate height
#240Earlier quoted context omitted.
How about not living in society and instead going into the wild?
Yes, because we should never ever try to improve the society we live in. Our only options should be to a) run away, and b) shut up and take it.
That's not what I was trying to say. But the fault lies with me for being sarcastic and silly.