如何利用HTML自定义元素简化表单验证逻辑-html教程-PHP中文网

原生表单验证在自定义元素中失效，是因为未正确接入constraint validation api；需设置static formassociated = true、调用this.attachinternals()，并在setvalidity()中传入可聚焦的内部dom节点作为第三个参数以激活验证流程。

如何利用html自定义元素简化表单验证逻辑

为什么原生表单验证在自定义元素里直接失效

当你把 input 封装进自定义元素（比如 <my-input></my-input>），浏览器默认不把它当“表单控件”——checkValidity() 返回 true，reportValidity() 不弹提示，提交时也完全跳过它。根本原因是：它没接入 Constraint Validation API。常见报错 “An invalid form control with name='xxx' is not focusable” 就是这个信号。

关键不是“写了个 custom element”，而是它得被浏览器识别为可参与验证的表单关联元素（FACE）。只加 static formAssociated = true 和 this.attachInternals() 还不够，漏掉 validity anchor 就会卡死整个流程。

必须在 setValidity() 调用时传入第三个参数：一个可聚焦的内部 DOM 元素（如 this.input）
internals.setValidity({ valueMissing: true }, '字段不能为空', this.input) —— 第三个参数不能省
这个内部元素要能接收焦点（tabindex="-1" 或本身是 input/textarea）

怎么让 `reportValidity()` 正常弹出并滚动到错误位置

很多 FACE 实现调了 reportValidity() 却没反应，或者 Firefox 下不自动滚动，问题往往出在 validity anchor 绑定失败或未触发 invalid 事件。

html-to-pptx-converter

使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

下载

确保每次调用 internals.setValidity() 时，第三个参数（anchor）是当前实例中真实存在的、可聚焦的节点
不要在 disconnectedCallback 里还调 setValidity()，否则 anchor 可能已移除，导致静默失败
如果用了 shadow DOM，anchor 必须在 light DOM 或显式 exportparts 暴露，否则浏览器找不到聚焦目标
测试时用 form.reportValidity() 触发全表单校验，比单独调某个元素的 reportValidity() 更可靠

`setCustomValidity()` 在 FACE 里怎么用才不翻车

原生 input 上用 setCustomValidity() 是直接挂载在元素上，但 FACE 必须通过 internals.setValidity() + 自定义 message 配合实现等效效果，且不能混用。

别在 FACE 内部再调 this.input.setCustomValidity() —— 它和 internals 的状态不同步，会导致验证逻辑混乱
自定义错误文案要写进 setValidity() 的第二个参数：internals.setValidity({ customError: true }, '用户名已被占用')
清空错误必须显式调用：internals.setValidity({}) 或 internals.setValidity({}, '')，不能只设空字符串
若需响应用户输入实时清空旧错误，要在 input 或 blur 事件里先 setValidity({})，再跑新校验逻辑

如何避免验证状态残留导致“输对了还报错”

这是 FACE 表单中最隐蔽的坑：用户修改后明明符合规则，但 reportValidity() 仍弹旧提示。本质是 validity 状态没及时重置，尤其在异步校验（如用户名查重）场景下更明显。

每次开始新校验前，先调 internals.setValidity({}) 清空所有 validity flags
异步校验（如 fetch）返回后，检查元素是否还在 DOM 中（this.isConnected），避免回调执行时组件已销毁
不要依赖 invalid 事件来清理状态 —— 它只在浏览器判定无效时触发，而你可能手动设了 customError，它不会自动触发
调试时可用 console.log(this.internals().validity) 直接看当前 validity 对象，比猜更准

FACE 的验证逻辑看似封装了一层，实则把约束验证的每个环节都暴露给了你。锚点缺失、状态未清、同步/异步混用——这些细节一旦漏掉，验证就变成“看起来能跑，实际总掉链子”。最稳的做法是：每一步 validity 操作都对应一个明确的 DOM anchor，每一次校验都以 setValidity({}) 开头，而不是靠“应该没问题”去赌。