什么事件触发 Javascript 表单字段验证和格式化？
首先我要说的是，我们验证服务器端的每个字段，所以这是一个问题 关于客户端可用性。
关于使用 JavaScript 验证和格式化 html 表单输入字段的确切时间的传统观点是什么？
例如，我们有一个电话号码字段。 我们允许使用数字、空格、括号和连字符。 我们希望该字段有十位数字。 另外，我们希望该字段看起来像 (123) 456-7890，即使用户没有这样输入。
看起来我们可以
- 在用户输入时验证并格式化它 退出场地。
- 验证并格式化 在输入的每个字符上。
- 拦截按键并防止 用户输入错误的字符。
- 上述的一些组合（例如 输入时格式化并退出时验证、输入时阻止并退出时格式化等）
- [已添加] 等待并在用户单击提交时执行所有验证和格式化。
我已经看到了所有这些方法，但我找不到关于什么的信息 从可用性的角度来看，这是最好的（甚至普遍接受的），更重要的是，为什么。
[编辑：一些澄清]
我们绝对不会强制执行任何格式标准。 当我说格式时，我的意思是我们将使用 javascript 重写内容，使它们看起来不错。 如果用户输入 1234567890，我们会将其更改为 (123) 456-7890。 不存在可能失败的“格式化规则”。
我将其与验证区分开来，因为如果他们没有输入足够的数字，我们必须让他们修复它。
我想我应该将问题改写为“关于确切何时验证和何时格式化的传统智慧是什么？
到目前为止，答案中的信息很好！
编辑：我接受我的下面是我自己的答案，希望其他人会发现该链接和我一样有帮助。
Let me first say, we validate every field on the server side, so this a question
about client-side usability.
What is the conventional wisdom on exactly when to validate and format html form input fields using javascript?
As an example, we have a phone number field. We allow numbers, spaces, parentheses, and hyphens. We want the field to have ten digits. Also, we want the field to look like (123) 456-7890, even if the user doesn't type it that way.
It seems like we can
- Validate and format it when the user
exits the field. - Validate and format
on every character entered. - Intercept keystrokes and prevent the
user from entering characters that are wrong. - Some combination of the above (e.g.
format on entry and validate on exit, prevent on entry and format on exit, etc.) - [Added] Wait and do all the validation and formatting when the user clicks submit.
I've seen it done all of these ways, but I can't find information about what
is best (or even generally accepted) from a usability perspective, and more importantly, why.
[Edit: Some clarification]
We are absolutely not enforcing any format standards. When I say format, I mean we'll use javascript to rewrite things so they look nice. If the user types 1234567890, we'll change it to (123) 456-7890. There are no "formatting rules" that can fail.
I distinguish this from validation because if they don't type enough numbers, we have to make them fix it.
I guess I should rephrase the question as "what is the conventional wisdom on exactly when to validate and exactly when to format...?
Good info in the answers so far!
EDIT: I'm accepting my own answer below in the hopes that others will find the link as helpful as I did.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
我见过的最用户友好的验证方法是在输入字段旁边显示一个指示器，以指示该值无效。 这样，您就不会在用户打字时打断他们，而且他们可以不断地查看他们是否输入了有效的条目。 我讨厌必须将信息输入到很长的表单中，结果最后却告诉我“哦，你需要返回并修复字段 1”。
您可以在用户键入时显示/隐藏指示器。 当值无效时，我使用警告图标，并在图标上设置工具提示来解释该值无效的原因。
如果您有屏幕空间，则可以仅输入“有效”或“必须采用 XXX-YYY-XXXX 格式”等文本。
请记住，当您进行每次击键验证时，您还需要捕获粘贴的文本。
除此之外，您还应该首先防止输入无效的按键。
The most user friendly way I've seen to do validation is to have an indicator that shows up next to the input field to indicate the value is invalid. This way you don't interrupt the user as they're typing and yet they can continually see whether or not they've typed a valid entry. I hate having to type information into a long form only to have the thing tell me at the end "Oh, you need to go back and fix field 1".
You can have the indicator be show/hidden as the user types. I use a warning icon when the value is invalid and I set a tooltip on the icon that explains why the value is invalid.
If you have the screen real estate, you could just put text such as "Valid" or "Must be in format XXX-YYY-XXXX".
Keep in mind that when you do per keystroke validation you also need to catch pasted text.
In addition to this, you should also prevent invalid keystrokes to be entered in the first place.
对于可用性最佳实践，我建议阅读如何设计完美表单（更准确地说上下文和内容）协助）和漂亮的表格。
对于表单验证框架，请检查 fValidator 和 iMask 组合，它们是互补的，因此可以完美地协同工作。
For usability best practices, I suggest reading How To Design The Perfect Form (more precisely Context & Assistance) and Beautiful Forms.
For a form validation framework, check the fValidator and iMask combo, they are complementary and thus work perfectly together.
我发现前三个选项真的很烦人。 没有什么比在打字过程中被打断更糟糕的了。
您的用户的主要目标是尽快完成表单，而您所做的任何减慢他们速度的行为都只是让他们完全放弃的又一个原因。
我也讨厌被迫输入一些内容例如信用卡#或电话#正是满足该表单的正确格式。 只要有可能，就给用户一个框来输入内容，不要让他们处理格式。
对于您的电话号码，让他们按照自己的意愿输入，删除您不喜欢的任何内容，尝试将其重新组合成您想要的格式（ (124) 567-8901 ），如果您这样做，则会抛出错误不能。
如果您绝对必须验证某些内容为特定格式，请在他们提交表单时执行此操作，然后突出显示有问题的字段。
I find the first three options to be really annoying. There's nothing worse than being interrupted in the middle of typing something.
Your user's main goal is getting through the form as fast as possible and anything you do that slows them down is just one more reason for them to give up on it entirely.
I also hate being forced to type something like a credit card # or phone # is exactly the right format to satisfy the form. Whenever possible, just give the user a box to type stuff into and don't make them deal with the formatting.
In the case of your phone #, let them enter it however they want, strip out anything you don't like, try to put it back together into the format you want ( (124) 567-8901 ) and throw an error if you can't.
If you absolutely must validate something to a specific format, do it when they submit the form and then highlight the fields that have problems.
我个人认为退出时的格式化和验证对用户来说是最不麻烦的。 让他们以他们喜欢的任何格式输入号码（电话号码有很多格式），然后将其更改为您喜欢的格式。 当您可以以用户喜欢的格式处理数据时，不要强迫用户遵守您的偏好。
此外，当我未完成输入时的验证消息很烦人，并且无法放置文本字段中的某些字符非常烦人。
我能想到的唯一例外是“这个值是否可用”的情况（例如创建一个唯一的用户名） - 在这种情况下，立即反馈确实很方便。
Personally I think formatting and validating on exit is the least bothersome to the user. Let them enter the number in whatever format they like (and there are a lot of these for a phone number) and then change it to the format you like. Don't force the user to conform to your preferences when you can handle the data in their preferred format.
Also, validation messages when I'm not done typing are annoying, and not being able to put a certain character in a text field is super-annoying.
The only exception I can think of is "is this value available" situations (such as creating a unique username) - in that case immediate feedback is really convenient.
这取决于每个领域。 但对于电话号码之类的东西，通常可以很好地阻止某人输入非数字。
这样，在输入时，您会注意到您的 1-800-HELLOWORLD 电话号码未正确显示，并意识到该字段仅接受数字（您也可以在输入字段旁边使用某种信息字段突出显示该号码）。
在我看来，这比尴尬的模式对话、弹出式错误字段或填写完毕后显示的服务器生成消息直观和友好得多。
当然，始终要平衡最终的客户端验证与构建它的最终技术要求。 例如，如果您在页面提交之前开始使用 Ajax 验证图像上传，那么这可能是一条相当漫长的道路。
编辑：另外，考虑一下你的观众。 与那些更习惯非 Ajax 互联网方法的人相比，更具技术头脑的人会更容易接受“动态”形式。
It depends per field. But for something like a phone number, it's generally pretty nice to prevent someone from even entering non-digits.
That way, when typing you'll notice that your 1-800-HELLOWORLD phone number isn't showing up correctly and realise that the field only accepts numbers (which you can also highlight with some sort of information field alongside the input field).
That seems to me to be a lot more inuitive and friendly than an awkward modal dialogue, pop-down error field or server-generated message displaying after you're done filling it out.
Of course, always balance the ultimate client-side validation with the ultimate technical requirements to build it. If you start down the path of, say, validating image uploads with Ajax before the page submits, that can be a pretty long road.
Edit: also, consider your audience. The more technically minded are going to be more accepting of "dynamic" forms than, say, people who are more accustomed to the non-Ajax approach to the Internet.
我本打算描述各种选项，但仅使用现有的 js 框架来处理输入掩码可能会有所帮助。 这里是各种选项的详细说明
I was going to describe various options but it may be beneficial just to use an existing js framework to handle input masks. Here is a good run down of various options
bmb 声明他们接受任何格式，并将其更改为所需的格式 (xxx) nnn-xxxx。 这是非常好的。 问题是 A) 格式更改和 B) 验证的时间安排。
A) 格式更改应在用户退出字段时完成。 早了会让人厌烦，晚了就完全失去了显示变化的目的。
B) 最适合在退出字段或提交表单时执行验证。 Sooner 会让用户感到沮丧和困惑。 在一份冗长而复杂的表单中，有多个屏幕，我倾向于在退出控件时进行验证，以便更容易进行更正。 在简短的表格中，我会在提交时执行此操作，以避免破坏填写表格的流程。 这实际上是一个判断调用，因此如果可能的话，请与真实用户进行测试。
无论如何，最好是与真实用户一起测试您的工作，但如果您没有预算或访问权限，快速而肮脏的“用户”测试可以帮助做出这样的决策。 您可以找一些没有使用该软件的人（尽可能接近您的真实最终用户）并要求他们填写表格。 指导他们专门输入错误信息，然后观察他们纠正错误。 让他们大声谈论他们正在做的事情，这样你就不需要猜测他们的思维过程。 寻找他们有问题的地方以及最让他们困惑/烦恼的事情。
bmb states that they are accepting any format, and changing it to the desired format (xxx) nnn-xxxx. That is very good. The question is the timing of A) the format change, and B) the validation.
A) The format change should be done as the user exits the field. Sooner is annoying and later defeats the purpose of displaying the change at all.
B) Validation is most appropriately performed either on exiting the field or on submitting the form. Sooner is frustrating and confusing to the user. In a long and complex form, with more than one screen, I would favor doing validation on exiting the control to make corrections easier. On a short form, I would do it upon submit to avoid breaking the flow of filling out the form. It is really a judgment call, so test it with real users if at all possible.
Preferably you are testing your work with real users anyway, but if you do not have budget or access for that, a quick and dirty "user" test can help with decisions like this one. You can grab a handful of people who did not work on the software (as close a match to your real end users as possible) and ask them to fill out the form. Instruct them to enter things a specifically to get an error and then watch them correct it. Ask them to talk aloud through what they are doing so you don't need to guess at their thought process. Look for where they have issues and what seems to confuse/annoy them most.
到目前为止，最好的答案不是答案，而是评论（见上文）。我将其添加为答案，以防有人在评论中错过它。
请参阅以下有关 A List Apart 的文章。
Web 表单中的内联验证，作者：Luke Wroblewski
By far the best answer so far was not an answer but a comment (see above.) I'm adding it as an answer in case anyone misses it in the comment.
See the following article on A List Apart.
Inline Validation in Web Forms by Luke Wroblewski
是的。 如果验证或格式化规则失败，向用户提供非侵入性反馈。 我所说的“noninasive”是指不要弹出警报或模式对话框，从而强制用户单击某些内容。 相反，动态地在验证或格式化失败的字段附近或下方显示一条消息。
不，我认为这会妨碍可用性。 相反，为用户提供工具提示或其他一些关于格式化规则或验证规则的提示。 例如，对于“必填”字段，星号几乎无处不在，而对于具有格式的字段，则预先告诉用户预期的格式是什么。
如果您要阻止用户输入无效字符，请告诉用户为什么您刚刚以非侵入性方式阻止了他们的输入。 另外，不要抢夺焦点。
所以对我来说，一般原则是：
Yes. Provide noninvasive feedback to the user if validation or formatting rules fail. By noninasive I mean don't popup an alert or modal dialog box, thereby forcing the user to click something. Rather dynamically display a message adjacent or underneath the field where validation or formatting failed.
No. I think that hinders usability. Instead provide the user with a tooltip or some other hint as to what the formatting rules are or validation rules are. E.g. for a "required" field the practically ubiquitious asterisk, and for fields with formatting tell the user up front what the expected format is.
If you are going to prevent the user from entering invalid characters, tell the user why you just blocked their input, noninvasively. Also,do not steal focus of the field.
So for me the general principles are: