This feature ships two new API methods for the Selection API: * Selection.direction which returns the selection's direction as either "none", "forward" or "backward" * Selection.getComposedRanges() which returns a list of 0 or 1 “composed” StaticRange A “composed” StaticRange is allowed to cross shadow boundaries, which normal Ranges cannot. For example: const range = getSelection().getComposedRanges({ shadowRoots: [root] }); If the selection crosses a shadow root boundary that isn’t provided in the shadowRots list, then the StaticRange's endpoints will be “rescoped” to be outside that tree. This makes sure we do not expose unknown shadow trees.
None
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No, this is only shipping new APIs without modifying existing behavior.
None
The Selection API is supported on all platforms.
Tests can be found at https://wpt.fyi/results/selection/shadow-dom/tentative?label=experimental&label=master&aligned
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
This new API is important to return Selection endpoints that are inside a shadow DOM and currently not accessible by API. This depends on new specification definitions of what it means to have a range that is composed and how the endpoints should be compared. That specification includes tree traversal, boundary point comparisons and the specification language is quite complex. The specification PR has been open since Dec 17, 2024 and is stalling due to disagreement on how to phrase/word the spec. There are a few remaining open issues about this, but none of those should affect the shape of the API - they only affect the spec text itself.Looking at the WPT results, there are a lot of Safari failures despite them having already shipped this.
https://wpt.fyi/results/selection/shadow-dom/tentative?label=experimental&label=master&aligned
Do you have an understanding of what those gaps are, and whether there’s a path towards resolving them and ending up with interoperable implementations?
I am also wondering if there should be a TAG review for this. It seems that the spec is still somewhat in flux and the shipped WebKit implementation doesn’t align all that closely with Chromium’s given the WPT results, so I’m not sure this Intent quite meets the spirit of the exceptions for a TAG review. And in any case the TAG may be able to help unblock some of the disagreements that have caused the spec changes to stall out.
-- Dan
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
blink-dev+...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/10d2631e-2014-42ac-9343-c6d43ff47975n%40chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
LGTM2
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7c042fed-e301-4cf1-9cfc-533a2fbe8b73n%40chromium.org.
LGTM3
/Daniel
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ad2542f-4745-4bb9-ba80-356e7e7d2a18%40chromium.org.