w3c/input-events

Input Events

The Input Events spec level 2

Level 2

This repository contains the code of Input Events spec level 2.

The Input Events spec level 1 (Discontinued draft)

Level 1

Level 1 and 2 each have three implementations (Chrome, Firefox and Safari). Level 2 is close to the consensus reached within the Editing Taskforce at the end of 2016. Level 1 is a subset that was split off in early 2017, when the Chromium team announced that it would not implement the entire specifition. At this time Safari had already implemented the full specification. We also did not want to give up level 2 of the spec, because it actually resolves a lot of issues and there has been no counter-proposal to effectively solve these issues from the Android team or others. Given that Chromium team told the Editing Taskforce that it either had to release a spec with their proposed changes or they would drop the spec entirely, it was decided to split the specification in two levels. By 2022, most of level 2 has been implemented in Chromium, and level 2 was adjusted remove three IME-specific input types. With this change, the implementations in all three browsers are following level 2.

Even though the specs look somewhat similar, they have to be handled quite differently by JavaScript editors:

• Level 1 gives the JS editor information about proposed changes from the user, but it makes the related DOM change be non-cancelable in many cases. The event is therefore only useful in combination with a way to roll back the DOM after the DOM change has been made, most likely a DOM-diffing library. In the case of IME, it is extra difficult to handle as DOM changes cannot be reverted before the composition has finished.

• Level 2 gives the JS editor information information about the proposed changes from the user and let's the JS author cancel the changes the browser otherwise would have done. There is one exception to this and that is IME, which cannot be canceled due to various technical constraints. A JS editor based on level 2 will therefore continue to rely on other techniques, such as DOM-diffing libraries or rolling browser-made DOM-changes back, to handle IME correctly. A test of trying to create an editor using the event was conducted by the CKEditor team in the second half of 2016 before it was implemented in browsers.

input-events's Issues

Should Device-Specific Edit Events say what Device-Independent Edit Event they will cause?

From @BenjamP on December 10, 2014 17:47

From MS Office Team

Copied from original issue: w3c/editing#25

"user agent" links are blue and go nowhere

Not sure why they are blue, but they should probably not be broken links.

We can try to fix whatwg/html#1021 for you to give them somewhere to point to.

What should happen when "deleteByComposition" is canceled?

According to the spec, "preventing the default action for [deleteByComposition] will mean that [the recomposed] range will not be removed from the DOM by the user agent." However, does this mean that the page should still show UI for editing the composition (for instance, a list of candidates) and allow typing to edit the composition, but just not modify the DOM in the process? If so, would the input events dispatched for a page that prevents default on both "deleteByComposition" and "insertFromComposition" look like this when recomposing text:

Dispatch beforeinput event of type "deleteByComposition"
< preventDefault() is called, and we keep the text being recomposed exactly the same >

< user selects a candidate/types something >
Dispatch beforeinput event of type "insertCompositionText"
Dispatch input event of type "insertCompositionText"

< user selects a candidate/types something >
Dispatch beforeinput event of type "insertCompositionText"
Dispatch input event of type "insertCompositionText"

< ...and so on... >

< finally, user hits enter to commit the composition >
Dispatch beforeinput event of type "insertFromComposition"
Dispatch input event of type "insertFromComposition"

^ I also had a question about the behavior of insertFromComposition in this circumstance, but Ryosuke added a question covering that here: #41

Editorial clarity

Editorial comments are less critical to handle on a WG-to-WG level, but
our participants thought they were relevant enough to send. This text is not clear:

The DataTransfer object's drag data store item list
<
https://html.spec.whatwg.org/multipage/interaction.html#drag-data-store-item-list>

contains one entry with the draf data item type string
<
https://html.spec.whatwg.org/multipage/interaction.html#the-drag-data-item-type-string>

|"text/html"|, whose kind
<
https://html.spec.whatwg.org/multipage/interaction.html#the-drag-data-item-kind>

is /Plain Unicode string/, and whose data is a HTML representation of
the content that is in the clipboard, in the kill buffer
<
https://www.w3.org/TR/input-events/#dfn-kill-buffer>,
to be dropped or
otherwise the content that is to be added. [HTML-LIVING
<
https://www.w3.org/TR/input-events/#bib-HTML-LIVING>]

Are you equating the kill buffer with the clipboard? It looks like you
are missing an “or” as in “ or in the kill buffer”.

Should there be "deleteOrderedList"/"deleteUnorderedList" inputTypes?

Browsers may have ways for the user to explicitly "downgrade" a list item into a regular text node.

Create an overview of which inputtypes are used on which platform

As mentioned in #20 (comment), not all inputtypes we define are currently in use and especially deletion commands on Mac OS X seem to work different in Firefox than in other browsers and native programs.

@choniong wrote in #20 (comment):

Yes I agree we should [...] maybe have an example/notes section listing known hotkeys.

That could work, but if it's a note in the spec, it may get outdated fairly quickly.

Is the Firefox behavior on Mac OS X intentional, @ayg @masayuki-nakano

Replace StaticRange with a dictionary or figure out if normal Ranges could be used

If StaticRange approach (but just using dictionaries) is taken, dom mutations during event dispatch need to be observed so that getTargetRanges() can return something valid (empty array is ok, but StaticRanges pointing to invalid data isn't).

Do we need to spec device specific events?

From @johanneswilm on August 3, 2015 13:57

We currently specify all the possible device independent events that will be triggered after device specific events. These device specific events are largely already accessible to JS in the form of onclick, onkeydown, etc. events, but not all of them (for example choosing "paste" from the right click menu), and they are available in different formats. Should we

a) define new device specific events for the missing device specific events
b) define new and additional device specific events for all of the events that will cause device independent events
c) add information about an events origin to the device independent events?

All of these have their advantages and disadvantages.

Copied from original issue: w3c/editing#62

RESOLUTION: have a relatedEvent to point to the UI event that caused a DI event to be fired

From @johanneswilm on August 25, 2015 14:43

Not sure, but this was related to issues #19 and #25. As I remember it, we had the resolution, and then after that we discovered that it possibly couldn't be used for the purpose of solving issues #19 and #25 anyway. But I guess the resolution still stands, right?

Copied from original issue: w3c/editing#82

getTargetRanges() is underspecified

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.

Do we really want forcing adding prefixes to inputType?

Issue Background

Recent commit 28b3edf adds prefixes to all inputType, e.g.

'transpose' => 'insertTranspose'

'undo' => 'historyUndo'
'redo' => 'historyRedo'

'bold' => 'formatBold'
'subscript' => 'formatSubscript'
'justifyCenter' => 'formatJustifyCenter'
'removeFormat' => 'formatRemove'

The original point of adding prefixes came from TPAC 2016: https://www.w3.org/2016/09/22-webapps-minutes.html#item04 @garykac

Gary: If we strictly use insert and delete as prefixes for events, maybe format* as well, makes it much easier to catch all events.

---

Original Naming style

Actually those prefixes look weird to me, and I'm not sure how useful "catch all events" would be.

The original style is DOMAction+Source/MoreDetails, and By/From means 'indirect outcome'. e.g.

* `deleteWordForward` means user initiated a 'delete' action, which is meaningful enough by itself. 
JS can either
  1. Filter prefix 'delete' and delete target ranges, or
  2. Filter 'Word' and implementing it's own algorithm to calculate target ranges
See how [CKEditor Typing Demo](https://github.com/ckeditor/ckeditor5-typing/blob/45b47a3cc68e36932592ebcc151b12ea79f149d5/src/delete.js#L53) utilize target ranges for selected units.

* `deleteByCut` means user initiated a 'cut' action, and this `beforeinput` is only about the 'delete' part of the action.

* `bold` just mean action `bold`, and there is no additional information.
(We probably don't want `boldFromKeyboard` or `boldFromMenu`)

• We have lots of insert* and delete* because they can be handled using similar logic (if JS doesn't care about sources, etc).
  • e.g. If we decided to add new type insertFromSpeech later, it should just work with existing insert logic
• We have other standalone inputType because they have to be handled individually
  • e.g. Adding prefix format or history doesn't provide useful information, JS still need to make a list of supported inputType, and preventDefault()/Let go on others

---

Proposal

We could do something about transpose, undo and redo, but should leave other inputType standalone.
(As well as backColor, createLink, fontName, and fontColor proposed here #32 (comment))

• For transpose: insertTranspose or insertFromTranspose could work, but I'm not sure about semantics...
• For undo and redo: We need to make it clear it's only about DOM modification, e.g. undoModification, modificationFromUndo, see #21

July 29th F2F Agenda Item - Data and dataTransfer attributes

From @gked on July 29, 2016 22:13

What should the relation between the two be? See Issue 131.

Copied from original issue: w3c/editing#139

inputTypes should be strings

E.g. "superscript", not superscript or superscript.

Introduce inputType 'deleteCompositionText' and 'insertFromComposition', fired right before 'compositionend'

Original Discussion
w3c/editing#118 (comment) We want 'deleteComposedCharacter' during composition because of it's special non-cancelable attribute.

Issues

1. 'insertText' during composition is also non-cancelable, do we want 'insertCompositionText'?
2. 'deleteComposedCharacter' is not so helpful as Chrome (and maybe WebKit) always replace the entire composition text

Proposal

1. Text replacement should only be split into deletion and insertion at 1. the start and 2. the end of the composition
   • During composition both deletion and insertion are non-cancelable, so there is no reason to split
2. Have 4 composition related events
   1. Single or none 'deleteByComposition', fired before 'compositionstart', cancelable
   2. Multiple 'insertCompositionText', fired during composition, non-cancelable
   3. Single 'deleteCompositionText', fired before 'compositionend', non-cancelable
   4. Single or none 'insertFromComposition', fired between iii. and 'compositionend', cancelable

Default Action

InputType	Default	preventDefault()
'deleteByComposition'	Delete original text	Similar to collapse selection forward and start composition, but next 'insertCompositionText' will pre-insert selected text in certain cases
'insertCompositionText'	Insert/replace marked text (with marked text)	N/A
'deleteCompositionText'	Clear marked text	N/A
'insertFromComposition'	Insert final confirmed text	Only cancels text insertion and won't affect IME (IME terminates as usual)

Example Order

(1. beforeinput - 'deleteByComposition')
(2. input - 'deleteByComposition')
3. 'compositionstart'

4. beforeinput - 'insertCompositionText'
5. 'compositionupdate'
6. input - 'insertCompositionText'
7. beforeinput - 'insertCompositionText'
8. 'compositionupdate'
9. input - 'insertCompositionText'
(...)

10. beforeinput - 'deleteCompositionText'
11. 'compositionupdate'
12. input - 'deleteCompositionText'

(13. beforeinput - 'insertFromComposition')
(14. input - 'insertFromComposition')
15. 'compositionend'

Example of Recomposition on Android

#	User Action	Event Type	inputType	DOM	event.data
1	Start			'Wo'
2	Tap 'Wo' to start composition	'beforeinput'	'deleteByComposition'	'Wo'
3		'input'	'deleteByComposition'	''
4		'compositionstart'		''	'Wo'
5		'beforeinput'	'insertCompositionText'	''	'Wo'
6		'compositionupdate'		''	'Wo'
7		'input'	'insertCompositionText'	Underlined 'Wo'
8	Press key 'r'	'beforeinput'	'insertCompositionText'	Underlined 'Wo'	'Wor'
9		'compositionupdate'		Underlined 'Wor'	'Wor'
10		'input'	'insertCompositionText'	Underlined 'Wor'
11	Tap suggested word 'Work' to commit	'beforeinput'	'deleteCompositionText'	Underlined 'Wor'
12		'compositionupdate'		Underlined 'Wor'	''
13		'input'	'deleteCompositionText'	''
14		'beforeinput'	'insertFromComposition'	''	'Work'
15		'input'	'insertFromComposition'	'Work'
16		'compositionend'		'Work'	'Work'

We should fire 'beforeinput' after 'compositionupdate'

Copied from w3c/uievents#66 (comment) as it's more InputEvent related.

Proposal
We should fire 'beforeinput' after 'compositionupdate', e.g.

*'compositionupdate'
*'beforeinput'`
-update DOM now-
'input'`

Reasoning

1. Previously we want to fire 'beforeinput' before 'compositionupdate' because IE/Edge has a different behavior, but IIRC @gked mentioned that it was a bug and will be fixed. (@gked can you help confirm?)
2. If IE/Edge could update the behavior then it makes more sense to fire 'beforeinput' immediately before DOM update as required by spec:

   A user agent MUST dispatch this event when the DOM is about to be updated.

@whsieh Safari Technology Preview is firing 'beforeinput' after 'compositionupdate', just want to confirm: Is Safari going to ship with this order?

When the events are fired seems strange

A user agent MUST dispatch this event immediately after the DOM has been updated.

What does this mean? Whenever any node in the DOM is updated in any way? If so this should probably be tied to the concepts of removing steps, insertion steps, attribute change steps, etc.

Add inputTypes for Safari and use 'data' to pass argument

Safari has context menus for more editing operations that have not been covered within inputTypes so far:

• capitalize
• make lowercase
• make uppercase
• substitute (?), used for smart quotes, etc.
• paragraphdirectionright/left (adds style="direction: rtl", so that the visual effect for European languages looks like right-justified, and the period at the end of the sentence moved to the other end of the sentence, but the text remains ltr)

Introduce inputType 'deleteByComposition' and fire before 'compositionstart'

Background
This is about replacing text.
Usually we fire 'insertText' and assume it will replace current selection, and canceling it will prevent the entire replacement.
However the first 'insertText' after 'compositionstart' is non-cancelable.

Proposal
We should split the replacement into 1. deletion and 2. insertion for composition, and do the deletion before 'compositionstart'.

Applications

• Android - Tap a word and start composition from existing text
• All OS - Select a range and start composition through 1. typing or, for example, 2. Japanese "Reverse Conversion"

Notes

• For start composition from existing text, the browser should pretend they are replacing the text, even though what they do is just adding underlines to the text
• Canceling 'deleteByComposition' will result in duplicated text
  • But this should be expected as you are canceling a deletion
• Canceling both 'deleteByComposition' and the last 'beforeinput' will keep DOM unchanged

Related discussion #17 (comment)

beforeInput/input events should be fired for any element with contentEditable enabled, input and textArea elements where input element and textArea will have targetRanges set to null.

From @gked on January 13, 2016 1:38

Copied from original issue: w3c/editing#96

dataTransfer spec is weird

This is mostly an editorial issue; I think implementers can probably figure out what you mean. But the way the spec is written:

dataTransfer.getData('text/html') returns a HTML representation of the content that is to be cut, copied, pasted, dragged, dropped or added.

it seems to imply you're overwriting the getData method in some way.

The proper way to layer this is to say that the event is created with an associated DataTransfer object, whose drag data store item list contains certain entries. Then, the dataTransfer attribute will return the associated DataTransfer object.

[beforeinput] PreventDefault() on InputType=cut differs from Clipboard API

From @choniong on August 16, 2016 20:32

If I recall correctly the outcome from the F2F is:

1. Cut and paste are effectively the same as beforeinput
2. Canceling 'beforeinput' prevents clipboard update

But according to Clipboard API canceling cut does not prevents clipboard update. Instead it writes user-modified data into clipboard.

To solve the conflicts the possible solutions are (For InputType=cut):

a. Set 'beforeinput'.dataTransfer=NULL, preventing default will prevent everything.
b. 'beforeinput' shares the same DataTransfer object with Clipboard::Cut, and does the same thing
c. Set 'beforeinput'.dataTransfer=Readonly-Data-To-Be-Cut, preventing default will prevent everything.

Personally I'd perfer a) since JS can always get data from selection, and we can add dataTransfer later if it's really useful.

Copied from original issue: w3c/editing#144

Function notifications for AT

From an accessibility perspective it would be valuable to have a notification to Assistive Technologies (AT) that functions like text insertions were
completed so that positive reinforcement could be provided to the user.

Filed from the feedback from the APA WG.

July 29th F2F Agenda Item - Non-cancelable event 1of 2

From @gked on July 29, 2016 20:23

Previously we talked about the beforeInput event not being cancelable during a composition. With the splitting of the event into one part in the ui-events spec and the other in the Input events spec, the cancelable attribute is in the ui events spec and the isComposing is in the Input events spec. In the ui-events spec the event is marked as always being cancelable. Will this work, or do we need to specify that it is not cancelable during composition?

Copied from original issue: w3c/editing#137

"This specification builds on the Document Object Model Events Level 3."

That spec is obsolete and should not be built upon. Probably you want https://dom.spec.whatwg.org/#events instead.

It is unclear from the spec why inputEvent.dataTransfer is needed

It mostly feels wrong. It should be dnd and clipboard events. No need to have it elsewhere.

How to make 'undo'/'redo' useful

Background
Currently 'undo'/'redo' is targeting the Element to be modified (but not the focused Element)

Issues

1. An editing host will never receive 'undo' if it prevents all 'beforeinput'
2. No 'undo' will be fired if the stack is empty

Solution

• Provide an API to push dummy 'undo' entries into the stack (with 'target')

Or alternately:

• Use the opt-in/opt-out feature to mark 'undo'/'redo' as always enabled
  • Events should be dispatch to focused document if the stack is empty
  • JS will have to catch 'undo'/'redo' from document

What do all the rows in the event definitions mean?

As pointed out in #6, I know that default actions is not a real thing. But I don't know what "Sync / Async", "Trusted Targets", or "Context (trusted events)" mean. Are these normative? If so, I have a bunch of follow-up questions, once I get definitions for them. If not, then probably they are causing more confusion than they are helping, and should be removed.

Make `targetRanges` an attribute which doesn't response to DOM mutations

Proposal

Define InputEvent as an one-time-use only event, where if event handlers wants to mess up with DOM, they should call preventDefault() and dispatch new 'beforeinput' to describe the change.

For example if spellcheckers wants to modify DOM, they should:

1. First call preventDefault() and dispatch a new 'beforeinput', describing the change;
2. Then modify DOM only if it's not cancelled.

In this way we can have StaticRange as an attribute.

Example Code: #40 (comment)

---

Original Post:

Example 1:

A Sample Text.

When user does the following:

1. Double-click word 'Sample' to select;
2. Press delete key.

UA may choose to delete one additional adjacent space (Chrome) or only the selection (FireFox).

In this case:

1. User's intention is the selection;
2. UA's default action should include the additional space (if available).

I think getTargetRanges() should follow User's intention and just return the selection, thus JS doesn't have to guess whether it's smart delete or not.

Example 2:

The current status of StaticRange is:
UA keeps a Range instance during event dispatching to track DOM mutation, and getTargetRanges() returns array of dictionary StaticRange at any point.

This example is about tracking selection/caret.

A Sample| Text.

(| is caret)

editor.addEventListener('beforeinput', () => {
  selectFirstCharacter(); // e.g. Select character 'A'.
});

Assuming there are multiple event listeners, and the above JS will run before any other.
When user does the following:

1. Place caret after 'Sample';
2. Press backspace key.

For the follow up listeners, should getTargetRanges() return

1. User's intention aka. 'e';
2. UA's default actionaka. 'A'?

I think we should still follow User's intention to return 'e' and don't track selection/caret.

Why do textareas and inputs of type "text" return an empty array from getTargetRanges()?

According to the chart in https://www.w3.org/TR/input-events/, <textarea> and <input type="text"> should return an empty array in getTargetRanges(). It seems like target ranges would be necessary for features such as autocorrect or spellchecking to work properly in plain text areas, otherwise the page would not know what range of text is being replaced.

July 29th F2F Agenda Item - Dragging and dropping

From @gked on July 29, 2016 19:42

What should the order of the events be and in what spec should this be placed?

Copied from original issue: w3c/editing#134

Programmatic methods for alternate input solutions

From an accessibility perspective it would be valuable to have A programmatic way for alternate input solutions to drive some of the changes. For example, an AT might want to insert the text now that this can be done in a device independent way. Some of this may be provided for in UI Automation (Windows platform) but are they
provided on others?

Filed from the feedback from APA WG.

July 29th F2F Agenda Item - Opt-in/opt-out of editing features and menus

Original issue w3c/editing#141, w3c/editing#93

In summary, we want to be able to specify 2 lists of allowed/disallowed editing features for

1. Individual editing hosts, and
2. Preferably avoid polluting the HTMLElement interface
   • Maybe a new HTMLElement subclass? Not sure it will work for cE

---

@johanneswilm has proposed a solution w3c/editing#93 (comment)

We can then have both opt in and out and a keyword "all" that enables or disables everything. Something like:

let el = document.getElementById('editor')
let editor = el.getEditor()

editor.disableCommands(['all']) // disables everything
editor.enableCommands(['copy','paste','cut','bold','underline']) // reenables the given array of commands
editor.checkCommands(['enlarge']) // True if the browser's UI supports a command with the name "enlarge"

Partial inteface cannot have a constructor

https://w3c.github.io/input-events/#interface-InputEvent

[Constructor(DOMString typeArg, optional InputEventInit inputEventInitDict)]
partial interface InputEvent {
    readonly attribute DOMString     inputType;
    readonly attribute DataTransfer? dataTransfer;
    sequence<StaticRange> getTargetRanges();
};

Per https://heycam.github.io/webidl/#Constructor [Constructor] only means something for interfaces, not partial interfaces.

Instead, it'll have to be:

partial interface InputEvent {
    readonly attribute DOMString     inputType;
    readonly attribute DataTransfer? dataTransfer;
    sequence<StaticRange> getTargetRanges();
};

partial dictionary InputEventInit {
    DOMString inputType = "";
    DataTransfer? dataTransfer = null;
};

(Or similar.)

replace undo/redo with events that only change DOM?

_@ojanvafai wrote on August 18, 2016 23:59 in #18 _

I wonder if a similar logic would apply to undo/redo, i.e. make preventDefault not prevent the items from getting popped from the undo stack? The complicated thing there is coming up with the name since undo/redo can both do deletes and insert. undoModification and redoModification maybe? That's wordy, but I think it at least would make it clear that the event is for the DOM modification, not the other parts of the user action.

[beforeinput] Add InputType 'deleteByKill', 'insertFromYank' and 'transpose'

From @choniong on August 24, 2016 15:58

On MacOS the hotkey ctrl-t will transpose the two character besides cursor (Chrome and Safari), e.g.

1. a|b => ba|
2. ab|$ => ba|$

Should we:

1. Create a separate InputType, or
2. Just fire insertText with the target range?

Copied from original issue: w3c/editing#148

Trigger beforeinput event from JS with measurements.

This came up in today's Editing taskforce call. We discussed whether Selection.modify [1] could be used to create beforeinput events in JS with correctly measured target ranges. The difficulty is to add the right target range -- for example to cover what the browser sees as a word backward or alike.

So if I wanted to create a beforeinput event with the inputtype "deleteWordForward", it seems I would do something like this:

let oldRange = selection.getRangeAt(0)
selection.modify('extend', 'forward', 'word')
let newRange = selection.getRangeAt(0)
selection.removeAllRanges()
selection.addRange(oldRange)

triggerBeforeInputEvent('deleteWordForward', newRange)

Where triggerBeforeInputEvent will then convert the newRange lvierange to a static range and trigger the corresponding event.

So it seems to me that it is possible to use, but it will require the temporary loss of the selection. Having to lose the selection seems like an inconvenience that will be OK a lot of times, but probably problematic during some other times, for example during IME input when the selection cannot be touched.

So the question is: Is this a good way of doing it? Should this be what we recommend JS developers do?

[1] w3c/selection-api#37

NULL is not a valid value

Probably you mean null.

Invalid Web IDL syntax

StaticRange[] is not valid Web IDL syntax. Probably you want sequence<StaticRange>.

What should happen when insertFromComposition is canceled

When insertFromComposition is canceled, we can't continue to have the text being composited since UA doesn't have the capability to keep input methods and keyboards open in some platforms. i.e. we need to remove the currently composting text from DOM.

There are two behaviors we can implement:

Fire another insertCompositionText to replace the composition with an empty string when insertFromComposition is canceled.
Before firing insertFromComposition, fire another insertFromComposition to replace the composition text with an empty string just like we do in deleteByComposition before starting composition.
(1) is weird because it would mean that we would fire an extra composition event after the composition had logically ended.

(2) makes sense because we already delete the existing content with deleteByComposition before entering input methods in reconversion case. We're simply following the same pattern when we're exiting the composition by first emptying the composing text, and then inserting the confirmed text.

[beforeinput] Rename drag&drop to deleteByDrag&insertFromDrop

From @choniong on August 24, 2016 15:17

We should use the name deleteByDrag&insertFromDrop to make it clear that the event is only for DOM modification. (e.g. Preventing deleteByDrag won't stop the drag&drop process)

Background:
Assume we all agree that InputEvent should only focus on DOM modification w3c/editing#144 (comment), and we are renaming cut&paste to deleteByCut&insertFromPaste.

Copied from original issue: w3c/editing#147

July 29th F2F Agenda Item - Non-cancelable event 2 of 2

From @gked on July 29, 2016 22:17

Android and IOS to investigate whether the above it is possible to come back to the original state before compositionStart if input is cancelled in the middle of the composition.

Copied from original issue: w3c/editing#140

inputType for Menu Bar>Edit>Delete (no obvious direction)

From @choniong on July 20, 2016 15:11

Should we add a new inputType (DeleteContent/Selection/?) since there is no obvious direction?

e.g. On Mac it will delete selection, and do nothing if collapsed.
(On other platforms the classic Menu Bar is not always shown.)

Also Note:
Menu Bar delete also acts as Kill on Mac, so later you can Yank by Ctrl+y.
I'm not sure if we should add new types, or can we just use Delete* and Insert*?

Copied from original issue: w3c/editing#130

July 29th F2F Agenda Item - History handling (undo/redo)

From @gked on July 29, 2016 20:16

What should the relationship between browser-controlled editing history and beforeInput event be? Should redo/undo have beforeInput events?
If JS handles beforeInput events, should the browser try to figure out what changes were made? Is that technically possible?

Copied from original issue: w3c/editing#136

Add InputType 'insertReplacementText' for all spellcheck and substitution related actions

We don't have InputType for spellcheck right now, assume we want one, should it be spellcheck or insertFromSpellcheck or something else?

order of events -- where defined

I cannot see that we came up with a solution where the order of events for these should be defined:

beforeinput/input events in relation to:

• clipboard: paste/cut
• history: undo/redo
• dragging: drag/drop

Can we make mutation to DOM cancelable during IME?

Background
Originally I proposed #34 because I was under the impression that the Editing TF has already made the conclusion that we cannot do anything to composition text. However @yosinch reminded me that we haven't yet got a conclusion.

Two Proposals
After digging into mailing list I found @ojanvafai 's email[1] about two proposals:

1. Spec UA's behavior during IME, assuming they aren't always preventDefaultable.
   • This is what we are currently doing
2. @rniwa 's proposal[2]: Make the mutation to DOM cancelable (But IME state remains untouched)
   • Could also be applied to cE=true
   • UA may decide to cancel IME session if JS failed to update DOM with expected composition text

I'm not sure what's the outcome from TPAC 2015's discussion and I cannot find minutes / resolutions (Edited: Here is the meeting notes[3] for the breakout session, but I can't find discussion about @rniwa 's proposal).

So what's the reason we didn't go with proposal 2?

[1] https://lists.w3.org/Archives/Public/public-editing-tf/2015Oct/0117.html
[2] https://lists.w3.org/Archives/Public/public-editing-tf/2015Oct/0085.html
[3] https://lists.w3.org/Archives/Public/public-editing-tf/2016Jan/0002.html

Add `sequence<StaticRange> targetRanges` to `InputEventInit`

Since InputEvent has method getTargetRanges(), it would be reasonable to add

sequence<StaticRange> targetRanges = [];

to InputEventInit.

---

Also, can we change

"sequence getTargetRanges();" => "sequence<StaticRange> getTargetRanges();"

Publish First Public Working Draft of Input Events?

Please +1 / -1 on this issue, or reply to the thread on public-webapps, before the end of the day 22 August 2016. It is unnecessary to do both.

Events do not have "default action"s

The concept is not defined.

Probably instead what you want to do is define an algorithm for performing certain operations. During the course of that algorithm, fire the event. Then, check if the event has been canceled. If not, perform other actions.

Track the source of Intentions

From @BenjamP on November 11, 2014 0:26

beforeInput.intentionSrc or similar should track the originating event or input control.

Copied from original issue: w3c/editing#19