Adjustments for EditContext

[johanneswilm]

The input events also need to fire in EditContext elements, so some adjustments need to be made.

EditContext behaves a lot like the contenteditable=caret and other modes that we initially planned (never implemented or shipped) that are mentioned in the spec. I wonder if we can replace the current reference to the alternative contenteditable modes with more generic language that can also be used by EditContext.

This bit:

A user agent MUST dispatch this event immediately after the DOM has been updated due to a user expressed intention to change the document contents which the browser has handled.

Could be changed to:

A user agent MUST dispatch this event immediately after the DOM has been updated due to a user expressed intention to change the document contents which the browser has handled, unless the browser makes no DOM change, either because the editing host is of the kind that does not do automatic DOM changes or because the browser (user agent) concludes that no DOM change is needed, in which case the user agent MUST NOT dispatch this event.

[dandclark]

If time permits it would also be useful to discuss where the entry point to Update the EditContext should be. The question of how exactly the text/composition info gets from the text input service to EditContext might be an implementation detail to some extent, but we could at least define the timing of this update with respect to when input events fire.

[johanneswilm]

@dandclark As I understand it, the web author cannot stop the editcontext from being updated nor can it influence it. So running event.preventDefault() on the beforeinput event will not stop the text in the editcontext from being stopped, nor is there any other way to achieve that. So that would mean that at times the beforeinput event would need to be used for reverting an undesired change to the editcontext, right? In that case, I think it would make sense to update the edit context just prior to the beforeinput event.

[dandclark]

My expectation was that beforeinput would happen before the EditContext gets the text update, and that preventDefault in beforeinput would prevent the EditContext from receiving the input.

This is how it works in the Chromium prototype today. It also seems closest to how things work with a normal contenteditable. It also seems like a useful behavior to me; authors might want to prevent text input when the EditContext is in certain states, e.g. to prevent input from exceeding a length limit, and doing preventDefault in beforeinput seems like a reasonable way to achieve that.

[johanneswilm]

@dandclark I agree. That would be much better. Should that be specified in the EditContext spec? The way it is written now (steps 6,7) it sounds as if the web app has no influence between user input and the editcontext being modified.

[dandclark]

Discussion from TPAC Editing WG meeting:

Dan: We could make a PR on Input Events that we will merge once we are certain EditContext goes to REC? Johannes: We could use generic language in some places Simon: Better to be specific. When will PR be merged? Dan: Hope to ship this year. We could say trigger is that it is shipped in one browser. Simon: No official position yet, but some interest. I’ll get back with position. Ryosuke: No official stand yet. Johannes: Will chromium ship even if it’s only them? Dan: I think if we hear no opposition then yes. Johnanes: PR can be land as it will not make browsers that don’t implement EditContext uncompliant. RESOLUTION: Make a PR to Input events that makes it work with EditContext, naming EditContext specifically. Not merge until shipped in at least one browser. Dan will write PR.