WICG / scroll-to-text-fragment

Proposal to allow specifying a text snippet in a URL fragment

Other

589 stars 42 forks source link

Specify behavior on hidden and display:none text #69

Closed bokand closed 4 years ago

bokand commented 4 years ago

The behavior we've found useful is that visibility:hidden or display:none text that we find in the DOM should be matched but not scrolled into view. That way, if the page makes it visible after load it is indicated.

One use case we're thinking of here is mobile Wikipedia. If the link has a classic element-id fragment so that it expands a section based on page script, we want the highlight to still appear. In these cases, we don't want to scroll-into-view though.

We need to make sure this is precisely specified.

tilgovi commented 4 years ago

That sounds good.

I'm looking at the draft specification and not seeing any mention of transparent elements. Is it the case that the text content of script et al are included in the search, or is there a reference to visible text somewhere that encompasses the notion of skipping these elements?

nickburris commented 4 years ago

I think transparent elements shouldn't be matched (not scrolled or indicated in any way). I'll be sure to include this case when clarifying hidden text matching in the spec. Thanks!

bokand commented 4 years ago

90 specifies this explicitly.

I think we've since settled that display-locking will be a more reliable way to deal with things like expandos (and the experimental display-locking implementation already works with text fragments!) so hacking in special-cases for hidden->unhidden elements as I mention at the top seems not worth the cost.