Clarify what getTargetRanges should return when joining paragraphs

[masayuki-nakano]

Backspace when <p>abc</p><p>[]def<br>ghi</p>, browsers move the first line of the second paragraph (i.g., "def") to the first paragraph. Therefore, if browsers make getTargetRanges() return "affected ranges", the text node of "def" and <br> needs to be in a target range. However, it must be not useful for web apps and actually, browsers try to return a range around </p><p>. So I think that the spec should clarify that the target range in such case should contain only the element boundaries which will be joined. E.g., Backspace when <p>abc</p><div><p>[]def</p></div>, it should be <p>abc{</p><div><p>}def</p>.

However, if there are some invisible white-spaces around the block element boundaries and they will be deleted by the browsers, the target range should include the while-spaces too. E.g., Backspace when <p>abc </p><div><p> []def</p></div>, it should be <p>abc[ </p><div><p> ]def</p>.

So, I'm trying to mean that inline element boundaries shouldn't appear around the block boundaries if there is no collapsed white-spaces. E.g., Backspace when <p><span>abc</span></p><div><p><span>[]def</span></p></div>, it should be <p><span>abc</span>{</p><div><p>}<span>def</span></p></div>. This is simple and avoid the inconsistency between browsers.

However, invisible <br> element needs to be in the target range if there is. E.g., Backspace when <p>abc<br></p><div><p>[]def</p></div>, it should be <p>abc{<br></p><div><p>}def</p>.

This rules getting it clear that open/close tags of inline elements in target range do not mean the styles of the inline elements may not be removed completely. It should be checked with document.queryCommandState instead (it's currently only API to retrieve the style which will be applied if user type a new text).

[johanneswilm]

Given that the other browser makers don't agree on having divergent behavior for contenteditable and EditContext, I take this as being a proposal for contenteditableand execCommand as well, right?

[masayuki-nakano]

As I commented in #158, I don't suggest the other browser vendors should change the editing behavior of contenteditable. I'm suggesting that there should be "normalizing" rules of target ranges. Without the normalization rules, it's hard to write the compatible implementation at least for EditContext (because EditContext is new one, and we could try to make getTargetRanges return more compatible ranges than running with contenteditable).

So, yes, normalizing rules should apply to contenteditable too, but the rules are really required to implement EditContext in Firefox since getTargetRanges for EditContext is the only way to let web developers know target ranges at handling deleting command with collapsed selection.

[masayuki-nakano]

I take this as being a proposal for contenteditableand execCommand as well, right?

So, yes, this is about both for contenteditable and EditContext.

[johanneswilm]

I am glad that this is a proposal for all richtext editing types. I am not against working on this as long as it doesn't stop other things from continuing to move.

However, I will point out that merging paragraphs and other types of content can get incredibly complex very quickly and the amount of possible combinations of what could be merged into oneanother is almost endless, which is why browser makers at previous meetings said that this is not something we should work on and it's also one of the main reasons why these new specs don't specify very much what concrete dom changes are to be made upon user request.

Backspace when <p>abc</p><p>[]def<br>ghi</p>, browsers move the first line of the second paragraph (i.g., "def") to the first paragraph. Therefore, if browsers make getTargetRanges() return "affected ranges", the text node of "def" and <br> needs to be in a target range. However, it must be not useful for web apps and actually, browsers try to return a range around </p><p>.

Yes, I can see how from a browser-technical perspective, one could say that the entire second node is affected. However, not from the perspective of the end user and it is this end user perspective that is important here. It seems like browsers already got this right in their implementation as they exist now, so it's mainly about making the wording reflect better what the implementations are already doing.

[johanneswilm]

@masayuki-nakano

However, invisible <br> element needs to be in the target range if there is. E.g., Backspace when <p>abc<br></p><div><p>[]def</p></div>, it should be <p>abc{<br></p><div><p>}def</p>.

What if it is something else than a <br>? For example a <hr> that is styled to display:none;?

[smaug----]

@masayuki-nakano any suggestions what the spec could say here to be closer to what implementations do?

[masayuki-nakano]

@johanneswilm

so it's mainly about making the wording reflect better what the implementations are already doing.

I agree, and need to be careful about the wording around inline elements mentioned in #158.

@smaug----

@masayuki-nakano any suggestions what the spec could say here to be closer to what implementations do?

If the conclusion of #158 is shrinking the range into leaf nodes or text nodes as far as possible, perhaps, it could say:

When 2 positions are connected like joining the last line of a paragraph and the first line of its following paragraph, the StaticRange should start after the last leaf content in the preceding point and before the first leaf content in the preceding point. E.g., starting from the end of the last text node in the preceding paragraph and ending at the start of the first text node in the following paragraph. If the last/first content of the paragraphs are not text like <img>, the range must start after and/or end before the <img>.

[johanneswilm]

From TPAC 2024 minutes:

Sanket: I think problem is larger in that dom changes differ.

Johannes: I think this is just about being consistent in how target ranges are collected.

Ryosuke: Difficult in Webkit as we have not yet implemented non-canonicalized selection …

Sanket: Yeah, also in Chromium

Ryosuke: Could imagine fancy editor doing different thing in bidi or so

Johannes: I wonder if it is about wording.

RESOLUTION: Olli follows up with Masayuki