beforematch: what to do when the element is no longer matching after callback.

[vmpstr]

Beforematch puts in a script callback before we scroll to whatever caused us to fire the signal (scroll-to-text, find-in-page, or fragment link navigation).

The question is what should we do if the conditions that caused us to find the match no longer hold after beforematch runs.

For example, in find-in-page case, the callback can:

• Add display: none to some ancestor
• Change text
• Move the node before/after other matches

We need to know how to handle all of those. Hopefully, whatever the decision, we can apply to other situations that we might not have thought of yet.

/cc @josepharhar @chrishtr @domenic

[josepharhar]

Some thoughts:

• find-in-page, ScrollToTextFragment, and ElementFragment each have their way of deciding to match something or not, maybe it would make sense to run that a second time after the beforematch event, perhaps based on what changes in css properties we see.
• If an element is display locked, we should fire the beforematch event on it. If the displaylock isn't removed, then it is an important for that use case that we don't scroll to it, right? In find-in-page, ScrollToTextFragment, and ElementFragment is it important to run another search again in this case?

[josepharhar]

I documented a bunch of current scrolling behavior here: #154

Another thought brought up in the PR: When we choose to scroll to a different element due to DOM/style changes in the beforematch handler, should said different element also get a beforematch event?
My gut feeling is yes, we should fire two events. At the moment, ScrollToTextFragment doesn't fire a second beforematch event when the target element changes due to the original target element being removed from the DOM.

[josepharhar]

Some more thoughts from @vmpstr: We should continue to fire events when the element we are trying to scroll to is changing, but we should limit it to like 10 to prevent infinite loops