Submitting this within the “Missed First Time Round” class. It popped up within the Firefox 139 launch notes and I used to be, like, ooo neat. Then I noticed it’s been in Chrome since at the least 2022. And as I wrote this, it landed in Safari Expertise Preview 125. So there you’ve gotten it.
Turns on the market are a couple of good posts and tutorials about hidden=until-found floating on the market, so I believed I’d jot down a couple of key takeaways for later reference.
It makes hidden content material “findable”
Quick story: Slapping hidden=until-found on a component in HTML allows any hidden content material inside the component to be findable within the browser with in-page search.
You’ll see, or extra precisely not see, that the content material is hidden with that in place:
It’s content-visibility: hidden underneath the hood
The browser takes that as a touch to cover the content material and does so by implicitly setting content-visibility: hidden on the component within the person agent kinds.
If we do a Ctrl+F on the keyboard to activate in-page search and enter a question, then a match reveals the content material, highlighting stated matched question.
Why we'd like this
That’s what I used to be asking myself once I began digging into this a bit of deeper. Probably the most distinguished instance of it getting used is from the Chrome for Builders docs as a faux-accordion. You recognize, a sequence of panels that open and shut on click on.
However isn’t {that a} solved deal now that we now have the
content-visibility: hidden on the ::details-content portion of the component that holds the content material.
I’m fairly positive
hidden=until-found launch). And Safari will presumably get there with Interop 2025. The instance from the Chrome for Builders publish demonstrates an strategy for working round a not-fully-supported
component and now we now have it.
So, why hidden=until-closed?
I don’t know. I’m positive there’s an excellent use case for hiding content material accessibly in some style whereas making it searchable. I simply can’t consider it off the highest of my head. I imply, we now have popover as effectively, however that takes a unique strategy with show: none which fully removes the content material from in-page search.
Browser assist and polyfill
We’ve already established that Chrome and Firefox are on board. Safari is the larger holdout, however understanding that making the hidden content material in
Within the meantime, although, is it price utilizing hidden=until-found? As a result of if we’re aiming for a constant cross-browser expertise, we’d have to do some form of swap between content-visibility: hidden to cover the content material and content-visible: auto to disclose it.
Nathan Knowler expertly explains the conundrum this creates. We are able to’t set content-visibility: hidden on one thing with out additionally eradicating it from in-page search. The hidden=until-found attribute works precisely like content-visibility: hidden however maintains that in-page search nonetheless works. In different phrases, we will’t polyfill the characteristic with content-visibility.
Thanks, Nathan, for taking place the large rabbit gap and discovering an answer that leverages the Shadow DOM to search for the HTML attribute, test assist, and revert its properties when wanted to accessibly cover the content material visually with out totally nuking it from being discovered.
Styling
Looks as if there isn’t a lot to say about styling one thing that ain’t seen, however discover that the in-page search characteristic highlights content material that matches the search question.
Seems to be like we could get a brand new ::search-text pseudo that enables us to pick the matched question and magnificence the spotlight colour within the CSS Pseudo-Parts Module Stage 4 specification, which is at the moment in Editor’s Draft standing on the time I’m penning this.
What about a number of matches? The present choice will get a unique spotlight from subsequent matches.
We’ll presumably, in keeping with the spec, have the ability to mix ::search-text with the :present pseudo-class to focus on the present match: ::search-text:present.
If you happen to’re pondering we would get to mix-and-match ::search-text with the corresponding :previous and :future pseudo-classes, I’m afraid the spec says nay. However it doesn't shut the door on it fully:
The
:previousand:futurepseudo-classes are reserved for analogous use sooner or later. Any unsupported mixture of those pseudo-classes with::search-textshould be handled as invalid.
Anything?
Probably not, however I do just like the notice on the finish of Christian Shaefer’s “Rethinking Discover-in-Web page Accessibility” publish that claims consideration wants to enter what occurs after a search question matches content material on the web page. At the moment, the content material stays seen even after in-page search is closed or canceled. Maybe we’ll want another HTML trace for that.
Hyperlinks
A dump of issues I discovered and used whereas researching this:
