Re: [editing] How do we switch the caret between overtype and insert mode? (#55)

> Given that Chrome has overtype support, I assume that also Safari has it, and that Mac user just don't access it because they don't have the needed `Insert` key on their keyboard.

I’m not sure about that. But I believe mobile platforms don’t support overtype and never will. So we’re practically requiring UAs to polyfill a missing OS feature on their own.

> It could mean someone creates a webbased VI-vlone, and it works everywhere except on Mac.

Well, you can’t `getUserMedia` on a platform with no camera; UAs are not required to reimplement a camera for that. Given that you can’t enable overtype on Mac, even vi itself only supports it because it handles modes internally.

> if the option is to have overtype happen "automagically" without any way for the JS editor to know about this or to interfere with it

I’m definitely not proposing that. I’m rather saying that the only thing overtype affects is the *type* of input events, not the *nature* of the input itself, and it *always* sets the intended `inputType`. We don’t care what the input mode is, unless there are actual input events that are intended as overtype, just as we don’t care what the keyboard layout is, unless there are events that are intended to translate specific characters. So it’s basically `inputType` that’s important, not some current mode per se. I’m saying that a) if overtype is implemented by the UA and b) it is currently enabled in the UA, then the UA must fire events with `inputType` set to `overwriteCharacter` to indicate intended overtype, instead of requesting overtype separately from the input itself. That practically means everything needed for overtype support is already in the spec: the expected `inputType` value. So we don’t define how to overtype, but define how to pass overtype intentions, if there are any.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/55#issuecomment-108416563