- From: Chris Harrelson via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Feb 2021 01:17:15 +0000
- To: public-css-archive@w3.org
> 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. I think your idea is: batch-unhide all the things and render them all at once whenever any of these algorithms run. And then once the find-in-page or scroll-to-fragment operation is done, leave things in the opened state. Is that correct? I'm not sure this works better. Here are reasons I can think of: * Performance: requires full rendering of everything. This would mean in particular page loads that use scroll-to-fragment would get a lot slower. Right now, Chromium's implementation only has to do style recalc (and even then it can be optimized further in the future). * Undesirable UX: sites may not want all sections or infinite-list content to be shown at once. For example, mobile Wikipedia would be much slower to scroll through (more gestures required) if all sections were opened at once, which is what would happen if you load the page with scroll-to-text or had just done a find-in-page. Or sites might have a UX that makes no sense to be "all open" - e.g. they have content in modal-like widgets. > 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). The point you make about lots of `beforematch` events firing has been raised before, in particular in the TAG review. I think a good way to solve it is to not fire the event on every keystroke, but instead at a slower rate, and/or only fire if there are enough characters typed to narrow the match sufficiently. > @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. No, what you propose here hasn't been considered as yet. -- GitHub Notification of comment by chrishtr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5595#issuecomment-776359802 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 01:17:17 UTC