tcr/edit-text

Support editing on mobile devices

tcr opened this issue · 0 comments

tcr commented

There are two major blockers to supporting mobile devices, with a long list of minor improvements. For my iPhone 6S, the following issues exist on Mobile Safari:

  • No keyboard is displayed. This is because mobile devices expect a keyboard-enabled element to have focus in order to show th ekeyboard.
  • The editor only listens for mousemove/up/down events. This should be transitioned to touch events or something using Pointer Events in order to work across devices.

Some device targets:

  • Chrome on Android
  • Firefox on Android
  • Safari on iPhone

Options to solve the keyboard issue

*A) Focus on the caret: A novel idea would be to turn the focused caret into an editor component to always remain in the current focus when editing. In any case, the keyboard only appears inside of elements designed to receive text, so a textarea or input type=text must be focused at all times. (Note: there should be a UI feature to dismiss the keyboard too.)

B) Leverage contentEditable: contentEditable isn't used in the editor because we want full control over how editing is performed, where cursors can be displayed, and we want to sync the state to other clients. But on the other hand, this requires reimplementing a lot of obvious client-side behaviors, including keyboard shortcuts for navigation.

  1. Once incremental frontend implementing (RenderDelta) is supported, it might be easier to have contentEditable cursor be in a consistent state.
  2. First pass would be displaying a transparent overlay to the document, allowing mobile clients to focus and move the caret on that. This then could use [curto] on the client in order to sync the true cursor in the background to its position.
  3. A more extreme change would be to support all of contentEditable to just enable true native cursor support, allowing native OS keyboard commands, but delegating all deletion events to the client itself. Cursors would still need to be synced under the hood to a "true" element location, and all caret locations that are possible on the client would need to be normalized to a caret position in the doc.