I know this "return something different depending on the collection" approach is a trademark of jQuery's early design, but I'm not a fan of continuing that tradition. Especially in this case where you can get the information via $("template").prop("content") which works all the way back to jQuery 1.6. If there was a strong argument for a getter/setter API it might make sense, but I don't think that applies for this case.

@dmethvin's comment is very sensible and hard to argue with, but I kinda want to argue with it anyway. This might be worth it. I'd like to see examples of return values.

@timmywil one example - with HTML:

<template>
	<div id="template-div0">
		<div id="template-div00"></div>
	</div>
	<div id="template-div1"></div>
	<div id="template-div2"></div>
</template>

if templateNode is a what its name suggests then running:

templateNode.content.childNodes

produces a NodeList with 7 nodes:

[text, div#template-div0, text, div#template-div1, text, div#template-div2, text]

Put together http://jsbin.com/mahudek/edit?html,js,output.

templateNode.childNodes
// => NodeList[0]

templateNode.content.childNodes
// => NodeList[7], with text elements

templateNode.content.children
// => HTMLCollection[3]

We discussed this one and given that the solution is short and we currently return an empty list, we can fix this. Something like,

...
jQuery.nodeName( elem, "template" ) && elem.content ?
    elem.content.childNodes
...

@TechQuery would you like to do the PR?

Note that we have to be careful to not make the contents stop being inert once running template.contents() so we'll need a test that ensures this does not happen. For example, you could create a <template> tag containing a script and <img> with an onload handler and making sure none of them fires.

@timmywil I'd like to make a new PR for this issue~

But one question: Which branch should I commit to ? 1.12-stable, 2.2-stable or master ?

@TechQuery master. We don't maintain versions 1.x & 2.x anymore.