Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
dandclark opened this issue Sep 19, 2022 · 8 comments

Comments

@dandclark
Copy link
Contributor

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----
Copy link

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

@css-meeting-bot
Copy link
Member

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
Copy link

stephanieyzhang commented Jul 29, 2024

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
Copy link
Member

sanketj commented Aug 9, 2024

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

@dandclark
Copy link
Contributor Author

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

@sanketj
Copy link
Member

sanketj commented Aug 30, 2024

@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 astearns added the Async Resolution: Proposed Candidate for auto-resolve with stated time limit label Aug 30, 2024
@astearns
Copy link
Member

astearns commented Sep 3, 2024

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()

@astearns astearns added Async Resolution: Call For Consensus Resolution will be called after time limit expires and removed Async Resolution: Proposed Candidate for auto-resolve with stated time limit labels Sep 3, 2024
@astearns
Copy link
Member

astearns commented Sep 9, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants