#7512 discusses whether a new pointer event type should be added for use with Highlights. A related task is to develop the details about how pointer events should be dispatched to highlights.

It's important to consider what should happen if there are multiple overlapping highlights. Consider for example an in-page editor implementing find-on-page, where a spell-checking extension is also running. Both might have actions they want to take when the user clicks a highlighted range, for example the find-on-page might want to change the color of the clicked word and update the selection, and the spell-checker might want to show a popup with spelling suggestions. When the spell checker decides to show its popup, it might be reasonable to allow it to block actions that another highlight type might take (like updating find-on-page highlight colors or selection).

With that in mind, there are a few potential approaches for what to do when a user interacts with (potentially overlapping) highlighted content.

Approach A: Dispatch a separate event against each Highlight under the cursor, in descending priority order.

Additionally, we could define the default action of each event to be the generation of the event for the next Highlight. This way, a Highlight's event handler can call preventDefault and prevent events from reaching subsequent Highlights.

It is a bit suspicious to potentially fire an arbitrary number of pointer events for a single user interaction, but this might be fine.

Approach B: Dispatch a single event against the top-priority highlight, whose event path includes any overlapping highlights in descending priority order, followed by the containing element and its parents.

There's a web compatibility problem with this one. Currently a PointerEvent's target can only be an element, so PointerEvent handlers will probably expect this and encounter problems if they receive an event whose target is a Highlight.

The MSEdgeExplainer proposes a variation of Approach B that works around this by setting the event's target to the element rather than the Highlight, even though the event path is ordered as if the Highlight is the target. But as @smaug---- points out at MicrosoftEdge/MSEdgeExplainers#588, this raises its own questions about how eventPath would work.

I'm also interested in a potential combination of Approach A and Approach B, where we dispatch exactly two events per user action. Firstly, dispatch an event against the top-priority highlight such that the event path includes any overlapping highlights in descending priority order. Secondly, the "normal" pointer event is dispatched against the originating element. In this case we could consider defining preventDefault on the highlight-dispatched event to prevent the subsequent dispatch of the "normal" pointer event. This approach seems to avoid a lot of the difficulties around Approach A and Approach B separately, and allows a great deal of flexibility in how Highlights can prevent propagation to lower-priority highlights and to the page content.

cc @frivoal @luisjuansp