- From: Klim Lee <notifications@github.com>
- Date: Tue, 02 Jun 2015 17:25:47 -0700
- To: w3c/editing <editing@noreply.github.com>
- Message-ID: <w3c/editing/issues/55/108139096@github.com>
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