The details / summary thing absolutely kills me. There’s basically nothing you can’t do with them. Hiding and replacing markers is easy. But every component library just pretends they don’t exist.
It even saves you the effort of all the aria control and expanded tags: these tags don’t need them.
One drawback of details was that cmd+f search wouldn't play nicely when the details was closed. But now there's a hidden="until-found" you can put on child content, along with an associated event. So you can open the details when a user searches :) super useful
You don't need the hidden="until-found" for details/summary, because that has those semantics automatically, but you can use that for other elements that behave similarly (for example tabs, which can't quite correctly be implemented with details/summary, and so needs to be done by hand).
Also I think the event isn't currently emitted consistently on all browsers (and maybe not at all for hidden="until-found"?) so unfortunately you can't quite rely on that yet if you need to sink some JavaScript state to your html. But in general, yeah, this is a really cool feature.
Yeah, support was patchy until recently (and I think that behaviour might not even have been standardised?) so I think a lot of people have assumed that if you want that functionality you need to do something extra.
Yes, Google started revealing the contents of <details> a few years ago, long after the element was supported in all browsers. Firefox added support earlier this year and Safari just added it.
Supporting the behavior was related to changing the user agent CSS when they're closed and the other browsers implemented it and hidden=until-found at the same time.
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]
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.
<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.
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.
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.
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"
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.
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.
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.
> 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.
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.
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.
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.
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 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.
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...
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.
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.
> 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.
Ooh, that sounds useful as a pretty mix-in-bad-data method for scrapers. Have a few of these tags do if junk, even though they are hidden it'll look to a scraper that cares about hidden/not like they aren't always hidden so are likely to contain something worth adding to their DB…
I'd need to look into what effect this might have on accessibility, but my gut says "very little".
Fun fact: <details> even works on github and similar sites with markdown-based input. You can post large inline logs in issues without cluttering the conversation.
The details / summary feature can also be implemented with pure css without JavaScript. Here is an example: https://docs.go101.org/std/pkg/io.html, just click all "+" signs to expand contents.
This is false, recently the details element has gotten support for grouping them: the [name] attribute.
This effectively enforces tab-like semantics where only one of the grouped details elements can be open at a time.
This is a quite recent addition and the modern web is evolving too fast so I wouldn't put it past myself for missing this :)
Yay for progress and for JavaScript free solutions!
No, it's still true. I'm aware of that hack, but unfortunately it doesn't solve the problems with pure HTML and CSS tabs.
Crucially, the `name` attribute does not semantically turn a group of <details> elements into a set of tabs. All it does is introduce the (visual) behavior where opening one <details> element closes the others.
Same caveat applies to the "checkbox hack" or any other pure CSS solution. You cannot create accessible versions of most complex controls like tabs without JavaScript.
(That first example could be created semantically and accessibly with <details> / <summary> though!)
That's actually a common strategy called "progressive enhancement". The only thing is that your order is backwards: you should first make it accessible in pure HTML and CSS, and then use JavaScript to layer your fancy interactions on top.
So, for the tabs example, your baseline pure HTML and CSS solution might involve showing the all tab panels simultaneously, stacked vertically. Once the JavaScript loads, it would rearrange the DOM to hide all but one and add the tab-like behavior.
Here is a non-exhaustive list of issues you'll run into with various pure HTML and CSS implementations:
- Tabs should have an ARIA "tab" role [1], but <summary> doesn't accept roles [2].
- Focusing a tab must activate the corresponding tab panel [3], which requires JavaScript.
- Tabs should be navigable by arrow keys [4], which also requires JavaScript.
I want to be clear that I'm not trying to tear down your work. Your project looks cool and eliminating JavaScript is a noble goal. But unfortunately, as of today, it's still required to correctly build most complex controls on the web.
I really don't know. I'm not a CSS expert. I've just picked up bits and pieces of CSS knowledge from Google and AI agents. These results often aren't perfect, so you'll need to make some adjustments.
You can't actually control the open state properly from markup (the `open` attribute only sets the default state), which is why I haven't bothered with them.
I’m not sure this is correct. The DOM class HTMLDetailsElement has the `open` property, which you can use to read/write the details element’s state. If you’re using setAttribute/getAttribute just switch to the property.
Having to use the property on the element instance, rather than the actual HTML attribute, is exactly the kind of wrapper code I want to avoid if I'm using a built-in.
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
`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.
If you specify the same name on each `details` element they behave like an accordion automatically [1], no need for JavaScript. If you set one of them to open that one will be initially open.
You can do that with a details element, you just need some code to actually do it. Which I'm pretty sure there's no possible solution that doesn't require some code to do that.
Yes. For example, on Codidact (https://codidact.com), limited HTML access is offered along with Markdown when making posts, and the details and summary tags in particular are whitelisted. I've made extensive use of this in some of my content, for example https://software.codidact.com/posts/289251/289252#answer-289... . If you have NoScript you can easily verify that the expanding sections work perfectly well without JavaScript. They can even be nested, as they are here; and the summary text can contain some other forms of markup without issue. (When crafting the post, however, I had to do some tricky things with whitespace to avoid confusing the Markdown parser.)
Details works even when it's set display:contents too, for even more flexibility. Can't animate from open›close, yet, though. That's pretty much my last frustration with it.
I think the CSS support for that has finally landed, though it means targetting a pseudo element instead. Its been a year, so support is probably good enough you don't care if just the animation doesn't happen.
Note that the transition to `auto` in that post relies on `interpolate-size` which has yet to land on Firefox or Safari, and neither have movement right now.
That's not correct. There is no aria-open attribute and the summary implicitly has the correct ARIA state, aria-expanded, indicating that its details element is either expanded or collapsed.
There have been bugs in its implementation, particularly in Safari and differing between mobile and desktop Safari.
It even saves you the effort of all the aria control and expanded tags: these tags don’t need them.