Skip to main content

Bug Tracker

Side navigation

#8111 closed bug (wontfix)

Opened February 01, 2011 01:27AM UTC

Closed May 29, 2012 09:55PM UTC

text() reports contents of inline script tags

Reported by: Owned by:
Priority: low Milestone:
Component: manipulation Version: 1.5
Keywords: Cc: dmethvin
Blocked by: Blocking:

test case:

also, using elem.textContent along with elem.innerText should be extremely performant and align more with users expectations.

Attachments (0)
Change History (11)

Changed February 01, 2011 04:07PM UTC by rwaldron comment:1

_comment0: Confirmed, however this behaviour has existed at least as far back as 1.2.6... \ \ 1.2.6 [[BR]] \ 1.3.2 [[BR]] \ 1.4.3 [[BR]] \ 1.4.4 [[BR]] \ 1.5.0 [[BR]] \ \ I'm concerned that changing it now will create a regression.1296576475686101
component: unfiledmanipulation
keywords: → needsreview
priority: undecidedlow
status: newopen

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






Changing it now will create a regression.

Changed February 01, 2011 05:32PM UTC by comment:2

You say tomatoe, I say tohmahtoe.

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

Changed February 01, 2011 05:50PM UTC by comment:3

First draft of perf test:

Changed February 01, 2011 05:58PM UTC by comment:4

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

Changed February 02, 2011 02:17AM UTC by jitter comment:5

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

Changed March 29, 2011 06:04AM UTC by comment:6

Changed July 12, 2011 09:31PM UTC by dmethvin comment:7

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

Changed January 24, 2012 11:24AM UTC by addyosmani comment:8

cc: → dmethvin

@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?

Changed February 16, 2012 09:44PM UTC by nsfmc comment:9

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

Changed May 29, 2012 08:49AM UTC by addyosmani comment:10

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

Changed May 29, 2012 09:55PM UTC by dmethvin comment:11

keywords: needsreview
resolution: → wontfix
status: openclosed

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.