Hacker News Reader

Comment by eleventen | Hacker News Reader

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.

View on HN

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.

Oh huh I didn't know details supported that naturally. I'm guessing this wasn't always the case and my knowledge is simply outdated. TIL!

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.

https://caniuse.com/mdn-html_elements_details_search_match_o...

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

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.

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.

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.

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

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

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

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.

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

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

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

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

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>

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)

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?

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

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!

What about strings + flags?

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

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

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.

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.

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.

* 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 can put a transition on details > summary.

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

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

You say that like it's a bad thing.

Does it need animating ?

When you search text with ctrl+f it also searches inside details elements and automatically expands them!

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.

I used this for a long time, and only now realized that I'm using html embedding, not some hidden markdown feature.

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.

We can also use pure css to implement tab panels. A demo: http://tmd.tapirgames.com/demos.html#section-demo-4

Modern css is powerful.

What is a good reference to learn modern CSS? I seems most books and online resources are quickly outdated.

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.

Note that pure HTML and CSS implementations of tabs using <details> and <summary> fail to meet several important accessibility criteria [1].

While you can make something that visually appears to act as a set of tabs, building it accessibly unfortunately still requires JavaScript.

[1] https://adrianroselli.com/2019/04/details-summary-are-not-in...

The pure-css effects I mentioned both don't use <detail>/<summary>.

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!)

for "accessible", do you mean getting focused when pressing TAB key?

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.

[1] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

[2] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

[3] https://w3c.github.io/aria/#tab

[4] https://www.w3.org/WAI/ARIA/apg/patterns/tabs/

> Tabs should be navigable by arrow keys [4], which also requires JavaScript.

It supports this now (with JavaScript). If not, try to refresh the page.

typo: s/with/without/

what about, make it work in pure html and css, and enrich it with js to make it accessible?

rather than not working at all with js disabled

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.

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.

I posted a list of accessibility issues with the <details> hack in another comment: https://news.ycombinator.com/item?id=46415271

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.

Out of curiosity, why have you needed to? This has never come up for me.

For a simple example, imagine buttons that opens a modal with a particular arrangement of open/closed accordions for each button.

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.

Really don't see what your complaint is.

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.

https://developer.mozilla.org/en-US/docs/Web/API/HTMLDetails...

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.

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.

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

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.

[1] https://developer.mozilla.org/en-US/blog/html-details-exclus...

It's not about using it as an accordion, it's about controlling the open/closed state from other interactions.

different things with the same name? O_O

It’s the name of the accordion and matches how radio buttons work. If you want to distinguish them, you’ll give them different ids.

I understand it, just wondering if it is good taste.

On a different note, trying to use an accordion this simplistic is quite terrible.

https://jsfiddle.net/8m0t5af6/

Or this?

https://jsfiddle.net/8m0t5af6/1/

Not very nice.

Do they work well for when you want to preview text? Like show the first 100 characters of a paragraph and then click to expand?

Of course. That's the summary part

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.

https://developer.chrome.com/blog/styling-details

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.

Last I checked that without JavaScript details / summary has accessibility issues. That is, you need JS to add aria-open or similar.

It’s odd and frustrating that such an essential tag is not defined to be accessible, afaik.

Why would you need aria attributes if it's summary tag?

I presume it has to do with AT and how it typically interprets the tag. TBH IDK other than I’ve seen it come up in accessibility discussions / groups.

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.

Perhaps you’re right. What I mentioned might have been an issue that has since fade due to browser and AT updates.

Thanks for correcting me.

I needed to recreate it recently because summary element does not allow headings inside, because it has a button role.

You can’t force it to be always open on desktop and collapsible on mobile. That was a deal breaker for me.

Reply on news.ycombinator.com