This sounds reasonable. @hzr, @domenic? (Anyone else from Google that would be better to ask for DOM questions?)

Maybe @coonsta?

Sounds reasonable to me too.

If I were to fix this I'd probably include all possible children of Element by the way, not just Text.

ok, tend also to do the one below (since I'm using .closest on all sort of nodes that comes with range.commonAncestorContainer)

Document.prototype.closest = function() { 
    return null;
};

All possible children of Element + Document—does it make sense to put this on Node? I suppose Document, DocumentFragment, and ShadowRoot .closest return null? (/cc @hayatoito for ShadowRoot.)

So, it does not make much sense for Document, DocumentType, DocumentFragment, ShadowRoot, and Attr, if it comes back as a node, but it seems there's at least a use case for Document. And if Document makes sense, even if it only ever returns null, so does ShadowRoot.

If we put it on node we should probably use [Unscopable].

Yeah, regarding ShadowRoot, it returns null because it is not an element and it is always the root.

I think if you include Document and ShadowRoot you may as well include DocumentFragment? I agree leaving this off Attr makes sense. Are there any other properties like this, can the principle of consistency guide the decision?

I think there are many properties like this, but for historical reasons they have ended up on Attr too. And for historical reasons DocumentType is a thing as well.

I guess we have two options here:

1. Just use Node.
2. Define a new TreeNode mixin that excludes Attr. (It seems we include DocumentType for other new mixins, such as ChildNode.)

I'm inclined to go with 2 if we still want to do this.