Adding .closest() to more nodes

[caub]

Text nodes have no .closest method, when working with Range, I find useful to do Text.prototype.closest = function(s) {return this.parentNode.closest(s); } //with this.parentNode&& if we want to be strict

For me it makes sense to be able to search from a textnode, .matches wouldn't make sense (edit: it could, by returning null), but .closest would

[annevk]

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

[domenic]

Maybe @coonsta?

[hzr]

Sounds reasonable to me too.

[annevk]

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

[caub]

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;
};

[dominiccooney]

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.)

[annevk]

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].

[hayatoito]

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

[dominiccooney]

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?

[annevk]

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.