- From: Chris Harrelson via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Feb 2021 03:39:13 +0000
- To: public-css-archive@w3.org
> 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. Are you suggesting then to expose the find-in-page or scroll fragment text to the page? This could be a privacy problem. > > 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`. This is what the mitigation I mentioned is about. It would not fire the event if you type "a" if there are too many matches / "a" is too short of a string / it's been too little time since you typed another character. This would be something that is up to the UA to optimize. > With the search string exposed as part of the event, pages could decide which thing to show. Wouldn't this mean the site has to implement search themselves? Or would they use `window.find` (which we'd then write a spec for)? This also won't work for find-in-page unless there was an event provided to script to listen in on what is being typed. It's true that if you directly expose the find-in-page or search query text to script, then the script can be smarter about things. It can even do stuff like bringing in "search results" that are not even in the DOM at all (which I think is bad, for reasons of it not being good to keep semantic document state out of the document, as it messes up progressive rendering and accessibility goals in multiple ways). And as I mentioned there is a security / privacy problem. -- GitHub Notification of comment by chrishtr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5595#issuecomment-776416839 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 03:39:15 UTC