Re: [w3ctag/design-reviews] Find-in-page API(s) (#236)

Thanks for the comment!
> In all of these cases, (via the keyboard) the website has the option to block the user experience. Sadly, sites can not be expected to always provide some equivalent functionality, which leads to user frustration (e.g., e.preventDefault() in your example, but no other code to enable a site-specific find + focus--or worse, the code is there, but doesn't work properly).

I don't quite understand this part. Do you mean that some site's custom find-in-page features might not offer the same functionality as other sites? 

> However, I disagree with the premise that the site should be able to hijack the browser's UI. 

We are not allowing the site to hijack the browser's UI (power users can choose to force usage of browser's UI). Instead, we're saying that the browser's default find-in-page UI should become similar to the browser's default back button UI, where (due to the introduction of APIs like the [HTML History API](https://developer.mozilla.org/en-US/docs/Web/API/History_API)) there's a default behavior, but also a way to interpose your own behavior when the default behavior doesn't make sense for your page's content.

> When there is visible text on the screen, and the user activates find-on-page, they expect to use the Browser's find service to locate that visible text.

Our API is specifically targeted at cases where that's not currently possible. There are a lot of sites today for which the browser UI is broken and not a consistent experience. Any site where the user's notion of the page's content doesn't map 1:1 to the web developer's notion of the DOM is like this. That includes sites that use virtualization, load contents lazily, or display text on a canvas, etc.

> Furthermore, the use of an event, while the appropriate metaphor, is also a synchronous construct--I imagine while the event handler code is running, the expectation is that the browser would delay showing it's UI. This is intensely problematic as this enables a user-experience hang if the web page takes too long to respond (e.g., the code in the event handler is too slow/complicated). A non-blocking or asynchronous solution would be needed (but is also tricky assuming you want a "before"-style event).

We don't intend to hang the page in any way, at least, no more than normal JavaScript is able to at any time (without involving events at all).

> Another potential problem with the design is figuring out what the timing of the event should be. Naively, it seems that the event would fire when the user invokes the find-on-page UI and that UI is not previously showing. However, often the UI is persistent and the key combinations for find-on-page (Ctrl+f) is used to re-focus the browser's "find" input box for follow-on searches. Should the event fire in these cases? What happens when the persistent UI is enabled, and the user switches tabs? Does the event fire immediately after tab-switch in the new tab? Is another event needed when the UI is disabled/cancelled, in order to keep the experience consistent with the browser's UI?

These are good questions and we are going to think about these questions, though some of them seems to be more of a browser-specific UI concern, which we don't want to constrain from the spec. 

> I prefer a model where the Browser's find-on-page and the web page's find service can work together without having to compete. While a complicated form of that scenario is out-of-scope (as noted in the explainer) a much simpler design could still be in-scope. For example, the web application could use the openfind event both as a trigger to enable page-specific find services, and also as a mechanism for the Browser UI to discover that the web page has a find service and, at a minimum, advertise this fact in it's UI. This, coupled with the inability to block the browser's UI, will ensure a consistency of user experience from the browser POV, and enable a service-discovery entry-point for the page's find service. Would love to see more exploration of something along these lines...

This model is interesting, but this is more related to Browser's UI. Some browsers may want to use them in that way, or maybe some other way by utilizing the APIs, but we shouldn't have the spec constrain browsers and how they implement their UI.

cc @domenic  

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/236#issuecomment-379700816