-
Notifications
You must be signed in to change notification settings - Fork 669
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
Comments
I could note there is mfreed7/declarative-shadow-dom#9 |
The CSS Working Group just discussed
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 |
Hi all, we propose putting cc: @sanketj |
@dandclark @tabatkins Does Stephanie's proposed syntax change seem reasonable to you? |
Yes, I think it's a reasonable change given the similarity to document.caretPositionFromPoint(). |
@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. |
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 |
RESOLVED: The |
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 usinghighlightsFromPoint()
.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 anincludeShadowRoots
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: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 howelementsFromPoint()
works in Blink and Gecko today, though the spec doesn't yet reflect thatelementsFromPoint()
is callable on shadow DOM and I see some cross-browser inconsistencies in which elements are returned.The text was updated successfully, but these errors were encountered: