senthil_rajasek a year 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...

  • thomasahle a year ago

    An example:

    HTML:

        <div id="example">
          <p style="display: none;">Hidden text</p>
          <p>Visible text</p>
        </div>
    
    Javascript:

        const exampleDiv = document.querySelector('#example');
    
        console.log(exampleDiv.innerText); // "Visible text"
        console.log(exampleDiv.textContent); // "Hidden textVisible text"
    • hgsgm a year ago

      display:none != visibility:hidden

      • tomjakubowski a year 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 a year ago

          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>

  • raincole a year 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 a year 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.

  • kitsunesoba a year 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 a year 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 a year ago

        Why couldn’t each one of the two have its own correct alias?

  • marcosdumay a year 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 a year 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?

TechBro8615 a year 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 a year ago

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

Aardwolf a year 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 a year 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...

  • lucideer a year 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.

robust-cactus a year 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.

  • dist-epoch a year 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.

seanw444 a year ago

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

  • ClassyJacket a year ago

    I mean web developers generally earn high salaries so statistically...

  • duxup a year ago

    That’s probably true.

dgreensp a year 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.

Night_Thastus a year ago

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

karol a year ago

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

  • karol a year ago

    He seems active on Twitter!