Re: [w3ctag/design-reviews] Scroll To Text (#392)

I wrote:

> > I'm a bit worried about interop here. Are you effectively requiring all browser engines to use ICU? If not, how can we ensure interoperability in a world where the word dictionary isn't specified / standardized? This is especially concerning given that the quality of word boundary analysis directly affects the efficacy of a security mitigation in this spec.

@nickburris replied:

> We improved our spec on word boundary matching based on your feedback and discussion with @domenic: https://wicg.github.io/ScrollToTextFragment/#next-word-bounded-instance

This is definitely an improvement, thanks. I have more specific thoughts about the non-normative note beginning "Limiting matching to word boundaries," which are below. With the following changes, I'd be happy with this text.

> Limiting matching to word boundaries is one of the mitigations to limit cross-origin information leakage.

It makes sense for this to be a non-normative note, though not as a note under step 4 of the algorithm. Consider moving?

> A word boundary is as defined in the Unicode text segmentation annex.

This should be normative text, not in a note, and it should be somewhere other than step 4 of the algorithm.

> The Default Word Boundary Specification defines a default set of what constitutes a word boundary, but as the specification mentions, a more sophisticated algorithm should be used based on the locale.
>
> Dictionary-based word bounding should take specific care in locales without a word-separating character (e.g. space). In those cases, and where the alphabet contains fewer than 100 characters, the dictionary must not contain more than 20% of the alphabet as valid, one-letter words.

This contains normative requirements, and thus should be in normative text, somewhere other than step 4 of the algorithm.

-- 
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/392#issuecomment-561836753

Received on Wednesday, 4 December 2019 21:00:57 UTC