Opened 12 years ago
Closed 11 years ago
#8111 closed bug (wontfix)
text() reports contents of inline script tags
Reported by: | paul.irish | Owned by: | |
---|---|---|---|
Priority: | low | Milestone: | 1.next |
Component: | manipulation | Version: | 1.5 |
Keywords: | Cc: | dmethvin | |
Blocked by: | Blocking: |
Description
test case: http://jsfiddle.net/deadlyicon/TnyPu/
also, using elem.textContent
along with elem.innerText
should be extremely performant and align more with users expectations.
Change History (11)
comment:1 Changed 12 years ago by
Component: | unfiled → manipulation |
---|---|
Keywords: | needsreview added |
Priority: | undecided → low |
Status: | new → open |
comment:2 Changed 12 years ago by
You say tomatoe, I say tohmahtoe.
You say regression of expected behavior, I say long-standing bug. :)
comment:4 Changed 12 years ago by
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
comment:5 Changed 12 years ago by
- As already noted, changing this would be a major bc-breaker. And an unneeded one too
- 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) - Improving the
Sizzle.getText
function withtextContent
should be evaluated, but tests are needed to verify the correct text content is returned - 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)
- 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.
comment:6 Changed 12 years ago by
Just for reference... the draft innerText spec: http://aryeh.name/gitweb.cgi?p=innertext;a=blob_plain;f=innertext.html;hb=HEAD
comment:7 Changed 12 years ago by
Cross-ref #3144 which has another getText implementation that uses textContent and resolves some issues with IE's nom-nominization of whitespace.
comment:8 Changed 11 years ago by
Cc: | dmethvin added |
---|
@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?
comment:9 Changed 11 years ago by
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
comment:10 Changed 11 years ago by
imo, this should also just be something we document. Leaving open for a second opinion.
comment:11 Changed 11 years ago by
Keywords: | needsreview removed |
---|---|
Resolution: | → wontfix |
Status: | open → closed |
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.
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.