I want browser "find" features to emit window events

[aarongustafson]

First, disclosures suck. But they're everywhere. I'm looking at you tab panels, accordions, fly-outs, details elements, etc. “Readability mode” / “read aloud” features and extensions usually don’t expose the hidden information. If someone bothered with a print.css, then maybe you could see it there.

For example: go to this Web Accessibility Initiative demo and launch the print dialog. You won’t see the hidden content. But you would if you were on Inclusive Design Principles.

“Find in Page” won’t search or highlight the hidden content either. To find what you're looking for, you have to open everything on the page and then “find” again. Unless, of course, it’s a tab panel or a one-thing-open-at-a-time style accordion; for those you have to “find” with each exclusive panel open! This is especially frustrating when a search result says the page has certain content, but you can’t find it quickly using the built-in browser tools.

Now imagine that an event was triggered when users initiate “Find in Page,” but before the search is executed against the page. You could programmatically open all of the disclosures via JavaScript, allowing the browser to highlight every instance of the searched terms.

window.addEventListener('before-find', openAllDisclosures, false);

This could also be really useful for analytics, helping teams answer the question “what did the user expect to find on this page?” (Hint: the answer is your disclosures are still a bad idea, but at least I can prove it to you with analytics.)

---

https://webwewant.fyi/wants/5e666a97fade7fad65251e5e/

[aarongustafson]

This is an interesting one.

If I had window events for browser "find" actions, I could stop fighting designers and programmatically open the disclosures with JavaScript allowing the browser to highlight the newly found words.

Despite that it is asking for an event to be emitted when "Find in Page" is triggered, the focus of this seems to be more about making sure hidden contents (e.g., hidden tab panels) can be searched and highlighted too. Could we do a better job of this by automatically expanding and searching within widgets that use proper semantics to control what is visible (whether via HTML or ARIA)?

Would love to hear @melanierichards’ thoughts here.

This would also be of great importance to app analytics, helping teams answer the question "what did the user expect to find on this page?" (Hint: the answer is your disclosures are still a bad idea but at least I can prove it to you with analytics).

This bit, however, is problematic from a privacy perspective. We do not expose this information to developers today nor do I believe we would want to do that in the future. I would suggest they use one of those "did this page meet your expectations?" type widgets so disclosure is voluntary. They should already be able to glean some of this info anyway via search traffic analysis.

[AutoSponge]

Could we do a better job of this by automatically expanding and searching within widgets that use proper semantics to control what is visible (whether via HTML or ARIA)?

That doesn't help the dynamically rendered application where the hidden content hasn't been rendered. The browser can't predict what might be rendered when the disclosure opens. However, the app developer could--or send a query to the relevant database to provide contextual hints where the sought data can be found.

This bit, however, is problematic from a privacy perspective.

I'm not sure what the privacy issues would be. Every search engine can collect our searches for the whole internet (well beyond any direct concerns). As a developer trying to help my users get to the information they need effectively and efficiently, I want to know when "find on page" feature is triggered and with which string. I can't think of a word or phrase that would risk someone's privacy. It's really no different than github's search box or other domain-specific searches.

Without this feature, (or if it's implemented without the searched string), I could override the browser's "find" keystroke and implement a string-match in JavaScript against the view's backing data. I'd rather every developer using disclosures not need to do that.

[AutoSponge]

Following up on privacy: let's say there's 3rd party scripts on the page that we don't want to get these events, how can we isolate the information? I have some ideas but curious to hear what others come up with. (assume there's no CSP.)

[aarongustafson]

That doesn't help the dynamically rendered application where the hidden content hasn't been rendered.

Interesting. I hadn’t considered that the content may not exist to begin with. If that were the case though, it seems like you’d still create a UX issue even if there was such an event because the contents would need to be populated before the search could be conducted. Depending on how that is done (hopefully it’s not a network request), it could be a significant amount of time before the content were even available to be considered a part of the searchable text of the page, whether hidden or not. It seems like it would make more sense to inject the content—even async after paint—so it is available ASAP for inclusion in any search.

I’d also raise this as a potential problem that would prohibit use of Scroll To Text Fragment (and the similar Fragmentions concept).

I'm not sure what the privacy issues would be.

Here is some detail on privacy threat models. There are a ton of ways in which someone’s interaction with a page, particularly what they are searching on, could expose information they may not want to share and could divulge information they wish to keep private (e.g., health conditions). I don’t want to go too far down that particular rabbit hole, but I am flagging it as a concern. You might also consider taking a look @ the privacy considerations of Scroll To Text Fragment as related.

[AutoSponge]

@aarongustafson I forgot to assume the site would be tracking or fingerprinting the user. Yes, I see your point. Perhaps the page/app could declare some sort of "map" between the disclosure trigger and its data (HTML attributes, JSON structure in a script tag with a special type, RDF/microdata, etc.) describing undisclosed content. Native search can then supplement the JSON with the page's textContent and provide a richer search capability. That way, sites can keep their lazy render (in case it does require a server call or tons of elements).

[aarongustafson]

Perhaps the page/app could declare some sort of "map" between the disclosure trigger and its data (HTML attributes, JSON structure in a script tag with a special type, RDF/microdata, etc.) describing undisclosed content. Native search can then supplement the JSON with the page's textContent and provide a richer search capability. That way, sites can keep their lazy render (in case it does require a server call or tons of elements).

I’m not an engineer, but I think that would be a tough nut to crack (content that exists, but doesn’t exist). It seems like the lazy load of these contents would be best to run (for performance at least) as soon as there were free cycles in the browser (essentially like defer or async). Assuming there aren’t RAM implications—I need to check with my engineer friends for details of how children of hidden nodes impact RAM; I am almost positive they don’t impact paint—this would enable you to get the behavior you desire without an adverse effect on performance and without any delay in terms of the actual experience of Find in Page.

[myasonik]

Here to just broadly "plus one" this whole issue.

Could we do a better job of this by automatically expanding and searching within widgets that use proper semantics to control what is visible (whether via HTML or ARIA)?

Discussion on this seemed to quickly move to a bunch of areas where browsers couldn't solve all the issues which is true and will never go away but I'd love to see browsers get better at this in addition to emitting an event that lets developers do whatever custom work they need.

Even looking as native as the <details>/<summary> pairing, browsers can't handle showing that content was found inside the closed <details>. Little changes like this I think could shift developers to make smarter choices around semantics (I can see bugs being filed all over the place for things like "how come I can find within these tabs but not these?" that could push devs to build proper tabs for example).

[NickGard]

[a few years later...]

Instead of an event, what if there was a web API to register searchable content. It would take a callback that would make the content visible, however the developer needs to do that: dynamically render it, open a modal or disclosure. Example:

document.registerSearchContent(
  "this text appears in the currently hidden or unrendered element",
  function() {
    // Do imperative logic here to show the content
  }
);

This would leave the browsers in charge of doing searches and wouldn't expose exactly what phrase was searched. If the browser decides that the callback took too long or was trying to make cross-site calls, it could exclude that registered content from the final results.