Naming of Composed Range

[dizhang168]

What is the issue with the DOM Standard?

Per the discussion on the PR to define Composed Selection Range, there is a disagreement on what naming we should use for the new concept. Currently:

• Composed selection range: A range with start and end endpoints that can be across shadow trees
• Legacy selection range: The live range that is associated with the composed selection range. In Selection API, this is the live range returned by getRangeAt(0).

Some suggestions on how to call it includes:

1. "composed live range" and "legacy live range"
2. "composed selection range" and "legacy selection range"
3. "composed-tree selection range" and "same-tree selection range"
4. "composed selection range" and "same-tree selection range"

Does anyone have a strong preference?

@annevk @smaug---- @sefeng211 @domfarolino

[domfarolino]

Either of the first two are my preference, and I would prefer to not go with the last two. My rationale is that we don't need to call out "same-tree" explicitly, or include "tree" alongside "composed"; that's what the presence/absence of "composed" does alone. For example, composedPath() isn't called composedTreePath(), and root isn't called same-tree root (maybe it should be though 👀).

[sefeng211]

Hmm, so we prefer to not have the "legacy" word in the naming because it hints that this is going to be removed/deprecated in the future and this isn't the case here.

[annevk]

Legacy does not mean it's going to be removed. E.g., we use "legacy" for all non-UTF-8 encodings in https://encoding.spec.whatwg.org. It just means that it's not the thing you want.

@rniwa as editor of the Selection API should also weigh in, but ultimately this is something that the editors can decide as it's not exposed API.

[rniwa]

I'm not sure "legacy" is the most descriptive term to be used here. It doesn't really tell us how that's different from "composed selection range".

[annevk]

The problem is coming up with something that's more descriptive. "Legacy" makes some sense to me in that it's the legacy way of thinking about selections in terms of ranges. With composed ranges being the better way. If composed ranges were not there we'd prolly just call it "range", but I think that doesn't provide enough contrast with composed ranges and also doesn't dissuade API designers from building on top of it.

[rniwa]

Maybe we can call it uncomposed range?

[annevk]

I think that's okay. I think that gives less of a hint to API designers, but we can assume that'll be tackled during review (hopefully before). It's also not as distinctive.

[rniwa]

Maybe we can call it legacy uncomposed range? It's a bit mouthful but it makes the semantics very clear.

[smaug----]

Someone mentioned uncomposed earlier today, but I couldn't find any current use of that. I could live with that anyhow.
(but I still don't like legacy. It hints that something is replacing it, or that one could use something else instead)

[annevk]

or that one could use something else instead

That is the case here, right? Especially for an internal term that is primarily aimed at web platform designers. We want them to think in terms of the composed range. They'll have to account for the legacy range and not break it, but that's not the API that works with shadow roots and the like.

[domfarolino]

I vote for legacy uncomposed range. "Uncomposed" is very clear, and I think "legacy" is important to keep in the name as a good hint for web platform designers, for the reasons @annevk mentioned. @dizhang168, since nobody disagrees with "legacy uncomposed range", do you want to incorporate this change into your PR?