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.
Interoperability risks: 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. Compatibility risks: 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.
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.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No
There are no DevTools features for the scrolling, URL fragment, and event firing impacts that beforematch has.
102
Please do. :)
Here are WPTs for the hidden IDL changes to allow "until-found": https://github.com/web-platform-tests/wpt/pull/32465
Flag name
--enable-blink-features=BeforeMatchEvent
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1055002
Launch bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1302408
Estimated milestones
102
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5400510406328320
Links to previous Intent discussions
Intent to prototype: https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/beforematch%7Csort:date/blink-dev/QKUZ_ALJdM8/j6daEdmUAgAJ
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msg/blink-dev/aTrk7__Eiq4/BOGSzGHeAwAJ
This intent message was generated by Chrome Platform Status.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwLpCZ3f7P8p%2B%2BsaoZkffffBXqRrqYN2%3DKvyEmiX6u0jYw%40mail.gmail.com.
Contact emails
jar...@chromium.orgExplainer
https://github.com/WICG/display-locking/blob/master/explainers/hidden-content-explainer.mdSpecification
https://github.com/whatwg/html/pull/7475Design docs
https://github.com/WICG/display-locking/blob/master/explainers/hidden-content-explainer.mdSummary
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.
Blink component
Blink>HTMLTAG review
https://github.com/w3ctag/design-reviews/issues/511TAG review status
Issues addressedRisks
Interoperability and Compatibility
Interoperability risks: 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. Compatibility risks: 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)
LGTM3
/Daniel
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5930d990-4a7c-4dea-8952-23bcb7d68e8dn%40chromium.org.