[HN Gopher] The poor, misunderstood innerText (2015)
___________________________________________________________________
The poor, misunderstood innerText (2015)
Author : sharno
Score : 86 points
Date : 2023-03-22 15:02 UTC (7 hours ago)
(HTM) web link (perfectionkills.com)
(TXT) w3m dump (perfectionkills.com)
| robust-cactus wrote:
| > 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 wrote:
| > 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.
| lucideer wrote:
| > _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...
| seanw444 wrote:
| I initially missed the comma, and read the title as implying that
| rich people understood InnerText better than poor people.
| duxup wrote:
| That's probably true.
| ClassyJacket wrote:
| I mean web developers generally earn high salaries so
| statistically...
| Aardwolf wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| Night_Thastus wrote:
| It seems the markdown formatted links are broken. Makes it a
| little ugly to read in parts.
| TechBro8615 wrote:
| 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 wrote:
| It seems to have HTTPS just with a cert that doesn't match the
| URL.
| karol wrote:
| Hope that guy is OK, he stopped posting at some point in 2015.
| karol wrote:
| He seems active on Twitter!
| senthil_rajasek wrote:
| 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...
| raincole wrote:
| 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?
| thomasahle wrote:
| 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 wrote:
| display:none != visibility:hidden
| tomjakubowski wrote:
| 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 wrote:
| 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>
| [deleted]
| dang wrote:
| 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)
| lucideer wrote:
| 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 wrote:
| 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 wrote:
| 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.
| marcosdumay wrote:
| 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 wrote:
| > _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?
___________________________________________________________________
(page generated 2023-03-22 23:01 UTC)