4 ms·

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 tec

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?
kitsunesoba 4y ago
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.
- lucideer 4y ago
  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.
  - grugagag 4y ago
    Why couldn’t each one of the two have its own correct alias?

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?

kitsunesoba 4y ago

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.

lucideer 4y ago
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.
- grugagag 4y ago
  Why couldn’t each one of the two have its own correct alias?