[css-highlight-api] Exposing shadow DOM highlights in highlightsFromPoint()

[dandclark]

The highlightsFromPoint() function, discussed here, should probably not return highlights in shadow DOMs by default. But, there should still be a way for authors to allow interaction with highlights in shadows using highlightsFromPoint().

I can think of two ways to have this function expose shadow DOM highlights.

The first is to handle it like getInnerHTML() does for Declarative Shadow DOM, in which it takes an includeShadowRoots option as well as a list of closed shadow roots. Highlights inside those shadows can be returned without breaking encapsulation, sinc the caller has proven that they already know about them: https://web.dev/declarative-shadow-dom/#serialization. Highlights could do something similar:

const hitTestResults = CSS.highlights.highlightsFromPoint({
  includeShadowRoots: true,
  closedRoots: [shadowRoot1, shadowRoot2, ...]
});

Alternatively, we could put highlightsFromPoint() on DocumentOrShadowRoot. When called on a Document, it would return only highlights in that document (not in its shadow roots). When called on a shadow root, it would return only highlights in that shadow, or perhaps highlights in that shadow plus highlights in the document (but not highlights in any nested shadow roots). This is analogous to how elementsFromPoint() works in Blink and Gecko today, though the spec doesn't yet reflect that elementsFromPoint() is callable on shadow DOM and I see some cross-browser inconsistencies in which elements are returned.

[smaug----]

I could note there is mfreed7/declarative-shadow-dom#9

[css-meeting-bot]

The CSS Working Group just discussed [css-highlight-api] Exposing shadow DOM highlights in highlightsFromPoint(), and agreed to the following:

• RESOLVED: Change highlights from point to work on document or shadow root with the intention of synchronizing how highlights and elements from point work. Open a new issue to harmonize the specs and doing the research

The full IRC log of that discussion

<dael> dandclark: This is about a highlight api v2 that we raised during tpac about making highlights interactive on scenarios like spellcheck and can click the word and handle an event knowing it was highlighted
<dael> dandclark: One issue during tpac was exposing highlights in shadow dom. Initial formulation was on css.highlights global. Don't want the api to return highlights in shadow. Alternative is follow example of point which can be called on document or shadow root and it gives elements under the coords on the shadow
<dael> dandclark: That seems like a close analog so should follow. Move highlights to be on document or shadow root.
<dael> dandclark: one wrinkle is point doesn't seem to say it's callable on doc or shadow roots. Seems to also be slight inconsistency between blink and geck about what can be returned if it's on shadow so some details to work out
<dael> dandclark: Still seems to be best to pursue
<dael> TabAtkins: Reasonable to me
<dael> astearns: Do you have an opinion about when this is called on shadow root d owe return light dom?
<dael> dandclark: Loose opinion is I would expect only return in the shadow dom. That seems most natural, but loosely help opinion
<dael> astearns: Other opinions?
<dael> astearns: Concerns?
<dael> TabAtkins: For question about light dom, are you thinking about slotted light dom into the shadow or arbitary overflow.
<dael> astearns: Thinking arbitary but slotted is right. I would expect slotted.
<dael> astearns: Definitely something to look into. I think I prefer the route of changing hightlights to work on either doc or shadow root
<dael> dandclark: Maybe resolve today to move to document and sharow root. Reality of browsers for point should be further investigated and we should match to that and agree what makes sense for both APIs. We can develop an opinion for both
<dael> astearns: I think point is our document; cssom view
<dael> astearns: Prop: Change highlights from point to work on document or shadow root with the intention of synchronizing how highlights and elements from point work. Open a new issue to harmonize the specs and doing the research
<dael> dandclark: Sounds right
<dael> astearns: Concerns?
<dael> astearns: Obj?
<dael> GameMaker: Since I've been doing highlights, want to say this seems to line up with things that will be okay
<dael> RESOLVED: Change highlights from point to work on document or shadow root with the intention of synchronizing how highlights and elements from point work. Open a new issue to harmonize the specs and doing the research
<dael> astearns: dandclark I may ask you to make point element edits as well

[stephanieyzhang]

Hi all, we propose putting highlightsFromPoint() on CSS.highlights, not DocumentOrShadowRoot, and adding an optional options dictionary parameter to the API. This dictionary has a key that maps to an array of ShadowRoot objects that can return highlights.
This approach is similar to how document.caretPositionFromPoint() and getHTML() interact with shadow DOM. Please let us know if there are any questions or concerns - thanks!

cc: @sanketj

[sanketj]

@dandclark @tabatkins Does Stephanie's proposed syntax change seem reasonable to you?

[dandclark]

Yes, I think it's a reasonable change given the similarity to document.caretPositionFromPoint().

[sanketj]

@astearns Do you think we can resolve async on the updates that @stephanieyzhang proposed here? There are deltas compared to what the working group has resolved on previously, but I think they are relatively minor.

[astearns]

The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.

Proposed Resolution: The highlightsFromPoint() method will be added to CSS.highlights, and have an optional options dictionary parameter matching the one from caretPositionFromPoint()