Hacker News Reader

Comment by maxloh | Hacker News Reader

> The details / summary thing absolutely kills me. There’s basically nothing you can’t do with them.

Animating the details element is tricky. By the spec, browsers don’t natively support transitions between display: none and display: block.

View on HN

That is no longer true! You can do it in CSS with a combination of `@starting-style` and `transition-behavior: allow-discrete`. [1]

Another gotcha you'll run into is animating the height. A couple other new features (`interpolate-size: allow-keywords` and `::details-content`) will let you get around that. [2]

Modern CSS is awesome.

[1] https://developer.chrome.com/blog/entry-exit-animations

[2] https://nerdy.dev/open-and-close-transitions-for-the-details...

The major issue with this is that modern CSS is almost its own job, to the point we used to have Interface Developers at some place I’ve worked (HTML+CSS specialists). I did frontend for over a decade and eventually lost the train on CSS changes, I don’t even know what’s going on there anymore.

It’s still awesome, but it’s becoming increasingly silly to ask someone to know modern HTML, CSS, JavaScript, Typescript, some build tools, a couple of frameworks, etc.

The amount of JS we ship to clients is a reflection of cost-cutting measures at your workplace, not that every FE dev shuns CSS.

When I started dabbling in web development, writing HTML and CSS was already its own job, and professional JavaScript developers basically did not exist. This was before TypeScript, before Node, before Ajax, before React or even jQuery. If anything has exploded in complexity in the intervening years, it's the JavaScript part of the equation.

I agree that it's increasingly silly to ask someone to be an expert in all of frontend. But the primary driver of that is not all the new CSS features we're getting.

Agreed. Having a "HTML + CSS" engineer on the team was largely due to the number of hacks needed to make css work -- purposely adding invalid html that would only be parsed by specific browsers, ie5 vs ie6 vs netscape being wildly different (opera mobile was out of this world different), using sprites everywhere because additional images would have a noticeable lag time (especially with javascript hover), clearfix divs to overcome float issues. To be clear, I'm not saying "things were harder back then" or "css is simple now", but things with CSS were so wild and the tooling was so bad, that it what a unique skill of it's own that is less needed now, and the shift has been for people to focus on going deeper with js.

<sarcasm>I'm an expert -> just write everything in static html, use css only where defaults are neglected. After relevant tables in the db are updated generate a new static document. Only if that won't fly use json but feel appropriately dirty when you do.

These are fair points. And developers themselves thought “hey, what if I also write Node?”, thus making things worse. Businesses accepted that all too willingly.

I can't see how a bunch of esoteric incantations are better than just some straight-forward easy to understand and follow JavaScript.

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.

   <span onclick="
      banana.
      classlist.
      toggle('hidden')
   ">click</span>
   <div id="banana" class="hidden">loris</div>

That's a poor example since it isn't accessible and doesn't work if a pending JS or CSS network request is preventing it from functioning.

This is the HTML version, it's not susceptible to halted execution, and it is accessible.

  <summary>Click</summary>

  loris

</details>

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"

using flags for language is a bad pattern I wish would die. I'm not clicking on the British flag!

Certainly. But the problem here wasn't "we want flags", but that the client (via the designer) demanded something that couldn't fit in a select box and so we had to build our own.

Now, I think part of the problem is that such elements weren't architectured properly when invented. Like many other HTML elements, they should've had some way to style and/or improve them.

E.g. an H1 Header, I can apply CSS to and change it from the default to something matching the business style. I can add some behaviour to it, so I can bookmark it's id anchor. I can add some behaviour to turn the H1-6 into a nice table-of-contents. Or an image can be improved with some CSS and JS to load progressively. But most form elements, and the dropdown in particular, is hard to improve.

And, yes, I am aware of the can of worms if "any element is allowed inside an <option>". Or the misuse designers will do if we can add CSS to certain <options> or their contents. Though I don't think "webdevs will abuse" was ever the reason not to hand power to them. It was mostly a disconnect between the "designers of the specs" and the "designers/builders of websites".

Because that "abuse" is never worse than what is still done en-masse: where we simply replace the "select" with hundreds of lines of CSS, divsoup, and hundreds or thousands of lines of JS. Where entire component libraries exist and used all over the place, that completely replicate the behaviour of existing (form) elements but with divs/spans, css and js. And despite the thousands of hours of finetuning, still get details wrong in the area of a11y, on mobile platforms, on obscure platforms, with a plugin, with a slow connection and so on.

Luckily things are slowly changing for the better. You can actually style a <select> now! Browser support is still scant but it'll gracefully degrade to a normal looking <select>. https://developer.mozilla.org/en-US/docs/Learn_web_developme...

What about strings + flags?

String of the language, in it's language: [Flag] Suomi (Finnish)

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.

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)

We've gotten so far away from semantic documents so we could build "apps".

Data used to be first class. You would deliver everything in the HTML container and the style sheets or client could do whatever it wanted/needed with that data.

Native search, native copy, no clever javascript tricks to hide or remove information from the document.

The HTML data container should be immutable.

> We've gotten so far away from semantic documents so we could build "apps".

Exactly. We're still pretending that the browser is some kind of document display application when it's an application runtime. We keep adding more HTML tags and infinite number of CSS properties and features (that never get it right) when what we should have as a better application GUI API. Throw all the hardware acceleration and threading into that instead of @starting-style, transition-behavior: allow-discrete, interpolate-size: allow-keywords and ::details-content and breath some sanity into the platform.

We've effectively re-implemented that desktop/mobile GUI using a bunch of cobbled together technologies and continue to get more esoteric and complicated every year. Hell, I'm not even sold on JavaScript -- it's just as clunky and weird as everything else.

Move document rendering into high-level implementation on top of a better designed low-level API much like how PDF display in browsers is done with JavaScript.

It sounds like you want a game engine.

I want a hypertext document viewer.

> @starting-style, transition-behavior: allow-discrete, interpolate-size: allow-keywords and ::details-content

This is sane from a declarative document styling syntax.

As a developer, I want a sane platform. Sometimes I want to write documents and sometimes I want to write applications.

> This is sane from a declarative document styling syntax.

Is it? CSS intentionally avoided mixing animation with live layout resolution and now we have a "switch" to enable it. I wouldn't call that elegant.

If we could just hook into layout with code this could have been resolved years ago instead of waiting for browser makers to invent yet another set keywords.

In my opinion the problem is the lack of good GUI editing apps for purely HTML documents and no standard for self-contained HTML docs (that would bundle all the ressources into a single clickable file).

Word for the web basically, but with support for multimedia.

In that sense the web has failed, there is epub but it's not really good.

Is CSS too hard to learn or something?

I'm not particularly familiar with modern webdev, can anyone share a minimal example?

JavaScript encumbered pages break at least once for NoScript users.

To be fair, that's on the user. It's a trade-off the user is making, knowing that there's poorly made sites out there and sites that actively depend on JavaScript to function (sometimes because JavaScript is the only way they can function, but usually because someone's never heard of progressive enhancement). In the past, turning off JavaScript was a functional way to prevent things from running and to make sites load faster; today ads and progressive enhancement and optional functionality are hardly the only usage of JavaScript: lazy loading variable-size content (via fragments or otherwise) causes scroll issues if you're trying to go for performance on a complex layout. CSS containment and content-visibility with contain-intrinsic-size help solve this, but they're pretty new.

* Only works on chromium browser for now.

** Works badly even on chromium browsers (granted I was doing weird stuff, but the animation did not work properly).

I estimate that in a few years we will have animations working properly and mostly everywhere on details elements. Not before.

You say awesome, I say layers upon layers of opaque incantations I have to remember. Thank god for LLMs.

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.

“Layers upon layers of opaque incantations”

You’ve described software.

And how might you do this in Javascript?

they just said "LLMS"!

My point was that js would be vastly more complicated than these html/css "incantations".

Most front end engineers could do it in JS without ever having to look something up. But the CSS to do it is still obscure to most.

so, why not answer my question and say how you'd do it in js...?

@starting-style Has less than 90% browser support making it a non-starter for the time being at least.

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

I agree, but must also observe that I have never met a designer who was willing to admit without a knock-down drag-out fight that any animation they put in was not somehow crucial.

I've never met a designer who wasn't completely fine with my suggestions for more pragmatic solutions. Like just styling a default scrollbar instead of implementing my own scrollbar to make it exactly like the design. Using a default drop-down menu instead of rolling my own just so I can round the corners of the selects.

The designers I've worked with are fine with these things. We have more important things to work on than small style details. We can go back and change these things later if anyone actually cares, but generally nobody ever does.

I've never met a designer who cares how it gets done but I have hard time believing they were OK with the corners not being rounded as per the design. They may agree on shipping without the rounded corner, as long as the ticket to round that corner is registered.

I suppose though that we have just had very different life experiences, as that is what the HN guidelines would require of us.

I think you're both right.

I have also met a lot of completely unreasonable designers that would insist on the most minimal things (even to the detriment of usability), and would act like assholes towards developers.

I have also had situations where developers would beg to work with a certain designer because their experience made development a breeze, even for complex layouts. Funny enough, the projects where this designer worked would always get done, and the visual result was always great.

The trick is they'll see it working for themselves. :)

It depends on what you're doing. It's common for clients to wonder why the design they saw had fancy animations yet they don't see them on their MacBook...

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

Animating accordions is almost always a bad idea because the content length can make it unbearable.

In general I find animations on the web overused and unnecessary

Seriously. As a user I can count on zero hands the number of times I’ve said “Oh great, I’m sure glad this UI is animated!” - and likewise zero times have I missed it when animation isn’t used. Animation is a way to light small units of your users’ precious time on fire, for zero benefit.

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.

That's the positive interpretation, but none of the discussions I've had with UI designers or managers have been about adding animation for accessibility, and the zeitgeist of the last decade has been that skeuomorphism (of which intuitive animations are a subset) is passé.

So far as I can tell, all that the stakeholders want from the UI, animations included, is pizzazz.

If it is for those people who barely grasp the slightest thing about what’s going on on-screen, I could grant them that, if they’d let me turn it off. In the days before jailbreak became basically impossible, setting the animation duration to zero was a blessed, incredibly satisfying thing. It’s exactly what I want. Just do the transition in zero seconds.

My iPhone 15 can’t even catch my first 1-2 keystrokes on the keyboard, multiple times a day, but boy howdy does it have the time and the cycles to animate that f*%ker into view. The disrespect for my time and my needs is so obvious.

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

Being related to neither software behavior nor the structure of the underlying problem, animations tend to obscure the causal relationships and make it harder for user to build a correct mental model.

I see where you're coming from: animations are overused and even when they make sense they are made too slow and flashy (because otherwise how would the implementors feel like they did something if it's barely noticeable?)

Animations are like bass in music: most people notice them only when they're missing or bad.

Does it need animating ?

> Animating the details element is tricky. By the spec, browsers don’t natively support transitions between display: none and display: block.

Very hot take; then don't animate them!

Animation in a UI is great - you draw the user's attention to a widget that changed because they might not necessarily notice it otherwise. This improves the UX.

With a details/summary, the animation is not needed and can only make a negative change to the UX. There is no positive change to the UX that animating the details/summary elements would bring. When it is opened it is obvious.

If you really really need to animate the details, instead of animating open/close, instead animate the summary background/text color to indicate that the element has just changed state.

Would I like easy animation of open/close? Sure. Does it improve the UX? Nope.

You can put a transition on details > summary.

> browsers don’t natively support transitions between display: none and display: block.

You say that like it's a bad thing.

Reply on news.ycombinator.com