Proposal: restrict matches to not span containment elements

[chrishtr]

As currently specified, it appears a text fragment identifier can match elements across a very wide swath of DOM, including the entire document, in one match. WICG/display-locking#125 on the display locking repo gives a real-world example where the match is very broad.

That issue also describes why this is a problem for semantics and usability of the beforematch event. It may also be a usability issue of scroll to text fragment, because the scroll will not show the entire match.

I propose that text fragment identifiers not be allowed to cross elements with contain: style layout. This specific restriction is chosen to match semantics of subtree-visibility, and resolve WICG/display-locking#125. Additional restrictions for other types of layout may be appropriate as well.

/cc @bokand @nickburris

--

One potential concern was raised by @vmpstr when discussing this proposal offline, which is that a site could "opt out" of scroll to text fragment by putting every word in a contain: style layout div. However, I don't think this is a significant problem because (a) I don't think it's a problem to worry about if sites go out of their way to avoid text fragments via extreme hacks, and (b) the site will have poor performance and layout behavior if they attempt it.

[bokand]

I'd need to familiarize myself more with beforematch and contain:style layout but off hand it doesn't sound unreasonable. We'd have to be a little careful here as users are able to select text across these boundaries. The goal is that they'd be able to easily create a link to arbitrary text selections. If we restrict it, we have to find some UI to explain why the selection can't be linked to which is challenging given the UI constraints of a context menu. Cross-element matching was an explicit goal of ours.

Is contain: style layout just author-added or is this something that's also implicit in other circumstances?

a site could "opt out" of scroll to text fragment by putting every word in a contain: style layout div.

We're adding an explicit opt-out in #80 so I don't think we have to worry about this.

[chrishtr]

Is contain: style layout just author-added or is this something that's also implicit in other circumstances?

It's usually author-added, but is also a side-effect of specifying subtree-visibility.