[css-highlight-api] Is a HighlightPointerEvent type needed?

[dandclark]

In #7447 the CSSWG resolved to move forward with developing a spec for handling pointer events in Highlight API.

An initial decision to make about this is whether a new pointer event type is needed, like the following suggested in the MSEdgeExplainer:

interface HighlightPointerEvent : PointerEvent {
    readonly Range range;
}

The Highlight type would become an EventTarget so that developers can add listeners for these events.

[Exposed=Window]
interface Highlight : EventTarget {
  constructor(AbstractRange... initialRanges);
  setlike<AbstractRange>;
  attribute long priority;
  attribute HighlightType type;
};

With this approach, developers can add a single listener on a Highlight that will work for all Ranges in that Highlight group. The event handler can use the event's range field to determine which of its ranges was affected by the event.

An alternative is to have the Ranges receive the events directly. This would require developers to set events on every range, which is would be cumbersome if we generally expect all the ranges in a given Highlight group to share the same functionality. It's also not clear in that case how the event handler would know which Highlight a given Range was associated with. So, I think dispatching against Highlight makes more sense.

There are plenty of other open questions around how the event should be dispatched and how event pathing should work for highlights, but in this issue I'm hoping to reach some consensus around whether this basic conception of HighlightPointerEvent is the right approach or not.

cc @frivoal @luisjuansp

[css-meeting-bot]

The CSS Working Group just discussed Is HighlightPointerEvent needed?.

The full IRC log of that discussion

<fantasai> Topic: Is HighlightPointerEvent needed?
<fantasai> github: https://github.com//issues/7512
<fantasai> dandclark: if the solution we go with here involves highlight being an event target
<fantasai> dandclark: which either way I think will be the case
<fantasai> dandclark: who do I know which range was targetted?
<fantasai> dandclark: e.g. I'm a spell checker, but got a click, but which range was clicked?
<fantasai> dandclark: multiple ways to fix
<fantasai> dandclark: original solution maybe doesn't make sense, but if we do have some kind of intersects API then maybe that answers the question
<fantasai> dandclark: if we're re-using the existing pointer events, then [missed]
<flackr> q+
<fantasai> dandclark: call some kind of API, what were my intersection ranges?
<fantasai> dandclark: I need to know which ranges and which highlight
<fantasai> dandclark: perhaps API could be just onHighlight? similar to what ?? was proposing
<fantasai> dandclark: I add intersects() function to Highlight, it takes x,y and it returns a list of ranges in the highlight
<fantasai> dandclark: maybe that's the simplest
<fantasai> dandclark: highlight could potentially have several overlapping on the same text
<fantasai> dandclark: does that sound reasonable?
<fantasai> emilio: yes...
<GameMaker_> q+
<fantasai> emilio: given we already have a hit testing function that gives you list of highlights, maybe also takes ranges
<fantasai> emilio: I think this is related to previous issue
<fantasai> emilio: either way, if we go through event listener path or dom event thing, or the thing we were discussing
<fantasai> emilio: I'd rather resolve that first, even if it's not the final solution
<fantasai> emilio: maybe instead of sequence of highlights we need to return sequence of highlights and ranges
<fantasai> dandclark: sounds good, just want to make sure the problem is on the radar
<fantasai> flackr: I don't think we should have a specific event type, because I think ?????
<fantasai> flackr: prefer to have event that bubbles up. You dispatch to specific range, and then on the highlight you can check for which range
<fantasai> emilio: but target would be the DOM eleent
<dbaron> s/?????/we will want to target multiple types of events at highlights/
<fantasai> flackr: right, but ...
<dbaron> (I think)
<fantasai> emilio: but unsure about event target
<fantasai> emilio: [missed]
<fantasai> emilio: we may need to figure out a way... obviously, if we provide the API so that if we ? both highlights and ranges, the page could put the ranges property and expand all of the object
<fantasai> emilio: it's worth thinking about, but depends on other issues
<astearns> ack flackr
<astearns> ack GameMaker_
<fantasai> GameMaker_: I just want to make sure that when we're talking about ranges that highlights are done in abstract ranges, so keep that in mind
<fantasai> GameMaker_: make sure we remember they're AbstractRanges
<fantasai> emilio: you can build highlights with StaticRange and ??
<fantasai> GameMaker_: yeah, AbstractRange can be either
<fantasai> emilio: right
<dandclark> q?
<fantasai> astearns: anything else on this issue?
<fantasai> astearns: OK, we'll come back to both of these relatively soon
<dbaron> s/StaticRange and ??/StaticRange or Range/

[flackr]

I suspect that if you have multiple highlight ranges with different behavior that they should maybe be different highlight instances, in which case maybe CSS.highlights should support adding multiple highlight instances to a single named highlight, e.g. something like this:

// Get array of Highlight instances for found text.
let results = findText(text);
CSS.highlights.clear("find-highlights");
for (result of results)
  CSS.highlights.add("find-highlights", result);

This way the developer can attach behavior based on the particular find result, which in some cases may be based on additional context gathered from around the result.