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

I noticed another problem in the case where the page has two or more highlighting libraries that don't coordinate with each other.
In this scenario, both libraries independently set this event listener in order to ensure that events get routed to their highlights:
```
document.addEventListener("click", function(e) {
  if (e.defaultPrevented)
    return;
  for (let { highlight, ranges } of CSS.highlights.highlightsFromPoint(e.clientX, e.clientY)) {
    e.ranges = ranges;
    highlight.dispatchEvent(e);
    if (e.defaultPrevented)
      break;
  }
  delete e.ranges;
});
```

If the `Highlight` event handlers for both libraries call `preventDefault`, then the `defaultPrevented` checking means we won't repeat the events. But if neither highlighting library wants to `preventDefault`, then each `Highlight` will get the event twice: once from each Document "click" handler set by each respective highlighting library.

It seems hard to get this right when there are multiple non-coordinating highlight libraries. I'd like to reconsider whether an approach that provides platform support closer to a traditional event path makes sense here:

> [when the user performs a pointer interaction over a highlight range], dispatch an event against the top-priority intersected 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. 

-- 
GitHub Notification of comment by dandclark
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7513#issuecomment-1208737552 using your GitHub account


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

Received on Monday, 8 August 2022 23:53:36 UTC