How do we switch the caret between overtype and insert mode?

[johanneswilm]

What method should we use to switch between the caret in insert and overtype mode?

[NorbertLindenberg]

If by overtype mode you mean that each newly typed character replaces one existing character: I don't think that even exists on Mac or iOS; I don't know on which other platforms it does exist. I also have no idea how it would work for languages with more complicated character models, such as Hindi. Do you have more information on that?

[johanneswilm]

@NorbertLindenberg If you are on a PC (Windows/Linux), and you click the "Insert" key, you will notice that in most applications you now have a caret that will let you do as you described above. This works in most editors where contenteditable is used.

[chaals]

Yuk. (Yeah, I know over overtype mode).

Honestly, I would love to say "you overtype if there is something selected, otherwise the mode doesn't exist". What would that break in practice?

[ghost]

Is there anything else affected by the mode apart from inputType property? What’s the supposed scope of the mode (i. e. typing container or document)?

BTW, on Mac there’s no overtype globally, but it’s sometimes supported on application level (vi, Brackets).

[johanneswilm]

What’s the supposed scope of the mode (i. e. typing container or document)?
I would say typing container.

To me personally the overtyping mode is mainly just annoying, similar to "Caps lock". It's just a key one hits accidentally and usually ends with one having to rewrite part of the text. But given that it's there, and people use it for something, we probably cannot just discard it altogether.

[chaals]

Actually, I think we could discard it. While people use it, I'd be surprised if its a really important feature.

I'd love to hear from anyone who has actual usage statistics…

[ghost]

People use it for something, we probably cannot just discard it altogether.

I agree. Although I also agree that it could be annoying, it’s still used by some. Do I understand correctly that on Windows/Linux overtype is a system-wide feature that applies to any input? If so, dropping it is a no go, as developers expect system-wide features to work system-wide.

On typing container, that could be something like setInputMode(). For multiple reasons, I’d stick with DOM conventions and pass predefined numeric constants as mode identifiers (INSERT_MODE and OVERTYPE_MODE or something); but we’ve got no namespace to put those constants in. (You may argue that namespace for two constants is an overkill, and I’d probably agree.)

[johanneswilm]

Do I understand correctly that on Windows/Linux overtype is a system-wide feature that applies to any input?

Indeed, it works just about everywhere and it works in contenteditable. An exception are text input boxes like the github one I'm typing in right now, that were built from the ground up in JavaScript where the authors of that particular JS library decided not to support it.

On typing container, that could be something like setInputMode(). For multiple reasons, I’d stick with DOM conventions and pass predefined numeric constants as mode identifiers (INSERT_MODE and OVERTYPE_MODE or something); but we’ve got no namespace to put those constants in. (You may argue that namespace for two constants is an overkill, and I’d probably agree.)

Sure, what's your suggestion to do then?

[ghost]

Indeed, it works just about everywhere and it works in contenteditable.

Then I’m sure we should not discard it.

If we decide we don’t want to use a global namespace for that, we just stick with string identifiers: e. g. setInputMode("overtype"). It’s not really that bad, it wouldn’t be the first API to use strings: DOM event IDs have been strings for decades, despite that the same DOM uses numeric constants elsewhere. Eventually, we may end up in need of a namespace for other parts of the spec, so it’s a difficult decision to make in such an isolated context; if there are other benefits of a global namespace, I’m personally more comfortable with constants (rigidity is good). But even if not, nobody ever died of strings. It’s still more neutral and potentially extensible than specific methods, like toggleOverwrite(boolean) in CodeMirror.

In case of strings, setInputMode() should probably do nothing for strings it can’t recognise, the same way execCommand does nothing for non-existing commands (I don’t think developers will need the ability to set and implement custom input modes like they do with custom events in addEventListener; I do think we may have to define additional modes in later versions of the spec, so by extensibility I understand the latter, and not the former).

I think pros and cons of constants are clear by now, so I’m interested in what others may think.

[NorbertLindenberg]

Indeed, it works just about everywhere and it works in content editable.

Then I’m sure we should not discard it.

I don't think that's the right criterion to use. The contentEditable="typing" is a new self-contained block of functionality, and will be used to create new applications, so this is the right time to revisit some old assumptions about requirements. A more interesting question is "how many people are going to miss overtype if it's not there, and for how long?". I understand that's also a harder question to answer, but without that kind of question our computers would all still have floppy disk drives.

[ghost]

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 are assumed to 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? 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.

[johanneswilm]

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.

[johanneswilm]

@klimlee So I think that 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 would vote for dropping overtype altogether. It can always be reintroduced in a later version of the spec.

[chaals]

Agreed we want to avoid a mess that makes implementation harder. But this is basically a user-facing option and it is unclear whether users will be really upset if it disappears. In particular, I don't know what the use cases are beyond "deal with someone pressing the insert button on a 1980s keyboard"…

What about:

1. There is an event for a request to overtype, since there is a use behaviour on lots of systems that does this.
2. Expected behaviour is to say "we don't support that".
3. We note that some people may implement something different (such as allowing overtype mode).

And FWIW I believe the "modern style" for APIs is to use strings rather than numerical constants as identifiers for things like events.

[johanneswilm]

In particular, I don't know what the use cases are beyond "deal with someone pressing the insert button on a 1980s keyboard"

I have an insert-key on my 2015 Thinkpad. Mac OS X may be the most common OS among developers these days, but lets not forget that there are still many people running Windows in this world.

What about:

1. There is an event for a request to overtype, since there is a use behaviour on lots of systems that does this.

Right now we have a beforeInput event for this, that lets us know about a user's "intentions".

1. Expected behaviour is to say "we don't support that".

Right now, there is no default behavior for all or most of the events within ContentEditable=Typing that are marked as intentions. So it's just an event that a piece of JS may choose to hook in to. If nothign does that, nothing happens.

1. We note that some people may implement something different (such as allowing overtype mode).

Yes, but for that they need to be able to show the overtype caret, so we need to make that possible. All movement and insertion is handled in JS, with the exception of some parts of IME-based insertion of new content. In that case it would have to look a bit different visually as the current character is covered during the composition process while in overtype mode. Thisis the entire reason overtype needs to be mentioned in the spec if it is supported.

[chaals]

(Sorry, I know that most keyboards still have an ins key and that MacOS is actually a niche product. I'm just not sure that ins is a commonly used key any more).

So we have the event requesting overtype...
If people try to set overtype, it should either work or tell the user it doesn't, rather than silently failing. Although I can see why implementations might prefer to silently fail.
I think those two things are why we need to mention overtype

The most obvious way I can think of to handle the interaction seems to be that you select a character, when a character is typed it replaces that one and the next character is selected... that re-uses what we do in typing, provides a visual indicator that uses platform hooks which should be easier to make accessible than doing everything ourselves, … But of course it's vapourware in my head, not a working implementation.

[johanneswilm]

Thinking about it, you may be right, that could be a way to implement overtype in userspace.

As for the silent failing: currently all events associated with an editor fail silently in contenteditable=typing: pasting, inserting a character, marking text as bold, etc. . Nothing works by default and no preventDefault() has to be issued on things one does not want to work.

[ghost]

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.

[johanneswilm]

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 #58 ).

[kojiishi]

It depends on how you define "system-wide feature." It's not a feature like IME or Caps Lock where system holds a global state, and have APIs to manage it.

On the other hand, most apps on Windows used to have the feature, including ones from MS. In that sense, one may call it a "system-wide feature;" available in every text edit in the system.

However, it's also true that some MS apps started to get rid of the feature, such as MS Word. I just tried notepad on Windows 8.1 and it does not seem to work any longer.

So I think what's important for now are:

• Make sure to know who wants it, and ask how strong it is for v1.
• Make sure to reach possible important developers who might build apps/libraries on top of ce=typing.
• Make sure it's possible to add in future.

To do that, I think we'll need MS reps to join the conversation. Maybe keep as an open issue, mark in the spec, and go on?

[johanneswilm]

Off-topic, but till important:

Make sure to reach possible important developers who might build apps/libraries on top of ce=typing.

I think I've written to all major editing libraries about the editing task force. The two big ones (TinyMCE and CKEditor) have been active in the discussion here on Github. Aloha Editor was at the Xtensible Web Summit in Berlin last year where several of us met for the first time, but they were already well on their way to create their new 2.0 editor which is not based on contentEditable. The Wikimedia Visual Editor people have briefly been active on the email list. Also the Codemirror main developer is aware of this effort. And then there are the Google and Microsoft teams with their various online editors who have not been directly active here, but at least the Microsoft people spoke through Benjamin earlier. Maybe we should try to write to some of them again now that there is more of a solid proposal.

[johanneswilm]

To do that, I think we'll need MS reps to join the conversation. Maybe keep as an open issue, mark in the spec, and go on?

The spec already talks quite a bit of overwrite vs. insert mode. Now I am thinking maybe we should just remove the overtype part for now and just add it as an issue that can be added in a future version.