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

>  Does the fact that we expose a specific method mean we require all UAs to implement overtype internally, regardless of system-wide support? 

Yes, they need to support overtype if they want to implement the spec entirely. The idea with the spec is that editor developers know exactly what does and can happen in the editor. 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. 

We could add some wording about "If the UA supports overtyping then it MUST..." That would make it possible to implement the spec without supporting overtype in the UA. I doon't necessarily think that is a good idea. It could mean someone creates a webbased VI-vlone, and it works everywhere except on Mac, where the overtype mode is just broken.

>  If we do expose the method, and given that the overtype feature is indeed system-wide, do we expect UAs to set current input mode for the entire system, or just locally? If the former, aren’t we treading on a territory we don’t own? If the latter, aren’t we asking too much of UAs, in case ‘local’ input modes are not supported at all on a given system?

I tried it here on Linux, and setting overtype in one program did not enable it in other programs. What do you mean by "‘local’ input modes are not supported at all on a given system". Aren't we kind of defining how this input mode is working? 

> I’m inclined to drop the method, but keep support for inputType: overwriteCharacter for UAs that allow it.

What we try to avoid here is the kind of magic that we currently have in contenteditable which led us into the mess we are currently in. The editor JS should under all circumstances know exactly know what is going on and figure out what to do with user intentions. So the user intention may be to enable overtype, but the JS editor needs to be able to figure out what to do with that request.

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