Hello TAG!

I'm requesting a TAG review of the beforematch event.

The beforematch event allows developers to display content to the user in response to the following actions:

• find-in-page (ctrl+f)
• element fragment navigation (example.com/#foo)
• scroll-to-text navigation (example.com/#:~:text=foo)

The event is fired at render timing before these actions scroll the page. The event is fired on the element which contains the text, or in the case of element fragment navigation, whichever element has the target id.

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/display-locking/blob/master/explainers/beforematch.md
• Security and Privacy self-review²: https://github.com/WICG/display-locking/blob/master/beforematch-security-and-privacy-assessment.md
• GitHub repo (if you prefer feedback filed there): https://github.com/WICG/display-locking
• Primary contacts (and their relationship to the specification):
  • Joey Arhar (@josepharhar), Google, Author
  • Vlad Levin (@vmpstr), Google, Author
• Organization/project driving the design: Google
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://www.chromestatus.com/feature/5400510406328320

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
• Existing major pieces of multi-stakeholder review or discussion of this design: https://github.com/WICG/display-locking/issues
• Major unresolved issues with or opposition to this design: beforematch: what to do when the element is no longer matching after callback. WICG/display-locking#150
• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback