[csswg-drafts] [css-highlight-api] Approaches for dispatching highlight pointer events (#7513)

dandclark has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-highlight-api] Approaches for dispatching highlight pointer events ==
#7512 discusses whether a new pointer event type should be added for use with `Highlight`s. 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 `Highlight`s.

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 ](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/highlight/events-explainer.md#proposal) 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 https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/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, an event against the top-priority highlight whose event path includes any overlapping highlights in descending priority order. Secondly, the "normal" pointer event 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

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7513 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 19 July 2022 00:01:49 UTC