浏览器引擎不解析元素，而是按字节→字符→token→节点流程构建dom树；等标签生成对应htmlformelement实例后，由dom绑定与事件系统赋予语义行为，如自动收集form.elements、响应submit事件、支持原生验证等。
浏览器引擎不“解析”
就结束该节点的子树构建。真正赋予它“表单行为”的，是后续的 DOM 绑定与事件系统。这个节点一旦生成，就会自动具备以下能力：
- 自动收集其内部所有可提交控件（
<input>、<select></select>、<textarea></textarea>、<button type="submit"></button>等）到form.elements集合中 - 响应
submit事件，并在默认行为中按method和enctype构造请求体 - 支持
checkValidity()和原生约束验证（required、type="email"等） - 与
<label for="xxx"></label>或嵌套关系联动，触发 focus/activation
form.elements 是怎么填充的？不是靠 class 或位置，而是靠“可提交性”定义
form.elements 不是简单地找所有子节点里的 <input>，它有一套明确的 W3C 规范判定逻辑。一个元素要被纳入 form.elements，必须同时满足：
- 是表单关联元素（
<input>、<button></button>、<select></select>、<textarea></textarea>、<object></object>、<output></output>） - 没有
disabled属性（disabled的控件不会提交，也不进集合） - 有
name属性（空字符串也算；无name的控件不参与提交，也不进elements） - 属于该
<form></form>—— 要么在它的 DOM 子树内，要么通过form="form-id"显式绑定
比如这段 HTML：
最终 document.getElementById('login').elements.length 是 3（user、空 name、token），不是 4 或 5。
为什么 autocomplete、novalidate 这些属性能立刻生效？
这些属性不是“解析时起作用”，而是在 DOM 属性变更时由引擎内部监听并同步更新对应状态位。例如：
-
novalidate属性存在 → 引擎将该HTMLFormElement的needsValidation标志设为false→ 提交时不调用checkValidity()→ 绕过所有原生校验提示 -
autocomplete="off"→ 渲染引擎禁用该表单下所有控件的 autofill 候选弹出层（注意：现代浏览器对"off"已弱化处理，更倾向尊重用户设置） -
target="_blank"→ 不影响解析，但会在 submit 时控制新窗口打开行为，由导航子系统接管
关键点：这些属性的 effect 是声明式的、即时的，不需要重新 parse HTML，也不依赖 JS 手动绑定。
容易被忽略的边界：form 的“隐式提交”和 button 类型陷阱
很多问题其实不出在“解析”，而出在开发者对默认行为的误判。最典型的是：
-
<button>提交</button>默认是type="submit"，只要在<form></form>内，点击就触发表单提交 —— 即使没写type属性 -
<input type="image">也会触发 submit，且会附带鼠标坐标x/y参数 - 按 Enter 键触发提交，只发生在“当前聚焦的可提交控件”在 form 内，且该 form 没有其他
type="submit"按钮时，才回退到第一个<input>上 -
<form></form>没有action时，默认提交到当前 URL；没有method时，默认为GET—— 这些都不是解析错误，而是规范定义的 fallback 行为
也就是说，表单“看起来没反应”，往往是因为 button 类型不对、缺少 name、或被 event.preventDefault() 拦截了 —— 而不是浏览器没解析到那个 <form></form> 标签。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
