Element.innerText returns blank string when element has visibility: hidden set by CSS Stylesheet
Reported by gtg1...@gmail.com, Sep 16 2011
Chrome Version : 13.0.782.220 OS Version: 5.1 (Windows XP) URLs (if applicable) : Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 5: Firefox 4.x: IE 7/8/9: What steps will reproduce the problem? 1. http://jsfiddle.net/XBdQq/ 2. Access an element's innerText when it has visibility: hidden set by a CSS stylesheet 3. it will be "" rather than its actual content What is the expected result? http://jsfiddle.net/BUeZj/1/ Element.textContent works fine This leads to several bugs in some frameworks also. What happens instead? Please provide any additional information below. Attach a screenshot if possible. UserAgentString: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
Sep 16 2011,
The second JS fiddle shows correct behavior when visibility: visible; http://jsfiddle.net/XBdQq/1/ shows using visibility: hidden along with textContent and how that functions as expected.
Sep 30 2011,
I've tried to print the innerText/textContent of a visibility:hidden div, here is the result. OK means can get the string, empty means only get empty string. Safari 5: innerText: empty; textContent: OK. Firefox 7: innerText: not support; textContent: OK. IE 7/8: innerText: OK. textContent: not support. IE 9: innerText: OK. textContent: OK. opera 11: innerText: OK. textContent: OK.
Mar 10 2013,
Apr 15 2015,
This appears to be expected behaviour. Matches firefox. Please use textContent instead.
Apr 15 2015,
How could it match Firefox if Firefox doesn't support `innerText` in the first place? :) IE and WebKit/Blink are the ones diverging on "visibility: hidden" behavior — http://perfectionkills.com/the-poor-misunderstood-innerText/#diff-with-textContent Considering that WebKit/Blink don't include "opacity: 0" elements, this is somehwat of a consistency issue. IE, on the other hand, only excludes "display: none" — which makes sense, since those are not part of the flow (unlike "visibility: hidden", "opacity: 0", "text-indent: -9999px", "color: transparent", and myriad of other ways one could come up with) So I'd argue that WebKit/Blink behavior is the odd one. Whether that could be "fixed" is a different matter; there might be sites relying on this. And technically there's nothing to "fix" in the first place, since `innerText` has never been standardized. Still, if this doesn't break anything, I think WebKit/Blink should follow IE lead in this particular aspect of problematic beast that innerText is :)
Sign in to add a comment