Is that "straight-forward easy to understand and follow JavaScript" the whole thing written from scratch? Or does it use libraries (that use libraries, that use libraries)?

Because I've written my share of javascript-from-scratch in my time - before npm and such. And even if my use-case was limited, in order to get edge-cases and details working - issues long solved by their HTML/CSS counterparts - we needed more and more JS. Many of which handwritten polyfills, agent-detection, etc.

Seriously, things like scrollbars (because the client insisted on them being consistent across user-agents) or dropdowns (because they had to be styled) "visited" state on links, in pure JS are thousands of lines of code. Maybe not today, anymore, IDK, with current APIs like the history API or aria labeling. But back then, just in order to make the dropdown work with screen readers, or the scrollbars react well to touchpads -in the direction the user was used to based on their OS- took us thousands of lines of JS, hacks, workarounds and very hard to follow code - because of the way the "solutions" were spread out over the exact right combination of JS, HTML and CSS. Edit: I now recall we got the web-app back with the comment "When I select "Language" and start typing "Fr" I expect French to be picked and "enter" to then put the language in French". We spent another few days on functions that collect character inputs in memory and then match them with values. All because "flags in front of the names were of crucial importance".

So, maybe this is solved in modern HTML/CSS/JS. But I highly doubt it. I think "some straight-forward ... JavaScript" is either an `import { foo } from foobar` or a pipe-dream in the area of "programmers always underestimate hours"

Because you need 20x the JS to do the same thing and it’s still not hardware accelerated. These new CSS properties are well supported and will only get better.

Because a team of browser engineers have already written and reviewed the code to do it for you; and (hopefully) it’ll be performant, properly tested and accessible… ;-D

JS animations run on the main thread with everything else, so if your browser is busy doing something else the animation ends up being janky. Using CSS solves that problem.

Is CSS too hard to learn or something?

1. CSS is declarative, so it avoid subtle bugs

2. CSS integrates better with HTML, as it has selectors to automatically bind to elements (yes there custom elements for JS)

It'll just degrade gracefully into not animating the element's entry, so unless the animation is somehow crucial you should still be fine to use it.

If you really need to detect whether it's supported there are hacky methods: https://www.bram.us/2024/07/11/feature-detect-css-starting-s...

91% of usage for browsers tracked by caniuse [1].

The biggest gap is Chrome versions > 2 years old.

[1] https://caniuse.com/?search=%40starting-style

“Layers upon layers of opaque incantations”

You’ve described software.

You're doing it wrong. You don't have to remember the incantations. You just have to remember that they exist, and then google them or ask an LLM when you need them.

If you use something enough you'll remember. If you don't, you just look it up when you need it. This is basic programming, nobody remembers everything.

And how might you do this in Javascript?

As the other user alluded to, Animations are not actually there for people who are comfortable using a computer. The vast majority of users are borderlines in capable of using the internet these days. Animations are supposed to be there to really help guide these users into understanding what the scary machine is doing when they click it. Can they be overused, absolutely, but i think have an accordion fold out animated is a reasonable case. You gotta remember your average user isnt paying any fucking attention, so drawing their attention to important changes on screen is not only good but necessary. I'd prefer no animations ever, but i also dont own an iphone while the majority of the world either does or wants to.

Animations are also a way to explain causal relationships between interactions and their results, and to help build mental models of software behaviour.

You need some JS to change an attribute as much as you need JS to change a property. What am I missing?

I hope the command attribute (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...) will eventually support this out of the box. In the meanwhile you can write a single custom --toggle command which is generic and works with any toggleable element

What kind of control are you looking for?

`open` works just like checked for a checkbox input. You can set the initial state in HTML and CSS can respond to changes in the attribute if a user clicks it. Markup won't have programmatic control over the attribute by design, that's always done in JS by modifying the element instance.