【发布时间】:2015-01-27 09:17:23
【问题描述】:
有据可查(主要是在 SO 上)在 <input type="text"> 上使用 Node.cloneNode(true) 会返回一个新的 <input> 节点,其文本内容与原始节点相同,但克隆了一个 <select>(在用户拥有selected) 返回一个新的<select>,而不需要用户选择。起初这似乎不符合规范,因为根据DOM 3:
cloneNode
返回此节点的副本,即用作节点的通用复制构造函数。重复节点没有父节点(parentNode 为空)并且没有用户数据。 与导入节点关联的用户数据不会被转移。
为什么会发生这种情况的答案稍后会有所说明,但在DOM 2 spec中更清楚,
cloneNode
克隆元素会复制所有属性及其值,包括由 XML 处理器生成以表示默认属性的属性,但此方法不会复制它包含的任何文本,除非它是深度克隆,因为文本包含在子项中文本节点。
考虑到这种措辞,我愿意接受这种行为,尽管我认为<input> 不包含文本节点,因为<input> 的childNodes 属性将始终为空@ 987654334@,不管它是否包含文本(在规范的措辞中,“有一个文本节点”)。
至少,我知道用户选择的<option> 被视为用户数据,因此不克隆是有道理的。在这种情况下,这个“用户数据”包含在<option> 的selected 属性中。
但是,当trying the behavior with radio buttons and checkboxes 时,Chrome 38、FF 33、Safari 6.2 中的行为完全违背了上述定义。克隆选中的复选框或选定的单选按钮会保持它们的选中状态。这似乎与规范相反,因为此信息是“用户数据”,它(如 <select>)包含在属性中(在本例中为 checked)。
我是否正确,这不符合规范?如果没有,是否在其他地方定义了这种行为?如果是的话,是否有一个用例可以解释为什么cloneNode() 在克隆用户输入字段的状态方面如此不一致?
编辑:在针对我的浏览器套件进行测试时,我发现 Opera 12.15 的性能与 <select> 输入一样。也就是说,它保留了克隆时的用户选择。
【问题讨论】:
标签: javascript html dom clone