网站设计必须考虑表格验证。随着不断的积累，我们知道表中的内联验证在工作中非常有用，但在失败时会令人沮丧。很多时候，它会导致无休止的破坏性错误消息或死胡同，没有机会逃跑。

毫无疑问，内联验证有很大的优势。当用户输入时，我们验证输入，所以当人们从一个绿色选择标记移动到另一个绿色选择标记时，我们增强了信心，创造了一种进步感。如果输入需要特定类型的内容，我们可以立即标记错误，以便用户立即修复它们。这在选择安全密码或用户名时特别有用。

但是内联验证也可能会出现问题。主要是因为我们不能在正确的时间表现出错误。除非他们清楚地告诉我们，否则我们不能真正确定用户何时真正完成输入。单击提交按钮是一个非常清晰的信号，用户认为它们已经完成了，但我们通常考虑将输入字段作为足够强的信号来启动输入字段的验证。这通常是一个正确的假设，但因为它只是一个假设，最终对一些用户来说是错误的——我们只是不知道有多少人会受到它的影响。

当然，我们不想表现出错误的错误；我们不希望用户在输入时闪烁的错误消息让他们感到困惑和沮丧。当错误发生时，我们希望表现出错误，并希望在修复后用友好的绿色复选标志代替它们。有多难实施？事实证明，这确实很有挑战性。有许多令人惊讶的内联验证方法。多年来，我们学会了避免过早输入字段时，我们学会了避免过早验证——内联验证。在这种情况下，在用户有机会输入任何内容之前，我们会过早地显示错误。没有帮助，令人沮丧。

最后，当用户打字时，我们转向实时验证。为此，我们定义了每个字段输入字符的阈值，然后开始验证。这并没有完全消除挫折，而是延迟了它。当用户最终达到阈值时，如果输入不完整或格式不正确，他们将开始面临过早的错误消息。

内联验证通常需要相当精细和严格的格式规则。例如，我们应该在什么时候验证日期输入的日期和月份？我们是单独验证它们，还是整体验证日期？由于日月输入相互依赖，因此很难在那里进行内联验证。从测试的角度来看，验证日期似乎有助于避免过早的错误。在实践中，每种输入和每种类型的输入都需要自定义验证规则的对话。

最常见的内联验证类型是后期验证：一旦用户离开输入字段（on blur），我们验证证输入，并在填写或复制和粘贴数据时保持原始。这无疑可以帮助我们避免闪烁的错误。然而，我们假设从一个领域到另一个领域的发展顺序是特定的。我们还将提醒用户中断他们的过程，并在错误发生后返回修复错误。

用户可能真的忽略了输入字段，但这并不是唯一的选择。他们最好只是误入错误的领域，然后立即离开。或者他们必须跳回最后一个字段来纠正验证器触发的错误。或者他们跳过了输入字段，因为他们只是想摆脱其他东西。或者也许他们只需要删除输入，然后移动到另一个浏览器的选项卡来复制和粘贴一串文本。

在实践中，很难让空白字段周围的用户体验正确。再一次，我们无法预测用户碰巧发现自己的环境。事实证明，他们并不总是从头到尾都有完美的线性体验——它通常是混乱的，几乎是不可预测的，有很多跳跃和自发的修正，尤其是在复杂的多列形式中。作为设计师，我们不应该假设填写表格的具体顺序，也不应该期望和依赖特定的选项卡行为。