Re: [w3c/editing] EditContext: Who's going to handle caret navigation? (#266)

> * "intention" detection will be tricky to get right (OS-specific, key combinations, etc.)

Our latest thinking is that the EditContext can now be associated with one or more DOM elements.  The association allows certain editable behaviors to be enabled on the active, EditContext-associated element.  One of those behaviors is the dispatching of a `beforeinput` event, which communicates the user's intent.  

I think that will address this concern, but if there are user intentions relevant to editing that are not covered by `beforeinput` events please call those out specifically and we can discuss how to detect them. 

> * calculating the results for all the interactions is extremely tricky (page up/down, arrow keys themselves)

Content-based navigation can be handled by the EditContext.  In [beforeinput terms](https://www.w3.org/TR/input-events-1/#interface-InputEvent-Attributes) this includes the selection location after these editing operations:
* insertText
* insertReplacementText
* insertLineBreak
* insertParagraph
* insertTranspose
* insertCompositionText
* deleteWordBackward
* deleteWordForward
* deleteHardLineBackward
* deleteHardLineForward
* deleteContent
* deleteContentBackward
* deleteContentForward

And also includes the selection location after the user initiates these explicit caret/selection movements (I've just extracted these names from the Chromium list of [editing command types here](https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/editing/commands/editing_command_type.h;bpv=1;bpt=1;l=14) to try to be complete):
* moveBackward
* moveForward
* moveLeft
* moveParagraphBackward
* moveParagraphForward
* moveRight
* moveToBeginningOfDocument
* moveToBeginningOfParagraph
* moveToBeginningOfSentence
* moveToEndOfDocument
* moveToEndOfParagraph
* moveToEndOfSentence
* moveWordBackward
* moveWordForward
* moveWordLeft
* moveWordRight

The location of selection would be reported in the `textupdate` event dispatched to the `EditContext` and the author would then translate the text-based offsets describing the selection into their own document model and view.

Layout-based navigation **cannot** be handled by the EditContext (at least not as currently defined).  These would be the responsibilty of the author:
* moveDown
* movePageDown
* movePageUp
* moveToBeginningOfLine
* moveToEndOfLine
* moveToLeftEndOfLine
* moveToRightEndOfLine
* moveUp

Some editing operations from the [InputEvents specification](https://www.w3.org/TR/input-events-1/#interface-InputEvent-Attributes) also require layout information which **cannot** be currently handled by the EditContext:
* deleteSoftLineBackward
* deleteSoftLineForward
* deleteEntireSoftLine

The biggest impediment to implementing operations that require layout information is the lack of it.  We could either introduce APIs to query line layout information to help with the implementation of these editing operations, or it may be sufficient to just provide an API like [Selection.modify](https://developer.mozilla.org/en-US/docs/Web/API/Selection/modify) - given a caret position you can find another in a given direction and for a given unit.  

Note that it is also getting easier to implement line layout with proposals like [Canvas Formatted Text](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Canvas/FormattedText.md).

> * mouse + touch + pen + whatever else come to your mind – you just don't want to do that in JS

If you implement your own selection, like Monaco, Word, GDocs, then these events are the responsibility of the author.  I read this point as wanting to use native selection and the caret with editable regions that are enabled via EditContext.  I don't have an answer for how that will work yet, but will try to define something.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/266#issuecomment-674104419