一般理由不处理Document和Element的原型

Question

是否有一般理由不处理Document和Element的原型？

我喜欢创建自己的小框架，因为我当前的项目不需要现有框架的大量功能。

我不需要支持不支持Element / Document构造函数的浏览器，也不需要执行不受我控制的脚本。

那么你会建议扩展原型还是我应该按常规方式从Element / Document创建自己的对象？

Answer 1

您是否计划扩展默认DOM元素？ 如果是这样，请不要。 Juriy Zaytsev（又名Kangax）清楚地描述了为什么不扩展DOM有什么问题 。

Answer 2

是的，很不幸的。 能够通过摆弄DOM原型来添加功能将是可爱的，但在实践中，鉴于当今的技术，它是不可靠的。

Document ， Element和其他等可能是浏览器实现的“主机对象”，无法摆弄其原型。 主机对象可能具有本机JavaScript对象不会具有的许多其他奇怪行为。 DOM节点是IE6-7中的主机对象以及许多旧的，利基和移动浏览器。

即使它们被实现为本机JavaScript对象，也没有标准（尚未）描述了它们的构造函数的位置，您可以在.prototype中进行.prototype 。 Document ， Element等只是W3 DOM接口名称，它们没有说明要找到的实现对象。

现在的浏览器（IE8本机模式以及Firefox，Opera和WebKit的最新版本）确实可以使构造函数可用，因此您可以开始向Document或HTMLElement添加方法。 但即使这样，在暴露的对象之间也存在差异，因为并非每个浏览器都提供具有相同名称的DOM接口。 （ NodeList的子接口/实现特别麻烦。）

通过查看Prototype.js框架，您可以看到DOM原型在实践中如何发挥作用。 当它工作时，它是非常流畅的。 但是因为你无法在任何地方制作原型，你最终得到了一些非常丑陋的东西，框架必须处理原型，通过将方法复制到Node的每个实例中都不会起作用。 然后你就遇到了你的代码可能会忘记需要强制执行这种“扩充”的情况，因此它可能会起作用或者不起作用，具体取决于是否有其他功能发生在以前增强同一节点。 这导致了非常糟糕的特定于浏览器，特定于交互顺序，易受竞争条件影响的调试痛苦。

如果您可以将原型设计工作限制在几个受到良好支持的界面上，并且放弃除最新浏览器以外的所有界面，那么您可以放弃它。