-
Notifications
You must be signed in to change notification settings - Fork 55
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
document.caretPositionFromPoint API in shadow DOM scenario #949
Comments
@siliu1 have you reviewed the design principles? |
I reviewed the spec change, but did not write it. |
Updated description based on above feedbacks. |
Hi there, We looked at this during a breakout today. First, the purpose of the explainer is not just to assist in TAG review, but to provide an overview of what the spec does, why it’s needed, and why it’s designed that way, for everyone. Including an explainer in the TAG review issue does not help with that. Second, one of the most important sections of the explainer is user needs. Here there are none. Getting the caret position is not a use case, it’s a solution. Why do they need to get the caret position? This is essential for evaluating the design. For example, if addressing the common use cases requires getting all shadow roots in a document and passing them to this function, the ergonomics are suboptimal, since the developer would have to query all elements, traverse them to see which ones have an open shadow root, then pass them to the function: let shadowRoots = [];
for (let el of document.querySelectorAll("*")) {
if (el.shadowRoot) shadowRoots.push(el.shadowRoot);
}
let pos = document.caretFromPoint(x, y, shadowRoots); But if it’s not common to need to do it in such a sweeping manner, but more targeted to a few shadow roots, it may be acceptable to provide them explicitly. Without a good set of use cases, we simply cannot know. The Do note that we advise against optional parameters being positional, and recommend a dictionary instead which both makes function calls self-explanatory and affords room for future expansion. As an example, one possible design could be to make the parameter a dictionary with a We also noticed that |
Hi Lea, Thank you for the review. The latest spec of this API has been changed to take a dictionary with Regarding the open shadow roots vs. closed shadow roots, there is an existing API |
Thank you for being responsive to our feedback. Indeed, consistency is a good point, though depending on the use cases, it could end up being a good choice to change both of these methods. Therefore, it would still be good to list use cases (starting with user needs). Nevertheless, we see a It's great to see support from additional implementers. We’re going to go ahead and close this. Thank you for flying TAG! |
…M behavior r=webidl,smaug,emilio Spec - https://drafts.csswg.org/cssom-view/Overview#dom-document-caretpositionfrompoint Spec PR - w3c/csswg-drafts#10200 TAG Review - w3ctag/design-reviews#949 Differential Revision: https://phabricator.services.mozilla.com/D215184
…M behavior r=webidl,smaug,emilio Spec - https://drafts.csswg.org/cssom-view/Overview#dom-document-caretpositionfrompoint Spec PR - w3c/csswg-drafts#10200 TAG Review - w3ctag/design-reviews#949 Differential Revision: https://phabricator.services.mozilla.com/D215184
…M behavior r=webidl,smaug,emilio Spec - https://drafts.csswg.org/cssom-view/Overview#dom-document-caretpositionfrompoint Spec PR - w3c/csswg-drafts#10200 TAG Review - w3ctag/design-reviews#949 Differential Revision: https://phabricator.services.mozilla.com/D215184
こんにちは TAG-さん!
I'm requesting a TAG review of document.caretPositionFromPoint API in shadow DOM scenario.
The document.caretPositionFromPoint returns a CaretPosition which represents the caret position indicating current text insertion point. However, the current spec is vague about the behavior in shadow DOM scenario. The proposal attempts to specify the behavior in shadow DOM.
shadowRoots
parameter tocaretPositionFromPoint
API. w3c/csswg-drafts#10200Further details:
[1] document.caretPositionFromPoint in shadow DOM scenario explainer:
Use case/developer need
It's necessary for web developers to have a method to determine the caret position within shadow roots. This allows for indentifying node
and offset within the shadow root so that range/selection creation is possible in shadow root at specific point.
With the proposal, web developer can get caret position inside shadow root like:
Background
The document.caretPositionFromPoint API returns a
CaretPosition which represents the caret position indicating current
text insertion point. However, the current spec doesn't
specifically define if and how shadow DOM scenarios should be supported. We want to update the API and spec to support shadow DOM cases
in a well defined way.
Proposal
Similar to Selection.getComposedRanges API, We should
introduce another argument
shadowRoots
which is the list of shadow roots that the API can pierce into. The API will look like:the returned caret position will only be in the shadow root if it's provided in
shadowRoots
argument. Otherwise, the caret position willbe in the shadow host's parent at the offset of the shadow host.
The proposed change to the API maintains the boundary of closed shadow tree unless the shadow root is provided to the API.
Alternative considered
DocumentOrShadowRoot
.The con to this approach is that the usage might be cumbersome to get a position inside nested shadow roots (need to call the API on each
level of shadow root).
The text was updated successfully, but these errors were encountered: