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

>> 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?

No, I mean the site's custom find-in-page feature might have bugs and not work. If the site has hijacked the browser UI's find-in-page (by `preventDefault`-ing it), then you're left with nothing. :( This happened at the TAG meeting when using CryptPad, which tries to do this, but it's site-specific find feature was broken in the browser we were using. Oops.

> We are not allowing the site to hijack the browser's UI (power users can choose to force usage of browser's UI).

Oh, then perhaps I was misunderstanding this [use case from the explainer](https://github.com/rakina/find-in-page-api/blob/master/README.md#use-case)?

>A web page has a completely custom way of loading data, and they want to provide a completely custom search UI. They can do this by adding an event listener for `openfind` Event, and calling `preventDefault()` on it, and then show their search UI instead.

I presumed "instead" meant in place of the browsers native UI. If you don't intend to prevent the browser UI from hiding, then I suppose many of my follow-on comments are invalid. If invoking `preventDefault()` is not for that purpose, what is it for?



-- 
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-380270181