The poor, misunderstood innerText — Perfection Kills
Few issues are as misunderstood and misused on the internet as innerText property.
That quirky, non-standard method of aspect’s textual content retrieval, [introduced by Internet Explorer](https://msdn.microsoft.com/en-us/library/ie/ms533899percent28v=vs.85percent29.aspx) and later “copied” by each WebKit/Blink and Opera for web-compatibility causes. It is normally seen together with textContent — as a cross-browser method of utilizing commonplace property adopted by a proprietary one:
Or as the primary webcompat offender in [numerous Mozilla tickets](https://bugzilla.mozilla.org/show_bug.cgi?id=264412#c24) — since Mozilla is among the solely main browsers refusing so as to add this non-standard property — when somebody would not know what they’re doing, skipping textContent “fallback” altogether:
innerText is just about at all times frown upon. In any case, why would you need to use a non-standard property that does the “similar” factor as a normal one? Only a few folks enterprise to truly verify the variations, and on the floor it actually seems as there’s none. These curious sufficient to research additional normally do discover them, however solely slight ones, and solely when retrieving textual content, not setting it.
Again in 2009, I did simply that. And I even wrote [this StackOverflow answer](http://stackoverflow.com/a/1359822/130652) on the precise variations — slight whitespace deviations, issues like inclusion of contents by textContent (however not innerText), variations in interface (Node vs. HTMLElement), and so forth.
All this time I used to be strongly satisfied that there is not a lot else to find out about textContent vs. innerText. Simply steer away from innerText, use this “combo” for cross-browser code, take into account slight variations, and also you’re golden.
Little did I do know that I used to be merely wanting on the tip of the iceberg and that my notion of innerText will change drastically. What you are about to listen to is the story of Web Explorer getting one thing proper, the true variations between these properties, and the way we most likely need to standardize this red-headed stepchild.
The true distinction
A short while in the past, I used to be serving to somebody with the implementation of textual content editor in a browser. That is once I realized simply how ridiculously necessary these seemingly insignificant whitespace deviations between textContent and innerText are.
This is a easy instance:
See the Pen gbEWvR by Juriy Zaytsev (@kangax) on CodePen.
Discover how innerText nearly exactly represents precisely how textual content seems on the web page. textContent, however, does one thing unusual — it ignores newlines created by and round styled-as-block parts ( on this case). Nevertheless it preserves areas as they’re outlined within the markup. What does it truly do?
Wanting on the [spec](http://www.w3.org/TR/2004/REC-DOM-Stage-3-Core-20040407/core.html#Node3-textContent), we get this:
This attribute returns the textual content content material of this node and its descendants. […]
On getting, no serialization is carried out, the returned string doesn’t comprise any markup. No whitespace normalization is carried out and the returned string doesn’t comprise the white areas in aspect content material (see the attribute Textual content.isElementContentWhitespace). […]
The string returned is manufactured from the textual content content material of this node relying on its kind, as outlined under:
For ELEMENT_NODE, ATTRIBUTE_NODE, ENTITY_NODE, ENTITY_REFERENCE_NODE, DOCUMENT_FRAGMENT_NODE:
concatenation of the textContent attribute worth of each little one node, excluding COMMENT_NODE and PROCESSING_INSTRUCTION_NODE nodes. That is the empty string if the node has no kids.
For TEXT_NODE, CDATA_SECTION_NODE, COMMENT_NODE, PROCESSING_INSTRUCTION_NODE
nodeValue
In different phrases, textContent returns concatenated textual content of all textual content nodes. Which is nearly like taking markup (i.e. innerHTML) and stripping it off of the tags. Discover that no whitespace normalization is carried out, the textual content and whitespace are primarily spit out the similar method they’re outlined within the markup. You probably have a large chunk of newlines in HTML supply, you will have them as a part of textContent as nicely.
Whereas investigating these points, I got here throughout a [fantastic blog post by Mike Wilcox](http://clubajax.org/plain-text-vs-innertext-vs-textcontent/) from 2010, and just about the one place the place somebody tries to carry consideration to this problem. In it, Mike takes a stab on the similar issues I am describing right here, saying these true-to-the-bone phrases:
Web Explorer applied innerText in model 4.0, and it’s a helpful, if misunderstood function. […]
The most typical utilization for these properties is whereas engaged on a wealthy textual content editor, when it’s worthwhile to “get the plain textual content” or for different useful causes. […]
As a result of “no whitespace normalization is carried out”, what textContent is basically doing is performing like a PRE aspect. The markup is stripped, however in any other case what we get is precisely what was within the HTML doc — together with tabs, areas, lack of areas, and line breaks. It’s getting the supply code from the HTML! What good that is, I actually don’t know.
Realizing these variations, we are able to see simply how doubtlessly deceptive (and harmful) a typical textContent || innerText retrieval is. It is just about like saying:
The case for innerText
Coming again to a textual content editor…
To illustrate now we have a [contenteditable](http://html5demos.com/contenteditable) space by which a consumer is writing one thing. And we might prefer to have our personal spelling correction of a textual content in that space. With a view to do this, we actually need to analyze textual content the best way it seems within the browser, not within the markup. We would prefer to know if there are newlines or areas typed by a consumer, and never these which might be within the markup, in order that we are able to right textual content accordingly.
This is only one use-case of plain textual content retrieval. Maybe you may need to convert written textual content to a different format (PDF, SVG, picture by way of canvas, and so forth.) by which case it has to look precisely because it was typed. Or perhaps it’s worthwhile to know the cursor place in a textual content (or its whole size), so it’s worthwhile to function on a textual content the best way it is offered.
I am certain there’s extra eventualities.
A great way to consider innerText is as if the textual content was chosen and copied off the web page. In reality, that is precisely what WebKit/Blink does — it [uses the same code](http://lists.w3.org/Archives/Public/public-html/2011Jul/0133.html) for Choice#toString serialization and innerText!
Talking of that — if innerText is basically the identical factor as stringified choice, should not it’s attainable to emulate it by way of Choice#toString?
It certain is, however as you may think about, the efficiency of such factor [leaves more to be desired](http://jsperf.com/innertext-vs-selection-tostring/4) — we have to save present choice, then change choice to comprise whole aspect contents, get string illustration, then restore unique choice:
The issues with this frankenstein of a workaround are efficiency, complexity, and readability. It should not be so laborious to get “plain textual content” illustration of a component. Particularly when there’s an already “applied” property that does simply that.
Web Explorer received this proper — textContent and Choice#toString are poor contenders in instances like this; innerText is precisely what we’d like. Besides that it is non-standard, and unsupported by one main browser. Fortunately, no less than Chrome (Blink) and Safari (WebKit) have been thoughtful sufficient to immitate it. One would hope there isn’t any deviations amongst their implementations. Or is there?
Variations with textContent
As soon as I noticed the importance of innerText, I wished to see the variations amongst 2 engines. Since there was nothing like this on the market, I set on a path to discover it. In true [“cross-browser maddness” traditions](http://unixpapa.com/js/key.html), what I’ve discovered was not for the faint of coronary heart.
I began with (now extinct) [test suite by Aryeh Gregor](https://internet.archive.org/internet/20110205234444/http://aryeh.identify/spec/innertext/take a look at/innerText.html) and [added few more things](http://kangax.github.io/jstests/innerText/) to it. I additionally searched WebKit/Blink bug trackers and included [whatever](https://code.google.com/p/chromium/points/element?id=96839) [relevant](https://bugs.webkit.org/show_bug.cgi?id=14805) [things](https://bugs.webkit.org/show_bug.cgi?id=17830) I discovered there.
The desk above (and within the take a look at suite) reveals all of the gory particulars, however few issues price mentioning. First, excellent news — Web Explorer and parts — after which when IE modified, they naturally drifted aside. At the moment, among the WebKit/Blink conduct is like old-IE and a few is not. However even evaluating to unique variations, WebKit did a poor job copying this function, or quite, it looks as if they’ve tried to make it higher!
Not like IE, WebKit/Blink insert tabs between desk cells — that type of is sensible! In addition they protect higher/lower-cased textual content, which is arguably higher. They do not embody hidden parts (“show:none”, “visibility:hidden”), which is sensible too. And so they do not embody contents of parts and / fallback — maybe a questionable facet — however cheap as nicely.
Okay, there’s extra excellent news.
Discover that IE Tech Preview (Spartan) is now a lot nearer to WebKit/Blink. There’s solely 9 elements they differ in (evaluating to 10-11 in earlier variations). That is nonetheless rather a lot however there’s no less than some hope for convergence. Most notably, IE once more stopped together with and <model> contents, and — for the primary time ever — stopped together with “show:none” parts (however not “visibility:hidden” ones — extra on that later).
Opera mess
You may need caught the dearth of Opera in a desk. It isn’t simply because Opera is now utilizing Blink engine (primarily having WebKit conduct). It is also as a consequence of the truth that when it wasn’t on Blink, it has been reaaaally naughty in relation to innerText. To maintain internet compatibility, Opera merely went forward and “aliased” innerText to textContent. That is proper, in Opera, innerText would return nothing near what we see in IE or WebKit. There’s merely no level together with in a desk; it will diverge in each single facet, and we are able to simply think about it as by no means applied.
Observe on efficiency
One other distinction lurks behind textContent and innerText — efficiency.
You could find dozens of [tests on jsperf.com comparing innerText and textContent](http://jsperf.com/search?q=innerText) — innerText is usually dozens time slower.
In [this blog post](http://www.kellegous.com/j/2013/02/27/innertext-vs-textcontent/), Kelly Norton is speaking about innerText being as much as 300x slower (though that looks as if a very uncommon case) and advises in opposition to utilizing it totally.
Realizing the underlying ideas of each properties, this should not come as a shock. In any case, innerText requires data of structure and [anything that touches layout is expensive](http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-webkit.html).
So for all intents and functions, innerText is considerably slower than textContent. And if all you want is to retrieve a textual content of a component with none type of model consciousness, you must — by all means — use textContent as an alternative. Nevertheless, this model consciousness of innerText is precisely what we’d like when retrieving textual content “as offered”; and that comes with a value.
What about jQuery?
You are most likely conversant in jQuery’s textual content() technique. However how precisely does it work and what does it use — textContent || innerText combo or one thing else? Seems, jQuery [takes a safe route](https://github.com/jquery/jquery/blob/7602dc708dc6d9d0ae9982aadb9fa4615a9c49fa/exterior/sizzle/dist/sizzle.js#L942-L971) — it both returns textContent (if out there), or manually does what textContent is meant to do — iterates over all kids and concatenates their nodeValue‘s. Apparently, at one level jQuery **did** use innerText, however then [ran into good old whitespace differences](http://bugs.jquery.com/ticket/11153) and determined to ditch it altogether.
So if we wished to make use of jQuery to get actual textual content illustration (à la innerText), we won’t use jQuery’s textual content() because it’s mainly a cross-browser textContent. We would want to roll our personal answer.
Standardization makes an attempt
Hopefully by now I’ve satisfied you that innerText is fairly rattling helpful; we went over the underlying idea, browser variations, efficiency implications and noticed how even an all-mighty jQuery is of no assist.
You’ll suppose that by now this property is standardized or no less than making its method into the usual.
Nicely, not so quick.
Again in 2010, Adam Barth (of Google), [proposes to spec innerText](http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Aug/0455.html) in a WHATWG mailing record. Humorous sufficient, all Adam needs is to set pure textual content (not markup!) of a component in a safe method. He additionally would not find out about textContent, which will surely be a most popular (commonplace) method of doing that. Thankfully, Mike Wilcox, whose weblog publish I discussed earlier, chimes in with:
Along with Adam’s feedback, there is no such thing as a commonplace, secure method of *getting* the textual content from a collection of nodes. textContent returns every little thing, together with tabs, white house, and even script content material. […] innerText is a kind of issues IE received proper, identical to innerHTML. Let’s please think about making that a normal as an alternative of eradicating it.
In the identical thread, Robert O’Callahan (of Mozilla) [doubts usefulness of innerText](http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Aug/0477.html) but additionally provides:
But when Mike Wilcox or others need to make the case that innerText is definitely a helpful and wanted function, we should always hear it. Or if somebody from Webkit or Opera needs to clarify why they added it, that might be helpful too.
Ian Hixie is open to including it to a spec if it is wanted for internet compatibility. Whereas Rob O’Callahan considers this a redundant function, Maciej Stachowiak (of WebKit/Apple) hits the nail on the top with [this fantastic reply](http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Aug/0480.html):
Is it a genuinely helpful function? Sure, the flexibility to get plaintext content material as rendered is a helpful function and annoying to implement from scratch. To offer one very marginal information level, it is utilized by our regression textual content framework to output the plaintext model of a web page, for assessments the place structure is irrelevant. A extra hypothetical use can be a wealthy textual content editor that has a “convert to plaintext” function. textContent isn’t as helpful for these use instances, because it would not deal with line breaks and unrendered whitespace correctly.
[…]These elements would are likely to weigh in opposition to eradicating it.
To which Rob provides an affordable reply:
There are many methods folks may need to do this. For instance, “convert to plaintext” options typically introduce characters for record bullets (e.g. ‘*’) and merchandise numbers. (E.g., Mac TextEdit does.) Safari 5 would not do
both. […] Satisfying greater than a small variety of potential customers with a single
attribute could also be troublesome.
And the dialog dies out.
Is innerText actually helpful?
As Rob factors out, “convert to plaintext” may actually be an ambiguous process. In reality, we are able to simply create a take a look at markup that appears nothing like its “plain textual content” model:
See the Pen emXMKZ by Juriy Zaytsev (@kangax) on CodePen.
Discover that “opacity: 0” parts usually are not displayed, but they’re a part of innerText. Ditto with notorious “text-indent: -999px” hiding method. The bullets from the record usually are not accounted for and neither is dynamically generated content material (by way of ::after pseudo selector). Paragraphs solely create 1 newline, although in actuality they may have gigantic margins.
However I believe that is OK.
When you consider innerText as textual content copied from the web page, most of those “artifacts” make good sense. Simply because a bit of textual content is given “opacity: 0” doesn’t suggest that it should not be a part of output. It is a purely presentational concern, identical to bullets, house between paragraphs or indented textual content. What issues is **structural preservation** — block-styled parts ought to create newlines, inline ones needs to be inline.
One iffy facet might be “text-transform”. Ought to capitalized or uppercased textual content be preserved? WebKit/Blink suppose it ought to; Web Explorer would not. Is it a part of a textual content itself or merely styling?
One other one is “visibility: hidden”. Much like “opacity: 0” (and in contrast to “show: none”), a textual content continues to be a part of the stream, it simply cannot be seen. Frequent sense would counsel that it ought to nonetheless be a part of the output. And whereas Web Explorer does simply that, WebKit/Blink disagrees (additionally being curiously inconsistent with their “opacity: 0” conduct).
Parts that are not identified to a browser pose an extra downside. For instance, WebKit/Blink not too long ago began supporting aspect. That aspect isn’t displayed, and so it isn’t a part of innerText. To Web Explorer, nonetheless, it is nothing however an unknown inline aspect, and naturally it outputs its contents.
Standardization, take 2
In 2011, one other innerText proposal [is posted to WHATWG mailing list](http://lists.w3.org/Archives/Public/public-html/2011Jul/0133.html), this time by Aryeh Gregor. Aryeh proposes to both:
- Drop
innerTexttotally - Spec
innerTextto be liketextContent - Really spec
innerTextin keeping with no matter IE/WebKit are doing
Much like earlier discussions, Mozilla opposes third choice (standardizing it), whereas Microsoft and Opera oppose 1st one (dropping it).
In the identical thread, Aryeh expresses his issues about standardizing innerText:
The issue with (3) is that it will be very laborious to spec; it will be even tougher to spec in a method that every one browsers can implement; and any spec would most likely should be fairly incompatible anyway with the prevailing implementations that comply with the overall strategy. […]
Certainly, as we have seen from the assessments, compatibility poses to be a severe problem. If we have been to standardize innerText, which of the two behaviors ought to we put in a spec?
One other downside is reliance on Choice.toString() (as expressed by Boris Zbarsky):
It isn’t clear whether or not the latter is in reality an choice; that is determined by how Choice.toString will get specified and whether or not UAs are prepared to do the identical for innerText as they do for Choice.toString….
To this point the one proposal I’ve seen for Choice.toString is “do what the copy operation does”, which is neither well-defined nor acceptable for innerText. In my view.
Ultimately, we’re left with [this WHATWG ticket by Aryeh](https://www.w3.org/Bugs/Public/show_bug.cgi?id=13145) on specifying innerText. Issues look quite grim, as evidenced in one of many feedback:
I have been instructed in no unsure phrases that it is not sensible for non-Gecko browsers to take away. Relying on the rendering tree to the extent WebKit does, however, is insanely difficult to spec when it comes to commonplace stuff like DOM and CSS. Additionally, it doubtlessly breaks for indifferent nodes (WebKit behaves completely otherwise in that case). […] However Gecko folks appeared fairly sad about this type of complexity and rendering dependence in a DOM property. And however, I received the impression WebKit is reluctant to rewrite their innerText implementation in any respect. So I am figuring that the spec that will likely be applied by essentially the most browsers attainable is one which’s so simple as attainable, mainly only a compat shim. If a number of implementers truly need to implement one thing just like the innerText spec I began writing, I would be joyful to renew work on it, however that wasn’t my impression.
We will not take away it, cannot change it, cannot spec it to rely upon rendering, and spec’ing it will be fairly troublesome 🙂
Gentle on the finish of a tunnel?
May there nonetheless be some hope for innerText or will it perpetually keep an unspecified legacy with 2 completely different implementations?
My hope is that the take a look at suite and compatibility desk are step one in making issues higher. We have to know precisely how engines differ, and we have to have a great understanding of what to incorporate in a spec. I am certain this does not cowl all instances, nevertheless it’s a begin (different elements price exploring: shadow DOM, indifferent nodes).
I believe this take a look at suite needs to be sufficient to put in writing 90%-complete spec of innerText. The most important problem is deciding which conduct to decide on amongst IE and WebKit/Blink.
The plan could possibly be:
1. Write a spec
2. Attempt to converge IE and WebKit/Blink conduct
3. Implement spec’d conduct in Firefox
Seeing [how amazing Microsoft has been](https://standing.fashionable.ie/) not too long ago, I actually hope we are able to make this occur.
The naive spec
I took a stab at a comparatively easy model of innerText:
Couple necessary duties right here:
1. Checking if a textual content node is inside “formatted” context (i.e. a toddler of “white-space: pre-*” node), by which case its contents needs to be concatenated as is; in any other case collapse all whitespaces to 1.
2. Checking if a node is block-styled (“block”, “list-item”, “desk”, and so forth.), by which case it must be surrounded by newlines; in any other case, it is inline and its contents are output as is.
Then there’s issues like ignoring , <model>, and so forth. nodes and inserting tab (“t”) between <td> parts (to comply with WebKit/Blink lead).
That is nonetheless a very minimal and naive implementation. For one, it would not collapse newlines between block parts — a fairly necessary facet. With a view to do this, we have to preserve observe of extra state — to know details about earlier node’s model. It additionally would not normalize whitespace in “true” method — a textual content node with main and trailing areas, for instance, ought to have these areas stripped whether it is (the one node?) in a block aspect.
This wants extra work, nevertheless it’s an honest begin.
It could be additionally a good suggestion to put in writing innerText implementation in Javascript, with unit assessments for every of the “function” in a compat desk. Maybe even supporting 2 modes — IE and WebKit/Blink. An implementation like this might then be merely built-in into non-supporting engines (or used as a correct polyfill).
I would love to listen to your ideas, concepts, experiences, criticism. I hope (with all your assist) we are able to make some enchancment on this path. And even when nothing modifications, no less than some mild was shed on this very misunderstood historical function.
Replace: half a 12 months later
It has been half a 12 months since I wrote this publish and few issues modified for the higher!
To begin with, [Robert O’Callahan](http://robert.ocallahan.org/) of Mozilla made some superior effort — he determined to [spec out the innerText](https://github.com/rocallahan/innerText-spec) after which applied it in Firefox. The concept was to create one thing easy however wise. The proposed spec — solely after about 11 years — is now [implemented in Firefox 45](https://bugzilla.mozilla.org/show_bug.cgi?id=264412) 🙂
I’ve added FF45 outcomes to [a compat table](http://kangax.github.io/jstests/innerText/) and other than couple variations, FF is fairly near Chrome’s implementation. I am additionally planning so as to add extra assessments to seek out every other variations amongst Chrome, FF, and Edge.
The spec already revealed few bugs in Chrome, which I am hoping to file tickets for and see resolved. If we are able to then additionally get Edge to converge, we’ll be very near having all 3 greatest browsers behave equally, making `innerText` viable function in a close to future.