Covering hidden=until-found | By The Digital Insider

Filing this in the “Missed First Time Around” category. It popped up in the Firefox 139 release notes and I was, like, ooo neat. Then I saw it’s been in Chrome since at least 2022. And as I wrote this, it landed in Safari Technology Preview 125. So there you have it.

Turns out there are a few good posts and tutorials about hidden=until-found floating out there, so I thought I’d jot down a few key takeaways for later reference.

It makes hidden content “findable”

Short story: Slapping hidden=until-found on an element in HTML enables any hidden content within the element to be findable in the browser with in-page search.

<div hidden="until-found">
 <!-- hidden content -->
</div>

You’ll see, or more accurately not see, that the content is hidden with that in place:

It’s content-visibility: hidden under the hood

The browser takes that as a hint to hide the content and does so by implicitly setting content-visibility: hidden on the element in the user agent styles.

If we do a Ctrl+F on the keyboard to activate in-page search and enter a query, then a match reveals the content, highlighting said matched query.

Why we need this

That’s what I was asking myself when I started digging into this a little deeper. The most prominent example of it being used is from the Chrome for Developers docs as a faux-accordion. You know, a series of panels that open and close on click.

But isn’t that a solved deal now that we have the <details> element at the ready? May as well use a semantic disclosure widget to, you know, disclose content. Indeed, browsers also set content-visibility: hidden on the ::details-content portion of the element that holds the content.

I’m pretty sure <details> was not as widely supported in 2022 as it is today. It’s actually part of Interop 2025 and notice that one of the functionalities mentioned is the capability for in-page search. Chrome already supports it. Firefox recently shipped it (ostensibly as part of the hidden=until-found release). And Safari will presumably get there with Interop 2025. The example from the Chrome for Developers post demonstrates an approach for working around a not-fully-supported <details> element and now we have it.

So, why hidden=until-closed?

I don’t know. I’m sure there’s a good use case for hiding content accessibly in some fashion while making it searchable. I just can’t think of it off the top of my head. I mean, we have popover as well, but that takes a different approach with display: none which completely removes the content from in-page search.

Browser support and polyfill

We’ve already established that Chrome and Firefox are on board. Safari is the bigger holdout, but knowing that making the hidden content in <details> findable is part of Interop 2025 (and Firefox’s corresponding support for it as part of that effort) makes me think it’s around the corner. (Turns out that hunch was correct because it landed in Safari Technology Preview 125 after writing this.)

In the meantime, though, is it worth using hidden=until-found? Because if we’re aiming for a consistent cross-browser experience, we’d need to do some sort of swap between content-visibility: hidden to hide the content and content-visible: auto to reveal it.

Nathan Knowler expertly explains the conundrum this creates. We can’t set content-visibility: hidden on something without also removing it from in-page search. The hidden=until-found attribute works exactly like content-visibility: hidden but maintains that in-page search still works. In other words, we can’t polyfill the feature with content-visibility.

Thanks, Nathan, for going down the massive rabbit hole and finding a solution that leverages the Shadow DOM to look for the HTML attribute, check support, and revert its properties when needed to accessibly hide the content visually without fully nuking it from being found.

Styling

Seems like there isn’t much to say about styling something that ain’t visible, but notice that the in-page search feature highlights content that matches the search query.

Looks like we may get a new ::search-text pseudo that allows us to select the matched query and style the highlight color in the CSS Pseudo-Elements Module Level 4 specification, which is currently in Editor’s Draft status at the time I’m writing this.

What about multiple matches? The current selection gets a different highlight from subsequent matches.

We’ll presumably, according to the spec, be able to combine ::search-text with the :current pseudo-class to target the current match: ::search-text:current.

If you’re thinking we might get to mix-and-match ::search-text with the corresponding :past and :future pseudo-classes, I’m afraid the spec says nay. But it does not shut the door on it completely:

The :past and :future pseudo-classes are reserved for analogous use in the future. Any unsupported combination of these pseudo-classes with ::search-text must be treated as invalid.

Anything else?

Not really, but I do like the note at the end of Christian Shaefer’s “Rethinking Find-in-Page Accessibility” post that says consideration needs to go into what happens after a search query matches content on the page. Currently, the content remains visible even after in-page search is closed or canceled. Perhaps we’ll need some other HTML hint for that.

Links

A dump of things I found and used while researching this:

#2022, #2025, #Accessibility, #Agent, #Approach, #Articles, #Attributes, #Board, #Browser, #Chrome, #Classes, #Color, #Content, #CrossBrowser, #CSS, #CssTricks, #Deal, #Details, #Developers, #Digitalocean, #Display, #Fashion, #Firefox, #Future, #HTML, #Indeed, #It, #Keyboard, #Links, #Module, #Newsletter, #Notes, #One, #Other, #Popover, #Query, #Safari, #Search, #Shadow, #ShadowDom, #Styles, #Technology, #Text, #Thinking, #Time, #Tutorials, #Us, #Visibility, #Writing

---

Published on The Digital Insider at https://is.gd/ArEjv3.