[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.