While investigating these issues, I came across a () from 2010, and pretty much the only place where someone tries to bring attention to this issue. If you have a giant chunk of newlines in HTML source, you'll have them as part of textContent as well. Notice that no whitespace normalization is performed, the text and whitespace are essentially spit out the same way they're defined in the markup. innerHTML) and stripping it off of the tags. In other words, textContent returns concatenated text of all text nodes. This is the empty string if the node has no children.įor TEXT_NODE, CDATA_SECTION_NODE, COMMENT_NODE, PROCESSING_INSTRUCTION_NODE The string returned is made of the text content of this node depending on its type, as defined below:įor ELEMENT_NODE, ATTRIBUTE_NODE, ENTITY_NODE, ENTITY_REFERENCE_NODE, DOCUMENT_FRAGMENT_NODE:Ĭoncatenation of the textContent attribute value of every child node, excluding COMMENT_NODE and PROCESSING_INSTRUCTION_NODE nodes. No whitespace normalization is performed and the returned string does not contain the white spaces in element content (see the attribute Text.isElementContentWhitespace). On getting, no serialization is performed, the returned string does not contain any markup. This attribute returns the text content of this node and its descendants.
But it preserves spaces as they are defined in the markup. textContent, on the other hand, does something strange - it ignores newlines created by and around styled-as-block elements ( in this case).
Notice how innerText almost precisely represents exactly how text appears on the page.
See the Pen gbEWvR by Juriy Zaytsev ( on CodePen. This is when I realized just how ridiculously important these seemingly insignificant whitespace deviations between textContent and innerText are. What you're about to hear is the story of Internet Explorer getting something right, the real differences between these properties, and how we probably want to standardize this red-headed stepchild.Ī little while ago, I was helping someone with the implementation of text editor in a browser. Little did I know that I was merely looking at the tip of the iceberg and that my perception of innerText will change drastically. Just steer away from innerText, use this "combo" for cross-browser code, keep in mind slight differences, and you're golden. HTMLElement), and so on.Īll this time I was strongly convinced that there isn't much else to know about textContent vs. And I even wrote () on the exact differences - slight whitespace deviations, things like inclusion of contents by textContent (but not innerText), differences in interface ( Node vs. Those curious enough to investigate further usually do find them, but only slight ones, and only when retrieving text, not setting it.īack in 2009, I did just that. After all, why would you want to use a non-standard property that does the "same" thing as a standard one? Very few people venture to actually check the differences, and on the surface it certainly appears as there is none. InnerText is pretty much always frown upon. Or as the main webcompat offender in () - since Mozilla is one of the only major browsers refusing to add this non-standard property - when someone doesn't know what they're doing, skipping textContent "fallback" altogether: It's usually seen in combination with textContent - as a cross-browser way of using standard property followed by a proprietary one: That quirky, non-standard way of element's text retrieval, () and later "copied" by both WebKit/Blink and Opera for web-compatibility reasons. Few things are as misunderstood and misused on the web as innerText property.
0 kommentar(er)
