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

I feel strange advocating a feature I don’t use. Just a reminder: if we drop it, cE=typing will be the only control not responding to system-set typing mode.

At the same time, I now think what I wrote above is broken/incomplete for the reason we never discussed. What happens on a platform that does not support overtype? Does the fact that we expose a specific method mean we *require* all UAs to implement overtype internally, regardless of system-wide support? (I hardly imagine overtype on iPhone, let alone wearables or whatever may come tomorrow.) If not, and UAs should use system-implemented input, do we need an exposed method at all, or should UAs handle that internally (‘inherit’ from system settings, set their own input mode) and only change `inputType` intrinsically? 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?

In my opinion, we shouldn’t require overtype support. It may be a good feature, a bad feature, but it’s certainly not essential for the ability to type (there was no ‘Insert’ key on NeXTSTEP in CERN). We also don’t want a platform-specific method. I’m inclined to drop the method, but keep support for `inputType: overwriteCharacter` for UAs that allow it.

Now, that may sound like more platform-specific behaviour; but it’s the opposite. Neither overtype support nor lack thereof affects what happens, only how.

Sorry for being verbose.

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

Received on Wednesday, 3 June 2015 00:26:15 UTC