Clarify relationships with other specs

[js-choi]

It’s wonderful to see concrete work being done in this space.

As an extension of #11, which is about whatwg/html#3539, I think it would also be good to add clarification about the relationships that this API has with the following prior art, particularly with the first issue below:

• Notify page that "find in page" is being used whatwg/html#2858 [Edit: Missed this already being already included in explainer as “1”]
• Charmod Norm
• Specify Selection.modify()? w3c/selection-api#37
• Range#expand() whatwg/dom#431
• Editorial: Refactor for normative reference by higher web specs tc39/proposal-intl-segmenter#17
• selectionStart/selectionEnd behavior needs to be specified whatwg/html#2424
• The inactive String Search API
• The inactive FindText API
• The inactive RangeFinder API

[domenic]

I'm not sure many, if any of these are related. Most of them seem to be about generic text or range processing, or just ideas that are not implemented. Could you explain why you think they would be related?

[js-choi]

On a second reading, I agree; they are not directly related; they are related only insofar that they might support custom searching of text from the DOM. I had been most concerned about whatwg/html#2858, but it had already been linked. Closing.

[js-choi]

Eventually, customization of the fuzzy text-matching rules that a UA uses (e.g., code-point normalization, case folding, other folding like curly/smart-quote folding, locale-specific customization) might be configurable from this API, in which case several of these prior initiatives might become more relevant.

[aphillips]

I agree that describing total support for all manner of Unicode normalization and find optimization is a good non-goal.

I suspect that this is missing the point, though. It isn't the customization of find() that is likely at issue but rather describing the actual options available. Most browser find commands (all of the ones I know of) have at least a "match case" option. That would affect the API of find-in-page. If other options are provided, they should be exposed in an orderly, forward-looking way. Saying what "match case" actually means might be an implementation detail.

The StringSearch document mentioned above is not wholly abandoned. But finishing CharmodNorm has been our higher priority. FindText is, to my understanding, moribund. Eventually it would be "nice" if some of these issues were dealt with (Unicode complexity does exist and does affect the outcome of a find, even if the result is by omission). But we should be careful not to throw out describing actual options, should they exist.