search

WICG / scroll-to-text-fragment

Proposal to allow specifying a text snippet in a URL fragment
Other
589 stars 42 forks source link

Proposal: restrict matches to not span containment elements #89

Open chrishtr opened 4 years ago

chrishtr commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.