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Β
:previousΒ andΒ:futureΒ pseudo-classesΒ are reserved for analogous use sooner or later. Any unsupported mixture of those pseudo-classes withΒ::search-textΒ shouldΒ 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:
