Re: [w3ctag/design-reviews] document.caretPositionFromPoint API in shadow DOM scenario (Issue #949)

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:

```js
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 `shadowRoots` parameter does double duty here: it opts in to the new behavior AND provides the shadow roots the code knows about. Again, depending on the use cases, this could be ok, but if aggregation is often desired (fetching all open shadow roots under a container), it can get tedious. It may be worth exploring alternative designs where this is easily possible. 

Do note that [we advise against optional parameters being positional, and recommend a dictionary instead](https://www.w3.org/TR/design-principles/#prefer-dictionaries) 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 `shadowRoots` option, which could take either an array of `Node` instances, or a `Node` (which would be treated the same as an array of one element). For non-`ShadowRoot` nodes, all open shadow roots within that container would be fetched. This means that `shadowRoots: document` addresses the use case of getting all open shadow roots with no further complication to the API, and closed shadow roots can still be provided like `shadowRoots: [document, shadow1, shadow2, ...]`.

We also noticed that `elementFromPoint()` and `elementsFromPoint()` still only have x and y parameters. Modifying the signature of one but not the other breaks [consistency](https://www.w3.org/TR/design-principles/#consistency) and should be avoided.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/949#issuecomment-2173011353
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/949/2173011353@github.com>