The jsfiddle above contains some noise, it is not a complete reduction of the problem. See the following jsFiddles for smaller examples of the problem

Using jQuery (and Sizzle) http://jsfiddle.net/mendesjuan/4hV6c/8/

Just with Node.contains http://jsfiddle.net/4hV6c/10/

The problem is really in Sizzle.contains which uses Node.contains, but that is broken in IE when you pass in a text node

I think a better description of the problem is that

$.has

doesn't support passing in a text node

Here is a work around for my specific issue in IE, the conditions for the other ways to use .has() will have to be added. http://jsfiddle.net/8F57r/12/

Used jquery to handle the .parent() http://jsfiddle.net/8F57r/13/

I looked at this a little over the weekend, but couldn't find a solution that added less than 14 bytes gzipped (and really, the most performant added 16). Others are welcome to take a swing, but I feel like that's probably it.

https://github.com/gibson042/sizzle/commit/439b16792ef089a248059bed7fe89ce2247ca621

This feels a lot like #11540 to me. Text nodes are not generally valid inputs for jQuery collections and/or methods. If we start to make exceptions and say, "Oh but for this API and that one we'll allow it" then everyone will (somewhat rightly) expect that all our APIs fully support text nodes. That would be a lot of work/size for something that hasn't caused a lot of issues over 5 years.

This might be a minority opinion, but I feel like we ''should'' generally support text nodes (except where doing so is prohibitively heavy or slow, in which case those reasons deserve documentation).

#11538 is a duplicate of this ticket.

My opinion is that text nodes shouldn't be supported for just one API when we're not going to be implementing this for others (at least not without some significant weight being added). I'd vote for a wontfix.

I never meant for this to be a discussion about textNodes

http://jsfiddle.net/8F57r/13/

proves (in IE8) that the parent of a textNode (i.e.: an actual node) has a broken .has()

Replying to [comment:10 theprecognition@…]:

I never meant for this to be a discussion about textNodes http://jsfiddle.net/8F57r/13/ proves (in IE8) that the parent of a textNode (i.e.: an actual node) has a broken .has()

The parent has no relevance here, it's your text node argument to .has that ultimately gets passed to Node.contains via Sizzle.contains. I've updated your fiddle to demonstrate: http://jsfiddle.net/8F57r/14/. See?

ah. But semantically, can you seer where I'm coming from? this functionality feels like it should work across all browsers. =\\

Replying to [comment:9 addyosmani]:

My opinion is that text nodes shouldn't be supported for just one API when we're not going to be implementing this for others (at least not without some significant weight being added). I'd vote for a wontfix.

In this case the relevant code defers directly to Sizzle, which tends to be much less hostile towards non-elements (e.g., compare $("<p>A<br/>B</p>").contents().filter(":not(*)") to $("<p>A<br/>B</p>").contents(":not(*)") or $.filter( ":not(*)", $("<p>A<br/>B</p>").contents() )).

I can't envision us opening up Pandora's box and treating text nodes as first-class citizens in jQuery. Given that much of our semantics are based on CSS selectors which treat text nodes as a lower caste if not an outright untouchable, I don't think we're making up crazy rules here.

For .has() I can see how it might be expected to accept a text node as its parameter. I'll mark this open for now but don't want it to become a rallying cry for "you accepted text nodes there, so why not here" arguments. In that case it would be better to close this wontfix.

https://github.com/jquery/sizzle/pull/100

Allow document to be passed to Sizzle.contains. Fixes #11539.

Changeset: eecd8aef671d6a8720b4f66ee22b3d01ef1b951b