getComposedRange() review

[annevk]

If this is empty, return a new StaticRange whose start node and end node are null and whose start offset and end offset are 0.

Start/end node cannot be null. I think we use some kind of default instead, such as "the body element"?

While startNode is a node, startNode's root is a shadow root, and startNode is not a shadow-including inclusive ancestor of any of shadowRoots

It seems that if you pass in the ShadowRoot instance start node is part of, this wouldn't result in a match. Which if you made a selection inside that ShadowRoot instance doesn't seem to be what you want?

---

One thing I'm missing here still is WICG/webcomponents#79 (comment). As we can no longer expose the true range directly we need to deal with that duality somehow, also for existing APIs such as getRangeAt(). That will require changes to both DOM and Selection.

[masayuki-nakano]

If this is empty, return a new StaticRange whose start node and end node are null and whose start offset and end offset are 0.

Start/end node cannot be null. I think we use some kind of default instead, such as "the body element"?

Why is just returning null or throwing an exception like getRangeAt not properly here? I feel it's odd that returning a range when there is no range(s). Returning "dummy" range makes web apps need to consider whether it's real one or not.

[rniwa]

Yeah, returning null is probably most straight forward behavior in this case.

[annevk]

(I was thinking of what https://dom.spec.whatwg.org/#dom-range-range does, but returning null from the method makes sense as well.)

[andreubotella]

Would there be some way to know the direction of a selection in a shadow tree if (anchor|focus)(Node|Offset) are all null? Since StaticRange doesn't have a concept of direction.

[rniwa]

@andreubotella : yeah, maybe we want direction property on DOMSelection.

[annevk]

Other things worth tracking here:

• Perhaps we should still allow for multiple ranges API-wise and return a list. (And add a trailing s to the API name.)
• StaticRange has a concept of "valid" and this does not adhere to that. Perhaps we need a concept of "shadow-including valid" or at least point out that these ranges will not always be valid (but that's okay). Probably the latter until there's an actual use case.

[rniwa]

@andreubotella : yeah, maybe we want direction property on DOMSelection.

Added direction property in cd5148f

[rniwa]

I prototyped getComposedRanges in WebKit: https://commits.webkit.org/260121@main

[rniwa]

Renamed this function to getComposedRanges in 941fa81 to match WebKit's implementation.

[mfreed7]

Thanks for writing up the spec and getting a prototype started @rniwa!

I need to dedicate some time to read through it in detail, but it would help if you could comment on whether/how it differs from the explainer we discussed before?

Also, as part of the WebKit implementation, did you happen to write any WPTs?

[rniwa]

@mfreed7 : There are a few differences with that explainer. For starters, the method is called getComposedRanges, and returns a sequence of StaticRange objects. The direction property also returns "forward", "backward", or "none" to match selectionDirection property on the input element.