This feature extends the existing hidden attribute with a new value, "until-found", which makes the element searchable by find-in-page, scroll to text fragment, and fragment navigation. When these search/navigation features want to scroll to something inside a hidden=until-found element, the browser removes the hidden attribute from the element and fires the "beforematch" event on it so that the newly revealed content can be scrolled into view.
TAG review statusIssues addressed
Interoperability and Compatibility
This feature is built on content-visibility, which is gradually being implemented in other browsers. The way this feature extends the existing hidden attribute means that browsers which don't implement this feature will still render hidden=until-found content as expected, but without the new find-in-page and ScrollToTextFragment auto-revealing functionality. Mozilla says this feature is worth prototyping.
This feature is unlikely to break existing websites because they must opt-in by setting the "hidden" attributes on elements to "until-found".
In the unlikely event that existing websites use hidden=until-found, it will just replace their "display:none" with "content-visibility:hidden" which will likely render the same.Gecko
: Worth prototyping (https://github.com/mozilla/standards-positions/issues/612
: No signal (https://lists.webkit.org/pipermail/webkit-dev/2022-March/032142.html
: No signalsOther signals
This feature can be used in tandem with scroll to text fragments.
This feature will not make it hard for Chrome to maintain good performance.
This feature will benefit from having example code in the explainer repo to show developers how to use it.
What the user types into the find-in-page box should not be visible to websites, and the beforematch event is a new way for websites to try to read this information on top of the existing scroll events. I created a privacy mitigation for all of these attack surfaces for find-in-page by adding a delay before find-in-page scrolls text into view when needed so websites are unlikely to be able to incrementally build what the user is typing into find-in-page.
WebView Application Risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
There are no DevTools features for the scrolling, URL fragment, and event firing impacts that beforematch has.
The find-in-page portion of this feature can't be tested because find-in-page can't be tested in WPT yet: https://github.com/web-platform-tests/wpt/issues/29915
Here are some tests which I will try to move to WPT soon: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/display-lock/beforematch/
Here are WPTs for the hidden IDL changes to allow "until-found": https://github.com/web-platform-tests/wpt/pull/32465
Requires code in //chrome?False
Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5400510406328320
Links to previous Intent discussionsIntent to prototype: https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/beforematch%7Csort:date/blink-dev/QKUZ_ALJdM8/j6daEdmUAgAJIntent to Experiment: https://groups.google.com/a/chromium.org/d/msg/blink-dev/aTrk7__Eiq4/BOGSzGHeAwAJ