Potentially standardize window.find()

[annevk]

See:

• https://www.chromestatus.com/metrics/feature/timeline/popularity/696 (currently 0.012% of page loads)
• https://bugzilla.mozilla.org/show_bug.cgi?id=672395
• https://bugs.webkit.org/show_bug.cgi?id=64761
• https://bugs.chromium.org/p/chromium/issues/detail?id=695564

Related #2858.

[js-choi]

Good news.

Is the scope of this issue simply to standardize window.find’s existing behavior in Firefox, WebKit, and Chromium? How does its matching work? Are Unicode code points matched with any normalization? Does case folding occur; if so, how? Can paragraph breaks and line breaks be matched, and by what characters? Is there any fuzzy search (e.g. between straight quotes and curly quotes as some browsers do on some systems)?

The answer to all of these probably will be: “What do current browsers do? Let’s stick with that,” but it’d be good to be explicit about the goal. And there may be some platform inconsistencies, especially in fuzzy matching.

See also Charmod Norm, w3c/selection-api#37, whatwg/dom#431, tc39/proposal-intl-segmenter#17, #2424, the inactive String Search API the inactive FindText API, and the inactive RangeFinder API.

[fred-wang]

For the record some browsers also implement a document.execCommand("FindString", ...) command.
https://w3c.github.io/editing/execCommand.html

[grantcv1]

I always find it distressing that counting the usage of public-facing websites is used to make decisions. In my experience, there are far more complex web applications with big companies and big governments that would not (should not) be included within these statistics.

window.find() is very much needed in editing style applications and there is a need for this feature (or a better alternative). Support for case folding, regular expressions, and other things that would help with a fuzzy search are really needed.

It seems that one possible effort to standardize this capability, the FindText API, (https://www.w3.org/TR/findtext/) has been discontinued :-(

[tilgovi]

One way to accommodate some of the goals of FindText without requiring standardization to take a stance on algorithm would be to specify how window.find interacts with Symbol.search (or other relevant, well-known symbols).

[vmpstr]

I'm not sure if this should be a separate issue, but my proposal to start the process of standardizing window.find by standardizing some of the aspects of find-in-page commonly used first. For instance,

1. Define terms like active match(?) vs potential match(?), meaning the thing that was found and highlighted vs the thing that could be found if the user or script continue searching for the same string
2. Perhaps also define how find-in-page interacts with things like clipped out content, and opacity 0 content, etc.

By starting with definitions, I think we can start thinking about how to define the algorithm. However for some features, it might already be useful to reference definitions of find-in-page (e.g. https://drafts.csswg.org/css-scroll-anchoring/#anchor-priority-candidates 2nd candidate is "an element containing the current active selected match of the find-in-page user-agent algorithm" which could reference this)

As an aside, I put together a brief overview of behaviors of find-in-page in different browsers (Chrome, Firefox, Safari) to see the commonalities and differences in behaviors. The doc uses find-in-page dialog, not window.find though.

Does this seem like a good approach?

[domenic]

my proposal to start the process of standardizing window.find by standardizing some of the aspects of find-in-page commonly used first.

Interesting.

This falls into a gray area of web specs, of specifying UI. Generally we try to shy away from that, and only specify things which are observable from JavaScript. I believe nothing about find-in-page is observable, so we normally wouldn't specify it.

However, sometimes we bend this rule, when it's especially beneficial, and all the browsers are interested.

I guess I would ask what is the goal here, and for who. Are you trying to make things more predictable for web page authors? In what way, since find-in-page is not observable? Are you trying to make things easier for implementers?

If the goal is purely to work on a better spec for window.find, then I would probably treat that orthogonally to find-in-page...

[vmpstr]

I guess I would ask what is the goal here, and for who

Good question. The immediate benefit from having the definitions is for spec writers and implementers so that they can agree what is meant by terms like 'active match' (e.g. the scroll anchor spec I linked, and beforematch proposal; the latter would benefit from the algorithm specified as well since the timing of the event and timing of find-in-page scroll are dependent on each other).

I think the ultimate benefit of at least partially speccing the algorithm is for users to have a consistent experience across browsers (although I'm not sure how valuable it is, since I imagine users don't typically switch browsers very often). That is, you can see in the compat doc I linked that browsers tend to do different things in a number of situations. In some cases, none of the browser seem to do "the right thing". For instance, content clipped by overflow hidden can be found on the three browsers I tested. It is conceivable that the spec here would dictate what should and should not be found, if that makes sense.

As an aside, I assume that window.find essentially hooks into the find-in-page algorithm (maybe this is a wrong assumption), so any kind of specification for it is likely to be very similar. To put it differently, I think if window.find is specified and browsers update their implementations to match the spec, I suspect that they will also have to change the find-in-page behavior to simplify the code.