[css-highlight-api] Incubating custom highlight pointer event handling in CSSWG

[dandclark]

Back in 2019 @sanketj posted a doc on the MSEdgeExplainers repo proposing an addition to Highlight API that would allow custom highlights to receive pointer events: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/highlight/events-explainer.md. This would make highlights interactive, unlocking useful scenarios like custom spell-checking where hovering or clicking a misspelled word shows spelling suggestions, or highlighted annotations that scroll-into-view and/or update the user's selection when clicked.

The Highlight API spec has matured significantly since then, and it is on the verge of shipping by default in Chromium. Thus it seems like this is a good time to move forward with this enhancement of the spec.

Would the CSSWG be interested in being the venue for incubating/specifying Highlight pointer events? This would have more DOM integration than the base Highlight API, but given the momentum that Highlight API has had here so far it seems like CSSWG is a good place to develop this.

If so, I'll start by moving some Highlight pointer events issues in the MSEdgeExplainers repo over to csswg-drafts and begin proposing some solutions.

cc @frivoal

[css-meeting-bot]

The CSS Working Group just discussed [css-highlight-api] Incubating custom highlight pointer event handling in CSSWG, and agreed to the following:

• RESOLVED: Incubate this in CSSWG
• RESOLVED: Create a highlight L2 spec, dandclark is an editor

The full IRC log of that discussion

<emilio> topic: [css-highlight-api] Incubating custom highlight pointer event handling in CSSWG
<emilio> github: https://github.com//issues/7447
<emilio> dandclark: Highlight API had some progress these last couple years
<emilio> ... but no progress to be able to interact w/ highlights
<emilio> ... common use case is spellcheck
<emilio> ... there's no way to interact with highlighted ranges
<emilio> ... so a super useful addition would be to add pointer events to highlighted ranges
<florian> q+
<emilio> ... there's various ways to determine how they'd be routed etc
<emilio> ... but I wanted to check whether this is the right place for this, since this is a bit more DOM-y
<emilio> ... some first steps would be moving some issues from the MSEdgeExplainers repo to CSSWG
<emilio> ... we can do some spec PRs and prototyping
<astearns> ack florian
<emilio> florian: I think the use cases are numerous and compelling, and proposed API looks pretty good at first sight
<emilio> ... there are a number of interesting questions: things like dealing with overlapping ranges, and how to dispatch to the DOM in general
<TabAtkins> Agree the use-cases for the feature are good and worth developing. Fine with this group taking on the work; we do DOM-ish stuff sometimes, and it feels reasonable to handle this in the same group as the rest of the CSS feature.
<emilio> florian: the other similar thing that comes up is other pseudo-elements
<emilio> ... is this a missed opportunity to fix that too?
<emilio> ... anyways I think the best thing to do is bringing it in-group
<emilio> astearns: is csswg the only place you have considered bringing in?
<emilio> q+
<emilio> dandclark: for now csswg, but we possibly also want to raise a tag review and other groups like whatwg
<fantasai> emilio: My first question is whether, there's a Selection and Editing API WG, which already has a buch of interop problems to solve
<fantasai> emilio: Other question is, do we really need to dispatch new events on these, or can we re-use the existing machinery?
<fantasai> emilio: [missed]
<fantasai> emilio: I don't know whether StaticRange has it as well
<fantasai> emilio: there are ways to check interaction of pointer events
<fantasai> emilio: It seems to me there's some other areas where this could benefit from, other groups that could also help here
<fantasai> emilio: especially editingWG
<fantasai> emilio: lots of interaction with ShadowDOM and stuff
<emilio> s/missed/add a convenient way to check whether an event intersects with a highlight
<fantasai> dandclark: [missed]
<fantasai> dandclark: But would think it's good to start here in CSSWG
<fantasai> astearns: Emilio, any objection to starting here?
<fantasai> emilio: no objection
<fantasai> astearns: Any other comments
<fantasai> astearns: I suggest we take this as an incubation in the CSSWG, noting that it's merely an incubation
<emilio> astearns: objections?
<emilio> RESOLVED: Incubate this in CSSWG
<emilio> dandclark: there's a section in the existing draft about this, which is just a missing section
<emilio> ... do we want to put it there?
<emilio> astearns: seems like a reasonable place to start?
<emilio> fantasai: do we want to put it into a L2 spec instead? Seems like highlight API is relatively stable
<emilio> florian: was about to suggest the same
<chris> A level 2 diff spec seems a better way, agreed
<emilio> dandclark: that works for me, might have some follow-up questions about process
<hober> present-
<emilio> astearns: who's the current editor?
<emilio> florian: I'm one of them
<GameMaker> I'm the third editor
<emilio> fantasai: there's 5 open issues on L1, we should consider trying to fix them and move to CR
<emilio> astearns: dandclark, would you want to be an editor of L2?
<emilio> dandclark: sure
<emilio> RESOLVED: Create a highlight L2 spec, dandclark is an editor
<TabAtkins> ol' D&D Clark, as I always read it

[fabiospampinato]

This would be super useful for code editor use cases and much more.