Define "affected ranges" clearer at `InputEvent.getTargetRanges()` definition

[masayuki-nakano]

Currently, getTargetRanges() is defined as:

getTargetRanges() returns an arrays StaticRanges that will be affected by the event if it is not cancelled.
https://w3c.github.io/input-events/#dom-inputevent-gettargetranges

InputEvent.getTargetRanges(): returns an arrays of StaticRanges which will be affected by the change to the DOM if it is not canceled.
https://w3c.github.io/input-events/#event-type-beforeinput

Currently, I'm implementing computation of "affected ranges" for shipping beforeinput event of Firefox. However, this definition is really unclear.

For example, when Backspaceing in <p>abc</p><p>[]def</p>, then, the paragraphs will be joined so that ("abc", 3) - ("def", 0) must be expected by web apps even though new empty first or second <p> element is removed (i.e., affected).

Another example: when there is invisible white-spaces at start of second paragraph and/or end of first paragraph in the previous example, i.e., <p>abc </p><p> []def</p>, browsers removes the invisible white-spaces too, i.e., becomes <p>abcdef</p>. So, in this case, getTargetRanges() should include the invisible white-spaces, but at least Blink does not include the invisible white-spaces.

On the other hand, if there is an invisible <br> element in the first paragraph, i.e., in the case of <p>abc<br></p><p>[]def</p>, Blink returns (p, 1) - (p, 0). I.e., including the invisible <br> element.

So, at least the first example, "affect range" may not be good information which web apps want to know. However, at the latter 2 cases, invisible things which will be removed should be contained by the result of getTargetRanges().

[masayuki-nakano]

Gecko compute "affected ranges" as the following rules for shipping in Nightly channel:

If Selection ranges are collapsed:

• If collapsed around a character in a text node, selects a character which means that it may select a surrogate pair if starting from a high-surrogate at forward deleting or a low surrogate at backward deletion
• If collapsed around an atomic content such as <input>, <img>, visible <br>, select it (i.e., at it in its parent and ends with next offset in same parent)
• If collapsed at inner of a block boundary, "affected range" contains only the boundary. For example, if pressing Backspace at <div>abc<p>[]def</p></div>, the range is <div>abc[<p>]def</p></div>. I.e., if the range starts and/or ends with a text node, its end and/or start becomes the boundaries of the range.
• If collapsed at outer of a block boundary, "affected range" contains only the boundary. For example, if pressing Delete at <div>abc[]<p>def</p></div>, the range is <div>abc[<p>]def</p></div>. I.e., if the range starts and/or ends with a text node, its end and/or start becomes the boundaries of the range.
• If collapse around an atomic content, select only the node, e.g., <p>abc<img>[]</p> and press Backspace, the range should be {P, 1} - {P, 2}.

However, if the range surrounded by invisible white-spaces, and they will be deleted by the action, they should be included into the target range. E.g., if <p>abc<hr> []def</p>, for keeping the white-space invisible, the range should be {p, 1} - {" def", 1}.

If the range is not collapsed, basically, it should be as-is, however, deleting the range causes deleting surrounding invisible white-spaces, the deleting invisible white-spaces should be included in the range. For example, <p>abc [</p><p>] def</p>, the range should be <p>abc[ <p><p> ]def</p>.

On the other hand, if non-collapsed range contains only one atomic content, but the range boundaries are in text nodes, e.g., <p>abc[<img>]def</p>, the target range should be as-is because trying to shrink the range is expensive for the browsers. For providing better UX for the users, browsers shouldn't try to shrink non-collapsed range(s).

Finally, I have no idea about this case: If selection range across table cells, like <table><tr><td>ab[c</td><td>d]ef</td></tr></table>, browsers won't change the table structure. Instead, they delete the content in the range. I.e., it becomes <table><tr><td>ab</td><td>ef</td></tr></table>. In this case, returning {"abc", 2} - {"def", 1} may not useful for web apps. Should browsers return {"abc", 2} - {"abc", 3} and {"def", 0} - {"def", 1} instead?

[masayuki-nakano]

And there is an issue if deleting block boundaries:

<div><b>abc</b><p><b>def</b></p></div>

If the <b> elements are joined, I think that the affected range should be <div><b>abc[</b><p><b>]def</b></p></div>, and if the <b> elements are not joined, I think that the affected range should be <div><b>abc</b>{<p>}<b>def</b></p></div>. That means that the "affected range" includes element boundaries which will be joined. However, if we'd take this rule, there are complicated cases. For example, <div><i><b>abc[</b></i><p><b>]def</b></p></div>, and deleting it gets <div><b><i>abc</i>def</b></div>, then, it's impossible to represent a range including only the element boundaries deleted. So, I think that "affected ranges" shouldn't take care of inline element boundaries which will be joined for making browser faster.

[annevk]

@RByers @whsieh could you work with @masayuki-nakano to improve this definition and interoperability between implementations? (Or find someone within your organization with the relevant expertise.)

[masayuki-nakano]

I added a lot of tentative tests to WPT, but it's not enough (editor has too many features!!)
https://wpt.fyi/results/input-events?label=master&label=experimental&aligned&q=input-events-get-target-ranges-

[masayuki-nakano]

It seems that when a target range boundary is at start of a block, Blink adjusts it as 0 of the block, but when a target boundary is at end of a block whose last content is a text node, Blink adjusts it as end of the text node, rather than end of the block. This inconsistency does not make sense. And I guess that pointing in a leaf node is more convenient for web apps. E.g., scanning ancestor block is easier than scanning first editable leaf.

[johanneswilm]

Hey,
to clarify: When we wrote the spec in the editing taskforce, we did not want to specify how backspace and delete behave or how the caret is to move. It's not that it would be bad to do so, but doing that seemed like a gigantic task with many complications and exceptions and the browser makers who participated were not willing to do this at the time. Can we differentiate between the following issues here?

• A language issue of the term "affected range" not expressing clearly whether or not DOM nodes at a higher level should be included. So for example if you press backspace in this case <p>abc</p><p>[]def</p> it could be argued that the entire second paragraph-element is "affected" as there will only be one paragraph element after the operation. It seems like all implementers have understood this correctly so far. If there is a better term, we could adjust the language to make it clearer that the entire second paragraph should not be included if we have a way of expressing that. The term currently used is the best we could come up with in the editing taskforce at the time.

• An issue of Blink returning a target range that differs from the actually affected range by not including certain types of invisible white space that really is affected. This is something that should be fixable in the blink engine without changing the spec, correct?

• There is some inconsistency in how Blink describes target ranges, sometimes referring to position zero in a text node and at other times referring to position zero in the parent node. I am not sure this is a problem. Is it? Given that the text nodes end up being merged, the more correct behavior would b for the static range to specify a place within the text node rather than the parent node.

• Browsers at times do some DOM cleanup (normalization, etc.). This is generally problematic for JavaScript editors and several browsers have cut down on this over the past 5-8 years. If this happens after a dom modification that causes a beforeinput event it can cause even more problems. Browsers should try to cut down on this in order to be friendly to JS editors, but also this is outside of the scope of this spec unless we create a special inputType for these kinds of changes.

• Different browsers have different backspace/delete behavior. This would be good to get standardized eventually so that JS apps can predict what will happen, but that would be outside of the scope of the Input Events spec.

Is that correctly understood?

[johanneswilm]

For example, <div><i><b>abc[</b></i><p><b>]def</b></p></div>, and deleting it gets <div><b><i>abc</i>def</b></div>, then, it's impossible to represent a range including only the element boundaries deleted. So, I think that "affected ranges" shouldn't take care of inline element boundaries which will be joined for making browser faster.

I am not sure how that selection could be set like that through human input, but putting it either here <div><i><b>abc[]</b></i><p><b>def</b></p></div> or here: <div><i><b>abc</b></i><p><b>[]def</b></p></div> and then hitting delete/backspace respectively, I get <div><i><b>abc</b></i><b>def</b></div>. So basically the <p> is gone, but the <b>s are not joined. The same happens on Firefox and Chrome.

This looks like one of those examples where browser in the past might have moved the dom nodes around (merging the <b>s), not realizing that this actually creates all kinds of problems for JS editors. This current behavior seems much better.

[johanneswilm]

On the other hand, if non-collapsed range contains only one atomic content, but the range boundaries are in text nodes, e.g., <p>abc[<img>]def</p>, the target range should be as-is because trying to shrink the range is expensive for the browsers. For providing better UX for the users, browsers shouldn't try to shrink non-collapsed range(s).

I think the cost argument should not be important here. The target ranges only need to be calculated if the getTargetRanges() function is called and if it just returns the same as the selection if the selection is not collapsed even when that will not return the real target range, then what is the point of calling the function at all? Can the JS author not just take the selection direct? If we do think it is important whether or not the target range starts in a text node or in the parent node, then the getTargetRanges() function should be the most correct ranges possible. So in the above example that would be {"abc", 3} - {"def", 0}.

We could also say that we don't care whether the range starts in the parent node or the text node because we know that adjacent text nodes as a result of browser native insertion/deletion will always be merged.