That's true. I'm not sure what you mean though; whether one makes the inner div display: none or visibility: hidden, it doesn't appear to make a difference to the values of innerText vs. textContent
I think he means something like:<p style="display: none;">Not Displayed text</p> <p style="visibility: hidden">Hidden text</p> not <p style="display: none;">Hidden text</p>
I think the confusion comes from the fact that you can set it. If it's "rendered result", then everyone, for a sane API design, should assume it's read-only, right?
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.
Even though verbosity is looked down upon by a lot of developers, I think that maybe applying a bit more that when naming these properties would've helped avoid the their ambiguity… "innerText" and "textContent" sound too much like the same thing. Something like "renderedTextContent" and "fullTextContent" would've been better.
That's a good idea in retrospect but could only have been possible if the current state was pre-planned. In actual fact the two properties were competing, with each side hoping the other would die. And of course changing names later is not a very viable path.
textContent seem to strip tags out of your string, so it's not really strict. innerText strictly preserves the HTML semantics of your string, textContent doesn't preserve anything.
Back then when those things were new, there was absolutely no way to store a string in an element and get it back later. Neither of those do this.
> textContent seem to strip tags out of your string, so it's not really strict.
Your mental model is a little off here. The character data returned will be coming from an internal representation of a node hierarchy - there are no tags, just a collection of nodes. The text data will be assembled from all text nodes in that collection and concatenated. Nothing is being stripped.
I'd guess the difference in original pre-spec features was innerText taking an internal representation that had been pre-processed for rendering before being stored in memory.
> innerText strictly preserves the HTML semantics of your string, textContent doesn't preserve anything.
It's the opposite. textContent preserves the semantics of your string in HTML source. innerText returns an intermediate representation of how you would expect your string to be handled by the rendering pipeline.
> Back then when those things were new, there was absolutely no way to store a string in an element and get it back later. Neither of those do this.
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.)
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)
This blog post is from 2015—which should be added to the title here on HN.
See MDN's docs on innerText. It's fully supported in Firefox since version 45 (2016). (Edit: the blog post also has an update at the bottom, noting that, as of 2016, the situation was already much better.)
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.
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...
An example:
HTML:
Javascript:display:none != visibility:hidden
That's true. I'm not sure what you mean though; whether one makes the inner div display: none or visibility: hidden, it doesn't appear to make a difference to the values of innerText vs. textContent
I think he means something like:<p style="display: none;">Not Displayed text</p> <p style="visibility: hidden">Hidden text</p> not <p style="display: none;">Hidden text</p>
I think the confusion comes from the fact that you can set it. If it's "rendered result", then everyone, for a sane API design, should assume it's read-only, right?
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.
Even though verbosity is looked down upon by a lot of developers, I think that maybe applying a bit more that when naming these properties would've helped avoid the their ambiguity… "innerText" and "textContent" sound too much like the same thing. Something like "renderedTextContent" and "fullTextContent" would've been better.
That's a good idea in retrospect but could only have been possible if the current state was pre-planned. In actual fact the two properties were competing, with each side hoping the other would die. And of course changing names later is not a very viable path.
Why couldn’t each one of the two have its own correct alias?
textContent seem to strip tags out of your string, so it's not really strict. innerText strictly preserves the HTML semantics of your string, textContent doesn't preserve anything.
Back then when those things were new, there was absolutely no way to store a string in an element and get it back later. Neither of those do this.
> textContent seem to strip tags out of your string, so it's not really strict.
Your mental model is a little off here. The character data returned will be coming from an internal representation of a node hierarchy - there are no tags, just a collection of nodes. The text data will be assembled from all text nodes in that collection and concatenated. Nothing is being stripped.
I'd guess the difference in original pre-spec features was innerText taking an internal representation that had been pre-processed for rendering before being stored in memory.
> innerText strictly preserves the HTML semantics of your string, textContent doesn't preserve anything.
It's the opposite. textContent preserves the semantics of your string in HTML source. innerText returns an intermediate representation of how you would expect your string to be handled by the rendering pipeline.
> Back then when those things were new, there was absolutely no way to store a string in an element and get it back later. Neither of those do this.
Not sure what you mean by this?
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.)
It seems to have HTTPS just with a cert that doesn't match the URL.
> 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)
This blog post is from 2015—which should be added to the title here on HN.
See MDN's docs on innerText. It's fully supported in Firefox since version 45 (2016). (Edit: the blog post also has an update at the bottom, noting that, as of 2016, the situation was already much better.)
https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement...
I don't think the article is saying it should be frowned upon, just that it traditionally has been (not always for valid reasons).
It's always been considered better than innerHTML though; it's only textContent people think it's worse than.
> 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.
> How do these standards processes work? It seems like there's demand.
There was, and it has since been standardised.
https://html.spec.whatwg.org/multipage/dom.html#the-innertex...
> How do these standards processes work?
Chrome implements something, and 3 years later it's adopted as a standard because the other browser (Firefox) was forced to implement it anyway.
I initially missed the comma, and read the title as implying that rich people understood InnerText better than poor people.
I mean web developers generally earn high salaries so statistically...
That’s probably true.
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.
He seems active on Twitter!