getTargetRanges() is underspecified

[domenic]

It appears to have two normative definitions.

The first:

getTargetRanges() returns an Array of StaticRanges [STATIC-RANGE] affected by this event if there is available, otherwise it returns and empty Array.

which has some grammar problems, and doesn't specify how implementations determine which StaticRanges are affected by this event.

The second:

1. If the inputType is undo or redo, getTargetRanges() returns an empty Array.
2. Else, getTargetRanges returns an Array of StaticRanges.

doesn't specify what is in the array of StaticRanges returned.

[domenic]

Actually there appears to be a third normative definition, in https://w3c.github.io/input-events/#overview. That one probably was supposed to be marked as non-normative (and could be cleaned up to just read "empty" vs. "non-empty").

[johanneswilm]

@domenic The issues should be fixed in the last two commits. Please reopen if persists.

[domenic]

Is there any way the spec could define "StaticRanges affected by this event"?

[johanneswilm]

@domenic I am not sure. "StaticRange" is defined. I wonder if the part "affected by this event" can be well-defined. It would be nice if it could, but the differences between user agents, etc. may make it difficult. Take for example:

<p>Text <b>bold text</b></p>

<p><b>|more bold</b> other text</p>

| = caret

Say the user hits backspace, so that the two paragraphs merge. The "affected part" if we only think about DOM nodes that will be removed or modified, etc. would like be this:

[<p>Text <b>bold text</b></p>

<p><b>more bold</b> other text</p>]

[] = affected part

But we really want something like this:

<p>Text <b>bold text[</b></p>

<p><b>]more bold</b> other text</p>

[] = affected part

Or some user agents may come up with this:

<p>Text <b>bold text</b>[</p>

<p>]<b>more bold</b> other text</p>

[] = affected part

(Paragraph merging is really really complex once you add more elements to it, which is part of the reason why we need to move this in JS space.)

[johanneswilm]

I guess what we mean with "affected content" would be "content replaced", if we can say that in a way so it only means the inner parts as demonstrated in the last two examples and not the entire outer element.

[chong-z]

From the original resolution https://github.com/w3c/editing/issues/80 I think getTargetRanges() should:

1. Return selection to be deleted for 'deleteContentForward/Backward', 'deleteWordForward/Backward', 'deleteSoftLineForward/Backward' and 'deleteHardLineForward/Backward'
2. Return NULL for other inputType (as the target ranges are always equal to current selection)

[johanneswilm]

(as the target ranges are always equal to current selection)

We went a few times back and forth over that. I believe we ended up saying that the target ranges should also return a target range, even if it is the same as the selection.

[johanneswilm]

From what I can tell, our answer to that question wasn't recorded. The one you mention, 80, from August 2015 wasn't the final answer as it was on the agenda in July, and I believe we went with the other one. Remember that at the time of 80, the targetranges were directly attached to the event (no method), and it was a live range. It would seem odd not to give this information because it is the same as the selection. It was a different issue when we had a live range attached directly to 2016the event.

In Gary's document I can only find the agenda topic from July's meeting: "We have moved back and forth between offering ranges information on most beforeInput events or only using it if it differs from the current selection. We need to decide one." https://docs.google.com/document/d/1XxIEF0So-kMF5mcJ03Yj0zsYMFRHEgXw1fV1K5FOwuQ/edit#

[johanneswilm]

@choniong: btw, I believe this issue is about something else (the wording). We exchanged a word at the F2F for this. Spec will update soon.

[johanneswilm]

@choniong See this: https://lists.w3.org/Archives/Public/public-editing-tf/2016Feb/0002.html : This is newer than #80 and basically it seems to communicate that there is no disagreement with always returning target ranges when target ranges are available, even when there is a selection. The same was the result from the July meeting, AFAIR, but unfortunately this wasn't recorded in the minutes.

[johanneswilm]

@choniong Closing this, as I'm fixing the original issue as per meeting notes.

If you want to restart the discussion on whether or not there should be target ranges on some of these events, could you start a new issue? I am quite confident that we ended up saying that we want the ranges in at least three different occasions after #80, but I can see that it's not well written down anywhere.