-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add prevententersubmit attribute to form element #8158
Comments
Why can't one have just a key event listener on the form element and call preventDefault() if the key is enter ? |
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? |
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.
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. |
Too much effort. Should be as simple as adding 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:
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.
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! |
@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. |
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. |
@masayuki-nakano you may have something wanted to say? |
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. |
I think that the motivation of preventing to submit the form by Typically, non-IME users do not press I think that the problematic scenarios are:
The former may be prevented by the browser level, i.e., don't submit the form with |
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.The text was updated successfully, but these errors were encountered: