Intent to Ship: hidden=until-found HTML attribute and beforematch event

534 views
Skip to first unread message

Joey Arhar

unread,
Mar 17, 2022, 3:10:47 PM3/17/22
to blink-dev

Contact emails

jar...@chromium.org

Explainer

https://github.com/WICG/display-locking/blob/master/explainers/hidden-content-explainer.md

Specification

https://github.com/whatwg/html/pull/7475

Design docs

https://github.com/WICG/display-locking/blob/master/explainers/hidden-content-explainer.md

Summary

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>HTML

TAG review

https://github.com/w3ctag/design-reviews/issues/511

TAG review status

Issues addressed

Risks



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)

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2022-March/032142.html)

Web developers: No signals

Other signals:

Ergonomics

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.



Activation

This feature will benefit from having example code in the explainer repo to show developers how to use it.



Security

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?
No



Debuggability

There are no DevTools features for the scrolling, URL fragment, and event firing impacts that beforematch has.



Is this feature fully tested by web-platform-tests?

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

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.

Mike Taylor

unread,
Mar 22, 2022, 11:06:51 AM3/22/22
to Joey Arhar, blink-dev
LGTM1

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.


Yoav Weiss

unread,
Mar 23, 2022, 12:50:47 AM3/23/22
to blink-dev, Joey Arhar
LGTM2

On Thursday, March 17, 2022 at 8:10:47 PM UTC+1 Joey Arhar wrote:

Contact emails

jar...@chromium.org

Explainer

https://github.com/WICG/display-locking/blob/master/explainers/hidden-content-explainer.md

Specification

https://github.com/whatwg/html/pull/7475

Design docs

https://github.com/WICG/display-locking/blob/master/explainers/hidden-content-explainer.md

Summary

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>HTML

TAG review

https://github.com/w3ctag/design-reviews/issues/511

TAG review status

Issues addressed

Risks



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)

I'll just note that this is not yet the official label, although it seems like it's going that way.

Daniel Bratell

unread,
Mar 23, 2022, 11:25:53 AM3/23/22
to Yoav Weiss, blink-dev, Joey Arhar

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.
Reply all
Reply to author
Forward
0 new messages