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.

The way you describe it, it sounds as if the UA simply lets the OS draw a text input window and then lets the OS deal with the caret. I am not an OS developer, but it is my understanding that it is the browser that does handles everything about text input. I am slightly unsure about the shape of the caret. Some comments at the last CSSWG meeting make me think that it is not entirely configurable by the browsers.

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

Ok, yes for input that should work. And if the "caret" in overtype mode simply is one character selected, then yes, I think this should be doable in userland. How to make sure that always one character is selected while in overtype mode will have to be handled in the JS. If caret movement is to be handled primarily by the UA (and not JS)< then it probably needs some definitions about how to move an overtype caret (as is discussed in https://github.com/w3c/editing/issues/58 ). 

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