通过ajax提交时为什么要使用表单标签？

哲学问题：

假设我有一个需要使用javascript和现代浏览器的网络应用，因此渐进式增强不是问题。如果我的表单是通过javascript构建的，而我的数据更新都是通过ajax POST和PUT完成的，那么是否真的有理由将我的控件包装在表单标签中？如果出于语义或结构上的原因，我仍要使用该标签，那么是否有任何理由要忽略我要忽略的操作和方法参数？感觉就像是对更早时代的保留。

通过将输入包装在表单标签内，至少提供了一项重要的用户体验功能：

回车键将提交表格。 实际上，在Mobile Safari中，这是使“开始”按钮显示在键盘上的方式。

如果没有包装输入的表格，则无法提交任何内容。

您当然可以通过按键事件提供回车键行为，但是我不知道这是否适用于移动设备。我不了解您，但是我宁愿使用浏览器提供的语义，也不必模仿事件。

对于您的情况，您只需为onsubmit表单提供一个事件处理程序，该事件处理程序将完成您的AJAX提交，然后return false取消实际的提交。

您可以简单地提供action=""（表示“自我”），而method不是必须提供-默认为GET。

如果您不需要逐步增强，那么从理论上讲您就不需要它们。

另一方面，forms具有很酷的分组和语义效果。使用它们，您可以按逻辑对表单元素进行分组，并使脚本更容易收集某些元素的值。

例如，如果您要ajax提交一些用户输入，说“让我们接受此表单中的所有元素并提交它们”总是比说“让我们接受此输入，这两个选择以及这三个文本区域并提交它们”要容易得多。 ”。以我的经验，如果form存在标签，它实际上可以帮助开发人员。

AJAX很棒，但正如JamWaffles（对他而言为+1）所说，使用form标签提供了一种后备方法。

就我个人而言，我使用表单标签，即使我使用AJAX提交的内容也是如此，因为它在语法上很清晰，并且可以轻松地获取特定表单中的所有输入。是的，您也可以使用adiv或其他方式执行此操作，但是正如我所说，使用格式在语法上是不错的。

顺便说一句，屏幕阅读器对内部内容的处理方式form有所不同，因此无论您选择哪种方式都存在可访问性问题。请注意，轶事证据表明Google在其排名中考虑了可访问性，因此，如果您对SEO感到担忧，请使用表格并正确进行。

摘要：适用于MVC，简单的Web应用程序，对面向组件的富Web应用程序不利的形式。

原因：窗体不能嵌套其他窗体：面向组件的体系结构的很大限制。

详细信息：对于典型的MVC应用程序，表格非常有用。在使用许多javascript和AJAX以及到处有很多组件的丰富，复杂的Web应用程序中，我不喜欢表单。原因：表单不能嵌套其他表单。然后，如果每个组件都呈现一个表单，则组件不能相互嵌套。太糟糕了。通过将所有形式更改为div，我可以嵌套它们，并且每当我想要获取所有参数以将它们传递给ajax时，我就可以这样做（使用jQuery）：

$（“＃id_of_my_div”）。find（“ [name]”）。serialize（）;

（或其他一些过滤条件）

代替：

$（“＃id_of_my_form”）。serialize（）;

但是，出于情感和语义的原因，当div用作表单时，我会不断为其命名。

我看不到。目前，我正在构建一个使用<form>s的Web应用程序，但是我正在使用它们，因此如果用户禁用了JavaScript（e.preventDefault正常停止表单发布），则可以使用备用方法。对于您所处的情况，您说的是用户必须具有JavaScript，<form>标记不是必需的，但如果浏览器需要对其进行任何操作或以某种方式访问​​它，则可能还是要保留该标记。类。

简而言之，不，<form>如果您正在执行纯AJAX，则无需使用，尽管如果您以后突然决定创建后备代码，则可能会有所保留。

我认为：如果出于语义原因使用它，请按预期使用它。动作属性是必需的（也可以保留为空），以使其格式正确，也可以通过设置动作属性并在ajax调用之前读取它，来将URI与js逻辑分开。

我不明白为什么您需要在这里使用form标签。使用表单标签的唯一原因（除了让您的标记通过验证）是，如果您要让用户使用sumbit输入或按钮标签“提交”数据。如果您不需要这样做，则不需要表格。但是，不确定是否将其视为“有效”标记。如果您确实使用它，则可以执行操作，<form action="">因为操作是form标记的唯一必需属性。但是，您确实提出了一个很好的建议，Web应用程序的未来可能不再需要表单和传统的提交方法。非常有趣，让我开心。呵呵 ：）