不处理文档和元素原型的一般原因
是否存在不处理文档和元素原型的一般原因？
我喜欢创建自己的小框架，因为我当前的项目不需要现有框架的大量功能。
我不需要支持不支持元素/文档构造函数的浏览器，也不会执行不受我控制的脚本。
那么您会建议扩展原型还是应该采用通常的方式并从元素/文档创建自己的对象？
Are there general reasons not to deal with Document's and Element's prototype?
I like to create my own little framework, because my current project doesn't need the mass of features of the existing frameworks.
I don't need to support browsers which don't support Element/Document-constructor and also will not execute scripts that are not under my control.
So would you recommend to extend the prototype or should I go the usual way and create own objects from Element/Document?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您计划扩展默认 DOM 元素吗？如果是这样，请不要。 Juriy Zaytsev（又名 Kangax）在扩展有什么问题中清楚地描述了为什么不这样做DOM。
Do you plan to extend default DOM elements? If so, please don't. Juriy Zaytsev (aka Kangax) clearly describes why not in What’s wrong with extending the DOM.
是的，不幸的是。如果能够通过修改 DOM 原型来添加功能，那就太好了，但在实践中，鉴于当今的技术，它并不可靠。
Document、Element等可能是浏览器实现的“宿主对象”，无法修改其原型。宿主对象可能具有许多其他本机 JavaScript 对象不会的奇怪行为。 DOM 节点是 IE6-7 和许多旧版、小众浏览器和移动浏览器中的宿主对象。即使它们被实现为原生 JavaScript 对象，（目前）还没有标准来描述在哪里可以找到它们的构造函数，以便您在
.prototype中查找。Document、Element等只是 W3 DOM 接口名称，它们没有说明要查找的实现对象。现代浏览器（IE8 本机模式和最新版本的 Firefox、Opera 和 WebKit）确实提供了构造函数，因此您可以开始向
Document或HTMLElement添加方法。但即便如此，公开的对象之间仍然存在差异，因为并非每个浏览器都提供具有相同名称的实现的 DOM 接口。 （NodeList的子接口/实现特别麻烦。）通过查看 Prototype.js 框架，您可以了解 DOM 原型在实践中是如何工作的。当它工作时，它非常流畅。但是因为你不能在任何地方都进行原型设计，所以最终会得到一些极其丑陋的东西，框架必须通过将方法复制到 Node 的每个实例中来处理原型设计无法工作的地方。然后你会遇到这样的情况：你的代码可能会忘记它需要强制这种“增强”，因此它可能会起作用或不起作用，具体取决于之前是否有其他函数碰巧增强了同一个节点。这会导致非常可怕的特定于浏览器、特定于交互顺序、容易出现竞争条件的调试痛苦。
如果您可以将原型设计工作限制在一些支持良好的界面上，并放弃除最新浏览器之外的所有浏览器，那么您可能可以摆脱它。
Yes, unfortunately. It would be lovely to be able to add functionality by fiddling the DOM prototypes, but in practice it's just not reliable given today's technology.
Document,Elementand others etc may be ‘host objects’ implemented by the browser with no ability to fiddle with their prototypes. Host objects may potentially have many other weird behaviours that a native JavaScript object wouldn't. DOM Nodes are host objects in IE6-7 and many older, niche and mobile browsers.Even if they are implemented as native-JavaScript objects, there is no standard (yet) that described where the constructor-function for them is to be found, for you to go fishing about in the
.prototype.Document,Elementand so on are just W3 DOM interface names, they say nothing about what the implementation objects are to be found.It happens that modern browsers (IE8 native mode and recent versions of Firefox, Opera and WebKit) do make constructor-functions available so you can start adding methods to
DocumentorHTMLElement. But even then, there are differences between what objects are exposed, as not every browser provides the DOM interfaces with implementations under the same names. (The subinterfaces/implementations ofNodeListare particularly troublesome.)You can see how DOM prototyping has worked in practice by looking at the Prototype.js framework. When it works, it's super smooth. But because you can't prototype everywhere, you end up with some extremely ugly stuff where the framework has to deal with places prototyping won't work by copying methods into every instance of a Node. And then you've got the situation where your code might forget it needs to force this ‘augmentation’ and so it might work or not work depending on whether some other function happened to augment the same node before. This leads to really horrible browser-specific, interaction-order-specific, race-condition-prone debugging pain.
If you can limit your prototyping work to a few well-supported interfaces, and give up on all but the latest browsers, you can probably get away with it.