You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Once incremental frontend implementing (RenderDelta) is supported, it might be easier to have contentEditable cursor be in a consistent state.
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.
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.
The text was updated successfully, but these errors were encountered:
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:
Some device targets:
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.
The text was updated successfully, but these errors were encountered: