We're not creating those text nodes, the browser that is converting the text to HTML does that. Since we've been passing through text nodes created like that since jQuery 1.0 I don't think we'd want to change it.

$('<p id="test">test</p>' + "\\n" + '<p id="text">text</p>').closest('#text')

That doesn't make sense to do, so if it results in an error I am okay with it. Element selection won't return text nodes, only creating HTML from text. If you need to ensure that the top-level result of an HTML conversion only contains element nodes, you can use $(html).filter("*"). That is essentially what I think you're advocating anyway, so you'll only need to pay the performance price when you really need it. http://jsfiddle.net/dmethvin/VwFUk/

What is the situation where you're encountering this?

The closest() selector does work in 1.7.2 and breaks in 1.8.1 because it selects the text node instead of the element with the id of the selection.

What I'm wondering is if there is reasonable code that might do this. That's why I asked about the situation where you're using this. Are you really creating HTML via $() and then using .closest() in your real code?

I am. I'm using jsRender to render the template into a jQuery object and then looking up the closest element to do further modifications before injecting all of it into the dom. jsRender templates come back formatted which creates multiple text nodes in between elements because of line breaks.

I'll take a look. It's strange that nodeType 11 is compared when we wouldn't expect anything but 1.

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

Update Sizzle: Fixes #12303, #12474, #12523, #12526, #12541.

Changeset: f7980d4d68e76147e6a9ddd7b30d379ddce7f222