[samwillis]

My prediction is that in 2-3 years we will see WASM being used to run desktop class rich text editors in a canvas (much like Google Docs now does), and an open source framework will appear that enables it.

I would even go as far as suggesting WebKit compiled to WASM would be better than trying to make a rich text editor based on contenteditable work everywhere, once you have it working in one version it runs “everywhere”. Although accessibility is going to be the main disadvantage of such system.

[josephg]

The other downside is that text editing interacts with a lot of native OS controls. For example, iOS needs to use the OS's keyboard (which is configured outside the web browser). And the user should be able to tap-and-hold to select text just like they can in other webpages and apps.

This sort of behavior is basically impossible to reimplement in javascript for every platform in a way that feels "native".

[samwillis]

Yes, maybe my 2-3 years is optimistic. I think ultimately it’s JS APIs for the native controls that need to be exposed rather than better contenteditable.

[josephg]

Accessibility APIs exposed via javascript? Sure. But all the other APIs you'd need would be a mess.

For example, what would an API look like to support international character combining? Or drag-select on mobile? Or custom keyboard inputs? How do you respect the user's OS level configuration - Like system-wide emacs shortcuts in macos, weird keyboards on samsung phones or overridden fonts for people with reduced vision?

Adding javascript APIs for all this stuff would hurt privacy on the web, because this data is full of entropy for anyone doing fingerprinting.

And it wouldn't even solve the problem. You'd still need user code (JS/WASM) to correctly implement platform-specific behaviour for everything to feel native. Thats a janky ride every time.

I'd much rather web browsers to just expose each platform's native rich text editing controls. They work great already. They already do accessibility, and have full support for the platform's native text editing controls and behaviour. And there's a precedent for this sort of thing - web browsers have had INPUT elements forever.

[continuational]

The thing is, letting the user format some text as bold isn't really enough for many use cases. You need custom block and inline elements, such as tables, highlighted code or formulas.

[josephg]

It won't be simple or easy, but this sounds like a solvable technical problem. Its solvable today if you're willing to use hacky javascript.

Inline blocks should probably be embedded DOM nodes or something - just like contentEditable does today. Then they can be themed & styled like everything else - using CSS.

There's some complex UX patterns to manage - like deciding what should happen if the user hits backspace when their cursor is right after an inline block element. If the user uses the keyboard to move the cursor "past" an inline block element, should the cursor enter the element or skip it?

This sounds like exactly the sort of problem that the web standards committee is designed for.

[corrral]

I'm dreading Canvas + WASM. Sites that intercept scroll and touch events with Javascript are already rage-inducing to use, especially on mobile. I can't imagine that taking even more of the UI interaction away from the browser will improve anything.

[samwillis]

So am I, however it's really going to shine with things like SQLite for client side data storage, and for complex graphics client side by using desktop class graphics libraries.

Skia have a WASM port, I could see it being an amazing base for a graphics/rich-text product: https://skia.org/docs/user/modules/canvaskit/

I think the difference is WASM will be really good for content creation (see Figma), but we really don't want it for content consumption - unless its seriously clever visuals or background data processing.

[jokethrowaway]

We already have egui which is pretty awesome.

Not great for accessibility though (yet)

https://github.com/emilk/egui