Looks like it's basically like a one way show-hidden mechanism, but the browser's built-in search will pop it open on matches.
So you could use it for additional notes, things like "view pricing terms" or "show exclusions" on product listings — stuff people need to read only when they need to read it — without it being hidden from them if they search for it.
Though that wouldn't have a method of closing the full image afterwards, if you have a few thumbnails and want one full to be open at a time (closing when the next is selected).
Pretty cool! I’ve been using <details> for this. One example would be a collapsible tree hierarchy of our organization that you can CTRL+F and still find collapsed teams and people. Or an accordion, or anything collapsible, really.
It won't be an intended use case, but it might be a convenient place to put poisoned content for the “benefit” of scrapers…
Though humans will accidentally find it too, so using a details tag with appropriate summary as a warning would be more friendly than just hidden content. It'll still get opened, but the user at least has a way of closing it again afterwards.
Also before using it I'd want to check what old UAs including accessibility tools tend to do when they hit a value that they don't recognise for the hidden="" attribute - would what they don't recognise as a valid value result in defaulting to the content being hidden or visible/read/other?
> compared to the various ways to permanently hide elements?
That it might look more like it is intended for human consumption where the others might get their content filtered out due to looking like an obvious trap? More so in the case of the detail tag. Of course they might not be filtering on that sort of thing at all, after all there are many cases of content for humans being hidden that way until activated by script and they won't want to be filtering those out, so it doesn't actually matter and the key will be not showing the otherwise pointless content to human viewers.
There is a common accessibility pattern where the first tab focusable item is a "Skip to content" link in the top left corner. The link is initially hidden until you tab to it. That is the only use case I could think of when checking it out.
That's not what it's for, that's solved by showing the link when it's focused.
My guess is there was a desire to make Find-in-page automatically expand <details> elements and someone realized they could make it also work for custom disclosure widgets by giving the boolean attribute `hidden` an optional value.
On a big page with lots of collapsed content, I want control+f to search it and find anything in the collapsed sections without having to manually expand them all before I hit control+f
So you could use it for additional notes, things like "view pricing terms" or "show exclusions" on product listings — stuff people need to read only when they need to read it — without it being hidden from them if they search for it.
Though humans will accidentally find it too, so using a details tag with appropriate summary as a warning would be more friendly than just hidden content. It'll still get opened, but the user at least has a way of closing it again afterwards.
Also before using it I'd want to check what old UAs including accessibility tools tend to do when they hit a value that they don't recognise for the hidden="" attribute - would what they don't recognise as a valid value result in defaulting to the content being hidden or visible/read/other?
That it might look more like it is intended for human consumption where the others might get their content filtered out due to looking like an obvious trap? More so in the case of the detail tag. Of course they might not be filtering on that sort of thing at all, after all there are many cases of content for humans being hidden that way until activated by script and they won't want to be filtering those out, so it doesn't actually matter and the key will be not showing the otherwise pointless content to human viewers.
My guess is there was a desire to make Find-in-page automatically expand <details> elements and someone realized they could make it also work for custom disclosure widgets by giving the boolean attribute `hidden` an optional value.