michael / svedit

https://svedit.vercel.app
MIT License
109 stars 3 forks source link

Svedit on mobile? (did a testrun on Android) #16

Open michael opened 2 weeks ago

michael commented 2 weeks ago

TL;DR: We have a long way to go; Chromeless content editing on mobile is really hard to do.

BUT: Quite a few things work nicely already. And I think it's worth exploring this territory.

Some issues:

Considerations:

PS: There's hope that Blink comes to Safari, which could really help us here: https://9to5mac.com/2024/10/23/ios-18-2-web-apps-browser-engine-in-the-eu/

johannesmutter commented 1 week ago

I think we should try to keep the keyboard always open for any active DOM selection (…) not rendering a toolbar on the page.

Do you mean the native QWERTY keyboard? I think this should only be open when you want to insert/edit text, as it takes away too much screen.

intuitively select multiple blocks on mobile

Craft has solved this quite nicely: swipe from the right edge to left to open the "multi select mode". Now little circles appear next to each block, tab multiple of these circles to make a selection.

https://github.com/user-attachments/assets/68c847e3-615b-4567-9f66-c100e837b78d

michael commented 1 week ago

For context: The overall idea of our current "Svedit approach" is to always drive the editor by a native DOMSelection. On the native browser level, these are all text selections, but some of them (when spanning over multiple blocks) are mapped to "container selections" in our internal model.

Assume someone makes the following selection on mobile:

image

The text selections starts at "You only..." and ends at "...lines of code" in the next block. Basically you first have the cursor before the "You" callapsed. The soft keyboard is visible now, because you are in a text selection. Next you expand the selection by dragging the text handle and move it further down. During this drag there's an implicit transition from a text selection as soon as you cross field or block boundaries. I don't want to interfere with what the browser does here, so hiding the soft keyboard during making a text selection would turn into a flickery experience. That's why I thought we maybe should keep the keyboard open all the time. Basically creating an experience similiar to Apple Notes on iOS. The keyboard is always open there and the contextual tools are shown right above the soft keyboard.

The Craft-UI uses a completely different approach tailored for mobile (with special click and drag handlers that have nothing to do with native DOM selections in a browser). It's possible that we'll fail on mobile with our native selection approach, and then we are forced to somehow create two different editor experiences (one for desktop and one for mobile), but I'd first like to find out how far we can come with the pure DOM selection approach.

Because we get so many things for free:

TL;DR: This is a very difficult problem we want to crack here, so I really don't know how far we'll get how fast, but i'm really keen to try create a mobile editing experience based on native DOM selections.

PS: I understand now that we can't customize the soft keyboard (and add arrow keys for instance), so we need to render all contextual tools above the keyboard.