The way I always distinguished innerText from textContent in my head is:
- innerText does what a human would likely want (fuzzy)
- textContent does what's technically correct (strict)
or to put it another way:
- retrieving textContent will give you what an author writing HTML by hand likely intended
- retrieving innerText will give you what an author writing into a WYSIWYG likely intended
The problem with fuzzy things like this is their implementations are much more likely to be buggier, but - barring bugs & inconsistencies (which should be ironed out by now with the HTML5 spec) - the intent of innerText seems preferable for most real-world "getter" use-cases.
For "setters" textContent does seem better, but I find in practice I use element.appendChild(document.createTextNode(value)) more frequently since it's non-destructive.
Related:
The Poor, Misunderstood InnerText (2015) - https://news.ycombinator.com/item?id=25176309 - Nov 2020 (13 comments)
The poor, misunderstood innerText - https://news.ycombinator.com/item?id=10167066 - Sept 2015 (1 comment)
The poor, misunderstood innerText - https://news.ycombinator.com/item?id=9304606 - April 2015 (32 comments)
For some reason I can't open this site on my iPhone, due to the lack of HTTPS, even when tapping "Visit Anyway." I tap it and nothing happens. Anyone know what might be causing this? Maybe it's one of my extensions...
EDIT: Weird. After returning here and clicking the link again, it now renders fine... it doesn't even show the warning, and now has a lock icon in the URL bar?
(Also, you gotta love the fact that a site called "perfection kills" doesn't implement HTTPS - fair play to the author.)
> innerText is pretty much always frown upon
Ugh, and here I was thinking this one was the 'better' one to use than innerHTML (if you can get away with it, when needing just unformatted text and not needing the convenience of HTML tags being automatically formatted for you)
> innerText is hard to spec
I think this post basically spec'd it, did the competitive analysis and outlined a clear why tho!
How do these standards processes work? It seems like there's demand.
I initially missed the comma, and read the title as implying that rich people understood InnerText better than poor people.
Implementers of content-editable-based rich text editors (I speak from experience) do not need browsers to do anything differently here for convenience; such editors have their own internal representation and algorithms for getting the “plain text” of the document.
There could be other uses.
It seems the markdown formatted links are broken. Makes it a little ugly to read in parts.
Hope that guy is OK, he stopped posting at some point in 2015.
Oh boy, this is an article from April 2015.
I had to look this ( innerText vs textContent) up yesterday and MDN had a much clearer explanation.
"The innerText property of the HTMLElement interface represents the rendered text content of a node and its descendants."
https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement...