Add prevententersubmit attribute to form element

[NagayamaToshiaki]

In Japan (and countries that use IME) there is a problem that unintended press of enter key because they forget to turn on the IME. To fix the word input in IME, you typically have to type the enter key, so this kind of mistake happens.

To solve this problem, there are some JS workarounds, but it makes the behavior of the submit button unclear.

So I suggest the prevententersubmit attribute which, when it is set, disallows enter key to submit the form data.

[smaug----]

Why can't one have just a key event listener on the form element and call preventDefault() if the key is enter ?

[pshaughn]

This might be a general IME problem that shouldn't depend on page authors opting into the fix on a form-by-form basis.

Perhaps when IMEs that care about the enter key are in effect, a single enter press on a text input should just always bring up an IME interface instead of submitting. Is there a central place to specify/recommend IME behavior like that?

[NagayamaToshiaki]

This might be a general IME problem that shouldn't depend on page authors opting into the fix on a form-by-form basis.

I don't think so. IMHO the default behavior is awful. They (mostly europian language user) didn't consider IME user when they created the spec. If the spec came first, we might have a select word key besides the enter.

Perhaps when IMEs that care about the enter key are in effect, a single enter press on a text input should just always bring up an IME interface instead of submitting. Is there a central place to specify/recommend IME behavior like that?

When Windows IME (and other simular IMEs) is on "半角英数" mode, IME is effectively turned off, unless you type "半角/全角" key to activate Japanese input mode. So if input behavior changed, we will be confused.

[o0101]

Why can't one have just a key event listener on the form element and call preventDefault() if the key is enter ?

Too much effort. Should be as simple as adding prevententersubmit (good name, but could be shorter? hard task, I will try: ... actually it's really hard. But I think I have a solution, why not an ime attribute that can contain options (similar to the feature policy token list you can have in iframe's sandbox and allow attributes).

Do we really think we can write a spec in English, mostly by European authors (as OP says), and account for all the crazy IMEs around the world? Crazy in a good way, there's so many of them, and each so complex and locale specific. But we can't hope to understand all the nuances without being those users, so "speculating" (speccing?) for them / on behalf of them, without full understanding is wrong. And limiting, and costs people a lot of frustration (as OP hints at), when behavior doesn't make sense to people using it.

It's a can of worms, but would be good to have some options to allow authors to interface with and configure that complexity to some extent. Better to use HTML options than JS as you avoid the temptation to create an overly "complex and complete" API, but rather limit it to some achievable modest set of useful things, like:

<input type=text ime="noentersubmit">

I tried really hard to think of another good "feature policy" to add to that attribute but I can't. I'm not an expert and not the best person to be coming up with this. Would be great to have input from people using IMEs regularly.

Perhaps when IMEs that care about the enter key are in effect, a single enter press on a text input should just always bring up an IME interface instead of submitting. Is there a central place to specify/recommend IME behavior like that?

Yeah I don't think the form behavior should depend on whether an IME is active or in a particular mode or not, it would be confusing.

---

But thinking about it, IMEs are normally separate parts of the system to the browser (I think, at least on device). So how could something inside a HTML page in a browser, interface with and specify that "externality"? I think that would be too hard.

But then again the "host application" for the IME can inform the IME of things ("Sorry, GIF input is not supported here") so there must be some communication.

Massive can of worms, but would be great if it (spec) could make it easier. Rather than push complexity and confusion "downstream" to people IMEing. Would be good to solve (try to solve), some at least, upstream. I think options like this is tentatively a good idea!

[annevk]

@NagayamaToshiaki is this a problem across all operating systems or are some more problematic than others? Also, if you could provide more detailed steps to reproduce that would be great so we can study the exact scenario better.

[smaug----]

If this is a common issue, perhaps browser implementations should handle this internally. Many pages wouldn't use prevententersubmit, just because they are often developed by people not using IMEs.

[himorin]

@masayuki-nakano you may have something wanted to say?

[macnmm]

When native apps have issues with IME it is usually because they are not passing the key events to the IME to be processed before they do their own processing. Web apps should be able to do the same. It is not a good solution to just block enter key to submit; the correct behavior should be to end the active IME session with the enter key and enter to submit on the subsequent one. IMHO.

[masayuki-nakano]

I think that the motivation of preventing to submit the form by Enter key presses is not caused by wrong behavior of IME but also preventing user's error.

Typically, non-IME users do not press Enter at typing single line text unless they want to do something with Enter key like submitting the form. On the other hand, IME users press Enter key for committing conversion for every word (especially with Japanese IME. Chinese IME and Korean IME do not use Enter key to committing converting words as far as I know) or something using other IME features. Therefore, the number of accidentally pressing Enter key of IME users must be higher than the non-IME users'.

I think that the problematic scenarios are:

• User presses Enter key too long so that the auto-repeat is triggered
• User accidentally press Enter key twice, e.g., just twiched

The former may be prevented by the browser level, i.e., don't submit the form with Enter key press if it's caused by auto-repeat. However, the latter requires web author's intention. E.g., if the form is not so important data, e.g., chat tool, not working Enter as form submission makes users feel inconvenient. Therefore, it's impossible to do something in browser level, for example, once Enter key is used in <input>, stop handling Enter as submitting the form, etc.