它可以是你有隐藏(display: none)字段和必需的属性。

请检查所有必填字段是否对用户可见:)

确保表单中具有所需属性的所有控件也具有name属性集

有些事情仍然让我感到惊讶……我有一个具有两个不同实体的动态行为的表单。一个实体需要一些其他实体不需要的字段。 所以，我的JS代码，取决于实体，做一些类似的事情: $ (' # periodo ') .removeAttr(“需要”); $ (" # periodo-container ") hide ();

当用户选择另一个实体时: $ (" # periodo-container "),告诉(); $ (" # periodo”)。道具(“需要”,真正的);

但有时，当提交表单时，会出现问题:“name=periodo的无效表单控件”不可聚焦(我对id和名称使用相同的值)。

要解决这个问题，您必须确保您正在设置或删除'required'的输入始终可见。

所以，我所做的是:

$("#periodo-container").show(); //for making sure it is visible
$('#periodo').removeAttr('required'); 
$("#periodo-container").hide(); //then hide

这解决了我的问题…难以置信。

奇怪的是，每个人都建议删除验证，而验证的存在是有原因的…… 不管怎样，如果你在使用一个自定义控件，并且想要维护验证，你可以这样做:

第一步。从输入中删除无显示，因此输入变得可聚焦

.input[required], .textarea[required] {
    display: inline-block !important;
    height: 0 !important;
    padding: 0 !important;
    border: 0 !important;
    z-index: -1 !important;
    position: absolute !important;
}

第二步骤。如果样式不够，则在特定情况下的输入上添加无效事件处理程序

inputEl.addEventListener('invalid', function(e){
   //if it's valid, cancel the event
   if(e.target.value) {
       e.preventDefault();
   }
}); 

我来这里是为了回答，我自己触发了这个问题，基于没有关闭</form>标签，并且在同一页面上有多个表单。第一个表单将扩展到包括对来自其他地方的表单输入进行验证。因为这些表单是隐藏的，所以它们触发了错误。

例如:

<form method="POST" name='register' action="#handler">


<input type="email" name="email"/>
<input type="text" name="message" />
<input type="date" name="date" />

<form method="POST" name='register' action="#register">
<input type="text" name="userId" />
<input type="password" name="password" />
<input type="password" name="confirm" />

</form>

触发器

name='userId'的无效表单控件不可聚焦。 name='password'的无效表单控件不可聚焦。 name='confirm'的无效表单控件不可聚焦。

使用ElementInternals API的自定义元素元素不能使用delegatesFocus: true与shadowRoot，因为元素必须直接接收焦点(目前，这可能会发展)在公开的表单的DOM树(父表单可以在shadowRoot，它只是必须在同一部分的树与自定义和其他表单元素);元素必须是可见的，在我的实验中tabindex=0是必需的元素(-1似乎也工作)

一个从googlchrome扩展的带有自定义元素的演示在https://jimmont.github.io/samples/report-validity/

the error is simply reporting that an element which has attributes indicating it needs validation cannot receive focus when there's a problem with the validation, so the user can correct the error; if the error and information is coming in as expected you can ignore the error; otherwise it's likely the result of some UI features hiding elements and a mix of unexpected behavior; it's possible to use another approach in implementations to allow the user to walk back through a flow of some sort, but it appears that's beyond the scope of the question at the moment