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?

[smaug----]

Maybe I could live with that though the legacy part seems not really important there, it is uncomposed which tells what the thing is about. If the old thing is that, what is the new thing called then? composed range?
(I kind of wish the names had selection somewhere in them, but they probably get too long with that)

[annevk]

It would help if you directly engaged with the points I made as to why "legacy" is important.

[smaug----]

I said I can live with that even though I disagree with you why it is or it is not needed. (IMO, it doesn't add any useful value if we anyhow call the thing "... uncomposed range", since that uncomposed is already very clear. And having something called "uncomposed" is odd enough that one should think what is then composed. Gecko has internal Node::GetUncomposedDoc() and Node::GetComposedDoc(), as an example, and that naming scheme has been very useful and clear for years now.)

My main question there was that it isn't clear to me what the latest proposal here is for the other range. Is that "composed range"? Or is it still one of the names mentioned in the original comment?

[dizhang168]

To summarize, the leading choice is to use "legacy uncomposed range".
Given that name, should we go for "composed range" for the new range that can be across shadow trees?

[dizhang168]

Per conversation during yesterday's WHATNOT meeting, I have updated the language to use "composed range" and "legacy uncomposed range". This issue can be closed.

[annevk]

Should we add "live" to those as well? As in "composed live range" and "legacy uncomposed live range".