Re: [w3ctag/design-reviews] Display Locking (#306)

Just to clarify your last point here, do you mean that it _already should fire_ on find-in-page and scroll-to-text, or that we _should update `hashchange` spec_ so that it fires on find-in-page and scroll-to-text?

When considering find-in-page specifically, which is a primary  use case for us, I think it would be somewhat awkward to have `hashchange` fire on a find-in-page match (mostly since the hash part of the URL doesn't change). In order to satisfy our use case, it would also have to fire on the element that contains the find-in-page match text (as opposed to on the window), which adds to the awkwardness in my opinion.

I think we can safely drop fragment-link navigation (ie #id navigation) from `beforematch` since that can be handled by `hashchange` for sure. Although in my mind it still feels like it is useful to include it in `beforematch`.

-- 
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/306#issuecomment-594161856