- From: Emilio Cobos Álvarez via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Feb 2021 00:25:33 +0000
- To: public-css-archive@w3.org
So one thing that comes to mind regarding this, and which might not have been considered (or if it was, the explainer doesn't seem to say...), and which would: * Simplify the handshake that the page and the browser needs to do. * Remove the need to add new CSS property values or tie the page to use a particular way to hide / not hide the content. * Has existing precedents. Why not, instead of adding a per-match `beforematch` event which only fires on elements with a particular CSS property, we do a global pair of events like `beforeprint` / `afterprint` (`beforefind` / `afterfind`? Do we even need `afterfind`?) In those events, the page could unhide all the content that it wants findable (it could maybe even get the string to be found, perhaps? not sure). It seems like a simpler design, and similar to how pages adapt to print in other ways other than CSS. My reasoning for why this is likely better, even without the search string, is that all browsers have find-as-you-type kind of functionality, so in practice unless I'm missing something, beforematch is likely to actually match large parts of the document for find-in-page, when the user starts typing (and thus most of the content would be findable). Getting the string to be found is perhaps more appealing in the scroll-to-text-fragment use-case, though I assume that the way this feature has been designed is to prevent exposing the exact fragment, which would have privacy implications. But then again the page can observe what the user has searched for with `beforematch`, right? And anyhow, I don't think getting the query string is necessary, and it'd likely be better. @chrishtr I wonder if such a solution was considered and if so why was it discarded? At least for find-in-page, it seems like a much simpler solution. -- GitHub Notification of comment by emilio Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5595#issuecomment-776337961 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 10 February 2021 00:25:35 UTC