Ergh.

Meant “[…] details/summary nesting structure”, not “beating structure.”

Silly autocorrect.

Couple things!

1. Labels can also (and, IMO, should) wrap their input element instead of matching by ID, which does match the details/summary beating structure. Furthermore, as a container for other ~stuff~, they probably wanted it to mimic how fieldset’s legend tag works.

2. Radio buttons are grouped by the “name” attribute.

But what might make your day slightly better is this: details elements are also grouped by the name attribute; you can implement tablike behaviour using details elements out of the box.

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

Sure, its not classical horizontal tabs as we know it, but the core notion of “show me one thing at a time” is covered. I do wonder if some CSS magicks can style them to horizontal tabs. Gut feeling says yes, but I haven’t taken a run at it.

Funnily enough, now it works even with #...:~:text=... URL search fragment anchors, in fairly recent browsers (so no need to use IDs after all):

https://es-d-4410775920250828-0198e89f-8650-7d35-8384-959dbdbaf2e1.codepen.dev/#faq-13-content:~:text=be%20very%20helpful%20for

(this (unnecessarily) addresses one FAQ item by id, but opens another one doing the “search”.)

Does not appear to work on Safari Version 18.6 (20621.3.11.11.3) under Sequoia 15.6.1 (24G90) on iMac 27 (intel) 😭 https://imgur.com/a/lD5Uzc1

Thank for looking !
Effectivelly Firefox works today, I might have been hallucinating.
Waiting for the Safari fix to land and thank for the workaround !
I found the related HTML spec
https://html.spec.whatwg.org/multipage/interaction.html#interaction-with-details-and-hidden=until-found

I’m seeing it work in Firefox:
https://share.cleanshot.com/4V056NLF

And Safari:
https://share.cleanshot.com/1KLG1RSR

I was able to replicate it NOT working in iOS Safari, which apparently needs https://bugs.webkit.org/show_bug.cgi?id=228843 to go out to stable there I guess?

A JavaScript implementation can be:

const matchingDetails = document.querySelector(window.location.hash);
if (matchingDetails) {
  matchingDetails.parentElement.setAttribute("open", true);
}

summary for="example"
details id="example"

There you have the basic concept known as … wait for it … a tab. I know, I know, HTML standards people are terrified of creating tags for simplistic UX concepts that have consumed countless hours of JS/HTML/CSS developer time. But we are basically there, except we are not. So very close when factoring in the existing grouping of details tags like radio buttons by the same attribute value (forget which attribute it is).

I really do not understand why HTML has failed to keep up with basic tags to create basic UX concepts in trivial declarative manner without faffing about with any JS.

We get to y little half-arsed atoms of new elements from the standards bods, but they’re always developed as if by someone who has never written HTML before because they never look into the existing ‘natural’ history of HTML to ensure they are not rewriting the wheel and building new elements that, at least partially, do the same thing established HTML elements had decades ago.

HTML is not evolving, it’s stagnant relative to any other code that produces a UX.

The list of what cannot be declared in HTML but can trivially be done in other languages must be quite long. One of these days hopefully someone will document it.