4 ms·

The poor, misunderstood innerText (2015)

112 points by sharno 4y ago

seanw444 4y ago
I initially missed the comma, and read the title as implying that rich people understood InnerText better than poor people.
- ClassyJacket 4y ago
  I mean web developers generally earn high salaries so statistically...
- duxup 4y ago
  That’s probably true.
Aardwolf 4y ago
> 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)
- theobeers 4y ago
  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/innerText https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement...
- lucideer 4y ago
  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.
senthil_rajasek 4y ago
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/innerText https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement...
- thomasahle 4y ago
 An example: HTML: <div id="example"> Hidden text Visible text </div> Javascript: const exampleDiv = document.querySelector('#example'); console.log(exampleDiv.innerText); // "Visible text" console.log(exampleDiv.textContent); // "Hidden textVisible text"
 - hgsgm 4y ago
 display:none != visibility:hidden
 - tomjakubowski 4y ago
 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
 - 6510 4y ago
 I think he means something like:Not Displayed text Hidden text not Hidden text
- raincole 4y ago
 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?
lucideer 4y ago
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.
- marcosdumay 4y ago
  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.
  - lucideer 4y ago
    > 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?
robust-cactus 4y ago
> 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.
- lucideer 4y ago
  > 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-innertext-idl-attribute https://html.spec.whatwg.org/multipage/dom.html#the-innertex...
- dist-epoch 4y ago
  > 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.
karol 4y ago
Hope that guy is OK, he stopped posting at some point in 2015.
- karol 4y ago
  He seems active on Twitter!
Night_Thastus 4y ago
It seems the markdown formatted links are broken. Makes it a little ugly to read in parts.
deleted 4y ago
[deleted]
TechBro8615 4y ago
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.)
- zamadatix 4y ago
  It seems to have HTTPS just with a cert that doesn't match the URL.
dang 4y ago
Related: The Poor, Misunderstood InnerText (2015) - https://news.ycombinator.com/item?id=25176309 https://news.ycombinator.com/item?id=25176309 - Nov 2020 (13 comments) The poor, misunderstood innerText - https://news.ycombinator.com/item?id=10167066 https://news.ycombinator.com/item?id=10167066 - Sept 2015 (1 comment) The poor, misunderstood innerText - https://news.ycombinator.com/item?id=9304606 https://news.ycombinator.com/item?id=9304606 - April 2015 (32 comments)
dgreensp 4y ago
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.

112 points by sharno 4y ago

I initially missed the comma, and read the title as implying that rich people understood InnerText better than poor people.

ClassyJacket 4y ago
I mean web developers generally earn high salaries so statistically...
duxup 4y ago
That’s probably true.

Aardwolf 4y ago

> 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)

theobeers 4y ago
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/innerText https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement...
lucideer 4y ago
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.

senthil_rajasek 4y ago

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/innerText https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement...

thomasahle 4y ago
An example: HTML: <div id="example"> Hidden text Visible text </div> Javascript: const exampleDiv = document.querySelector('#example'); console.log(exampleDiv.innerText); // "Visible text" console.log(exampleDiv.textContent); // "Hidden textVisible text"
- hgsgm 4y ago
 display:none != visibility:hidden
 - tomjakubowski 4y ago
 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
 - 6510 4y ago
 I think he means something like:Not Displayed text Hidden text not Hidden text
raincole 4y ago
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?

lucideer 4y ago

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.

marcosdumay 4y ago
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.
- lucideer 4y ago
  > 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?

robust-cactus 4y ago

> 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.

lucideer 4y ago
> 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-innertext-idl-attribute https://html.spec.whatwg.org/multipage/dom.html#the-innertex...
dist-epoch 4y ago
> 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.

karol 4y ago

Hope that guy is OK, he stopped posting at some point in 2015.

karol 4y ago
He seems active on Twitter!

Night_Thastus 4y ago

It seems the markdown formatted links are broken. Makes it a little ugly to read in parts.

deleted 4y ago

[deleted]

TechBro8615 4y ago

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.)

zamadatix 4y ago
It seems to have HTTPS just with a cert that doesn't match the URL.

dang 4y ago

Related: The Poor, Misunderstood InnerText (2015) - https://news.ycombinator.com/item?id=25176309 https://news.ycombinator.com/item?id=25176309 - Nov 2020 (13 comments) The poor, misunderstood innerText - https://news.ycombinator.com/item?id=10167066 https://news.ycombinator.com/item?id=10167066 - Sept 2015 (1 comment) The poor, misunderstood innerText - https://news.ycombinator.com/item?id=9304606 https://news.ycombinator.com/item?id=9304606 - April 2015 (32 comments)

dgreensp 4y ago

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.