为何innerHTML属于Element类而非HTMLElement？Document属性归属疑问

Great question—this is one of those DOM API quirks that comes from a mix of historical legacy, early browser implementations, and evolving spec decisions. Let’s unpack each part clearly:

1. innerHTML belongs to Element.prototype, not HTMLElement #

At first glance, innerHTML feels like it should be HTML-specific, but there are two key reasons it lives on the generic Element interface:

• Early browser precedence: Microsoft’s IE was the first to introduce innerHTML, and it implemented it as a property of Element back in the early 2000s. When other browsers followed suit to match IE’s behavior (critical for compatibility with existing websites), this pattern stuck.
• Expanded spec support: Over time, the DOM specs evolved to allow innerHTML on non-HTML elements too. For example, you can use innerHTML to modify content inside SVG <foreignObject> elements (which contain HTML), or even in XML documents where elements have text/child elements. Putting it on Element makes this cross-document functionality consistent.
• Inheritance efficiency: Since HTMLElement inherits directly from Element, all HTML elements automatically get access to innerHTML without needing to redefine the property on the subclass. That’s why your check Object.getOwnPropertyNames(HTMLElement.prototype).includes('innerHTML') returns false—the property is inherited, not defined directly on the subclass.

2. body and head live on Document.prototype, not HTMLDocument #

This is another case where legacy compatibility won out over strict "HTML-only" categorization:

• Early DOM simplicity: When the DOM was first designed, browsers were almost exclusively handling HTML documents. The Document interface was the main entry point, and body/head were added directly to it because everyone assumed documents would have these elements. The HTMLDocument subclass came later as specs expanded to support XML/SVG.
• Backward compatibility guard: Moving body/head to HTMLDocument would break millions of existing websites that used document.body or document.head without checking the document type. Instead, the specs adjusted to define that for non-HTML documents (like pure XML or SVG), these properties return null.
• Simpler developer experience: Having these properties on Document lets you write code like document.body.style.color = 'red' without first checking if you’re dealing with an HTMLDocument instance. If it’s an HTML document, you get the element; if not, you get null—a cleaner pattern than conditional type checks.

To Sum Up #

These property placements are mostly compatibility compromises from the early days of the web, when the DOM was less standardized and browser vendors prioritized matching existing behavior over strict theoretical correctness. Over time, the specs have retroactively justified these choices by expanding support (for innerHTML) or defining clear fallback behaviors (for body/head on non-HTML documents).

内容的提问来源于stack exchange，提问作者KJJ