Confirmed, however this behaviour has existed at least as far back as 1.2.6...

1.2.6 http://jsfiddle.net/rwaldron/TnyPu/2/

1.3.2 http://jsfiddle.net/rwaldron/TnyPu/3/

1.4.3 http://jsfiddle.net/rwaldron/TnyPu/4/

1.4.4 http://jsfiddle.net/rwaldron/TnyPu/5/

1.5.0 http://jsfiddle.net/rwaldron/TnyPu/7/

Changing it now will create a regression.

You say tomatoe, I say tohmahtoe.

You say regression of expected behavior, I say long-standing bug. :)

First draft of perf test: http://jsperf.com/jquery-text

Also it looks like innerText doesn't give text results for hidden elements or script nodes, while textContent does.. which means .textContent aligns with past behavior... fwiw

a. As already noted, changing this would be a major bc-breaker. And an unneeded one too

b. I don't think this is a bug .text() behaves like the specification for textContent (maybe it doesn't in XML context for processing instructions)

c. Improving the Sizzle.getText function with textContent should be evaluated, but tests are needed to verify the correct text content is returned

d. http://jsperf.com/jquery-text/2 gives a better look at the possible perf improvements (the first version was also doing the whole selection step at each iteration)

e. Who uses inline script tags anyway ;)

A little test case to toy with. Shows some bugs in the textFast() as well as the current text() (#6827) method.

Just for reference... the draft innerText spec: http://aryeh.name/gitweb.cgi?p=innertext;a=blob_plain;f=innertext.html;hb=HEAD

Cross-ref #3144 which has another getText implementation that uses textContent and resolves some issues with IE's nom-nominization of whitespace.

@dmethvin what were your thoughts on Jitter's comments about this being an unnecessary bc-breaker? Do we still want to pursue a solution for this?

so, i just got bitten by this and assumed it was a straight up error since IE was the only browser doing 'the wrong thing' but after reading the spec for innerText which specifically talks only about returning display != visible... i think that basically this could be resolved via documentation

.text() Get the combined text contents of each ''visible'' element in the set of matched elements, including their descendants.

rock on

imo, this should also just be something we document. Leaving open for a second opinion.

With 1.7 we tried using .innerText and we got #11153 for our troubles. So I think we'll stay with the nom-nominization we currently have, which (on the bright side) does use .textContent. At least it's a very consistent bug over time.