3 ms·

> The problem is that you're going to need to get the data back out of WASM eventually, back into JavaScript and then back to the DOM. Could you paint everythi

> The problem is that you're going to need to get the data back out of WASM eventually, back into JavaScript and then back to the DOM. Could you paint everything in a canvas element to avoid the DOM? That is being my approach in a small project, although it admitedly can complicate things.

josephg 5y ago
Don't do that. There's all sorts of very complex OS-level UX controls which hook into a text box. If you implement your own text box using canvas, all this stuff will be broken by default. For example: - Ctrl+Left / right for moving a word at a time. This is Alt+Left/right on a mac I think. There's another keyboard shortcut to go to the start / end of a line, or the start / end of the input element. These shortcuts are OS-specific and can be overridden in the user's OS level settings - which you don't have access to from javascript. There's a mountain of shortcuts - like Ctrl+A, Ctrl+X/C/V, etc. They all vary per OS. You have to implement them correctly on every operating system. - International character input methods. Eg, how would you type Japanese / Korean / Chinese characters into your text element? - Undo/redo support - Text selection via the mouse, the keyboard and on mobile by touch-dragging to select. - Accessibility - like voiceover and dictation. No matter how dedicated you are, I guarantee your custom canvas element will never correctly re-implement all the features already available in a simple HTML text input element.
- mejutoco 5y ago
  I am aware of the tradeoffs and generally I agree. That is what I meant by it can overcomplicate things. It is all tradeoffs, and for some usages it might be a valid one to remove the dependency on the DOM. I see it as an option for a heavy app in the browser. This is AFAIK similar to what Figma does (or flutter). Also, I am not referring specifically to text editors, although I could imagine something like vim working with this approach in the browser without trying to replicate an HTML text input element.
- slight_glitch 5y ago
  Google Docs does that and it works. Not perfect, but good enough.

josephg 5y ago

Don't do that. There's all sorts of very complex OS-level UX controls which hook into a text box. If you implement your own text box using canvas, all this stuff will be broken by default. For example: - Ctrl+Left / right for moving a word at a time. This is Alt+Left/right on a mac I think. There's another keyboard shortcut to go to the start / end of a line, or the start / end of the input element. These shortcuts are OS-specific and can be overridden in the user's OS level settings - which you don't have access to from javascript. There's a mountain of shortcuts - like Ctrl+A, Ctrl+X/C/V, etc. They all vary per OS. You have to implement them correctly on every operating system. - International character input methods. Eg, how would you type Japanese / Korean / Chinese characters into your text element? - Undo/redo support - Text selection via the mouse, the keyboard and on mobile by touch-dragging to select. - Accessibility - like voiceover and dictation. No matter how dedicated you are, I guarantee your custom canvas element will never correctly re-implement all the features already available in a simple HTML text input element.

mejutoco 5y ago
I am aware of the tradeoffs and generally I agree. That is what I meant by it can overcomplicate things. It is all tradeoffs, and for some usages it might be a valid one to remove the dependency on the DOM. I see it as an option for a heavy app in the browser. This is AFAIK similar to what Figma does (or flutter). Also, I am not referring specifically to text editors, although I could imagine something like vim working with this approach in the browser without trying to replicate an HTML text input element.
slight_glitch 5y ago
Google Docs does that and it works. Not perfect, but good enough.