- From: Emilio Cobos Álvarez via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Feb 2021 01:46:16 +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? Sorta. If the page doesn't have access to the search string / fragment directive / etc, then yes, it can only unhide ~everything and pray. But if it does have access to it (which might be a reasonable thing...) then the page can decide what to show or what not. > Undesirable UX: sites may not want all sections or infinite-list content to be shown at once. [...] Or sites might have a UX that makes no sense to be "all open" - e.g. they have content in modal-like widgets. Right, but those are also existing issues (for find-in-page, at least) with this proposal, right? As in, that's what happens if you do a find in page and type e.g. the "a" character with beforematch, right? (Assuming nearly all sections of a wikipedia article are going to have an "a" character around). The modal widget thing has also the same issue with `beforematch`. With the search string exposed as part of the event, pages could decide which thing to show. -- GitHub Notification of comment by emilio Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5595#issuecomment-776371549 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:46:19 UTC