表单验证是
网站设计必须要考虑的，随着不断的积累我们知道单中的内联验证在工作时很有用，但在失败时会令人沮丧。很多时候，它会导致无休止的破坏性错误消息或死胡同，没有任何脱身的机会。
毫无疑问，内联验证有很大的优势。我们在用户输入时验证输入，因此当人们从一个绿色复选标记移动到另一个绿色复选标记时，我们增强了他们的信心并创造了一种进步感。如果输入需要特定类型的内容，我们可以立即标记错误，以便用户立即修复它们。这在选择安全密码或可用用户名时特别有用。
但是内联验证也可能会出现问题。主要是因为我们无法在错误发生的正确时间真正显示错误。其原因是我们无法真正确定用户何时真正完成了输入，除非他们明确告诉我们他们已经完成。单击“提交”按钮是一个非常明确的信号，用户认为他们已经完成了，但我们的实现通常考虑将输入字段作为足够强的信号来启动对该输入字段的验证。通常这是一个正确的假设，但由于它只是一个假设，最终对某些用户来说是错误的——我们只是不知道有多少人以及多久会受到它的影响。
当然我们不想显示“错误”的错误；我们也不想让用户在输入时闪烁的错误消息让他们感到困惑和沮丧。我们希望在错误发生时显示错误，并希望在它们修复后用友好的绿色复选标记替换它们。实施起来有多困难？事实证明，这确实非常具有挑战性。有许多令人惊讶的内联验证方式。多年来，我们学会了避免过早的验证——当用户只关注一个空的输入字段时发生的内联验证。在这种情况下，我们会过早地显示错误，甚至在用户有机会输入任何内容之前。这没有帮助，而且令人沮丧。
最终我们转向了实时验证，这发生在用户打字时。为此，我们为每个字段定义输入字符的阈值，然后开始验证。这并没有真正完全消除挫败感，而是延迟了它。当用户最终达到阈值时，如果输入不完整或格式不正确，他们就会开始面临一闪而过的过早错误消息。
内联验证通常还需要相当精细和严格的格式规则。例如，我们应该在什么时候验证日期输入的日期和月份？我们是单独验证它们，还是将日期作为一个整体来验证？因为日和月输入是相互依赖的，所以很难在那里进行内联验证。从测试来看，一次验证日期似乎有助于避免过早的错误。在实践中，每个输入和每种类型的输入都需要关于自定义验证规则的对话。
最常见的内联验证类型是后期验证：一旦用户离开输入字段（on blur），我们就验证输入，并让他们在填写数据或复制粘贴数据时保持原样。这无疑可以帮助我们避免一闪而过的错误。但是，我们假设从一个领域到另一个领域的发展顺序是特定的。我们还会提示用户中断他们的进程，并在错误发生后返回修复错误。
用户可能确实忽略了输入字段，但这不是唯一的选择。他们还不如只是误入了错误的领域，然后立即离开。或者他们必须跳回上一个字段来纠正验证器触发的错误。或者他们跳过了输入字段，因为他们只是想摆脱其他东西。或者也许他们只需要清除输入，然后移动到另一个浏览器的选项卡以复制粘贴一串文本。
在实践中，让空白字段周围的用户体验正确是非常困难的。再一次，我们无法预测用户碰巧发现自己所处的环境。事实证明，他们并不总是从头到尾都有完美的线性体验——它通常是混乱的，几乎是不可预测的，有大量的跳跃和自发的修正，尤其是在复杂的多列形式中。作为设计师，我们不应该假设填写表格的特定顺序，也不应该期望和依赖特定的选项卡行为。
