> foo is a member of a [...] foo is a member of the prototype for class A [...] they need to know is the function on the prototype or on the object itself and d

> foo is a member of a [...] foo is a member of the prototype for class A [...] they need to know is the function on the prototype or on the object itself and documenting as Class.prototype.func tells them that I know how prototypes work, and I know why the `Array.prototype.slice` are documented that way, because I wrote those docs—and caught a bunch of flak along the way when making the move away from referring those and other methods in the form `Array.slice`—in 2007. It's hard to address the issue using your specific example, because it's so contrived. (Who is replacing native implementations [don't], and why? [Once again: don't.]) Here's the actual motivating factor for why you see stuff like `Array.prototype.slice` documented that way: There are methods `fromCharCode` and `charCodeAt`. However, you call the former as `String.fromCharCode` and the latter as `x.charCodeAt`, where `x` is some string instance. That's an important distinction, which means it's important that we not refer to them as `String.fromCharCode` and `String.charCodeAt`. The former is a real method that actually existed, and the latter is something that doesn't exist Which means if we tell readers "Use `String.charCodeAt`", then what we're doing is giving readers bad, confusing, and possibly frustrating information—not what you want when your goal is to be explaining things to an already unsure or simply ignorant audience. This distinction only became more important with ES5, since it started adding things like `Object.keys` and `Object.defineOwnProperty`, rather than making those methods available to all instances by adding them to the prototype. But this is all besides the point, because we're talking about the DOM here. > I'm not understanding the distinction from a JS programmer's perspective That's the problem. Because what we're discussing is a reference for people using the DOM, and once again your changes would force a bunch of JS-isms into the scope of the documentation, and not only that, but a bunch of shaky, not-at-all-well-understood-or-agreed-upon, cobweb-covered parts of how the underlying objects get projected into JS. > In other words, a JS programmer does not care about implementation details. You understand that the thing you're asking for are that implementation details surface through the docs, right? And that they should be a prominent feature? That's what you're asking for.