For the `beforeMatch` event we requested that if the website does not reveal `hidden-matchable` content in response to this event, sending the event be stopped for the reminder of the lifetime of the page. This was to prevent adding new ways of snooping on what the user types in the find-in-page box without any user-visible feedback; and in anticipation of a future world where the preexisting vectors of snooping have been mitigated.
However, back then, we were unsure if there exists a robust solution to verify that content actually got revealed in response to `beforeMatch`. There was some discussion about this on the TAG review thread, but I am not sure if we ended up finding a good approach. Do you think there is a viable technical enforcement here, for the <details> element? On Thursday, September 23, 2021 at 3:37:32 PM UTC+2 Mike Taylor wrote: > On 9/23/21 8:19 AM, Yoav Weiss wrote: > > On Thu, Sep 23, 2021 at 9:25 AM Thomas Steiner <to...@google.com> wrote: > >> Not sure this was discussed before, but could a new boolean attribute >> that opts the element in to the new behavior be the answer? >> >> <details *searchable*><!-- … --></details> >> > At the risk of jinxing UseCounter metrics > <https://bugs.chromium.org/p/chromium/issues/detail?id=690143#c21>, > another option would be to spec the `search` event such that > `preventDefault()` provides an opt-out here. > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/59f4ba04-6078-43a6-907d-a4921098128bn%40chromium.org.
