Comment by freshhawk | Hacker News Reader

Comment by freshhawk | Hacker News Reader

Parent Full thread

"essentially writing what `innerText` was supposed to be"

For your use case. Making, as you mentioned, a huge number of edge case decisions. So if innerText was standardized to your use case what would it be good for other than your specific project?

Pulling large chunks of plain text as a string to process for any low latency tasks constrains the size of text you can reasonably work with. JS strings are immutable as well, that's a lot of copying. So you can't be grabbing the whole document at once with innerText, but you still want it to handle line breaks. So innerText is useful for a text editor where the chunks are more than one line long but still fairly short.

Another issue is this whole handling of converting lists and tables to some kind of plain text markup. Is that a two translation? Are tabs going to turn into table elements if I have them in a string and set innerText? That seems pretty crazy, but not doing so would just make it very weirdly asymmetrical.

I liked the article, lot's of good info and stuff I didn't know. But I did come away thinking "Thank you Mozilla, at least someone is pushing for sanity". How much horribly slower do you want the DOM to be?

> So if innerText was standardized to your use case what would it be good for other than your specific project?

I don't think this is a very specific task. As you've seen in the post, other people have similar requirements (text editor, selection retrieval, etc.) and similar desire for keeping `innerText`.

> Pulling large chunks of plain text as a string to process for any low latency tasks constrains the size of text you can reasonably work with. JS strings are immutable as well, that's a lot of copying.

Pulling large chunks of plain text — that's a plausible argument, but no different than pulling, say, `innerHTML` (large chunk) or `textContent` (large chunk) or really anything else in JS land (which if often full of strings — JSON, templates, whatever).

> Another issue is this whole handling of converting lists and tables to some kind of plain text markup. Is that a two translation? Are tabs going to turn into table elements if I have them in a string and set innerText? That seems pretty crazy, but not doing so would just make it very weirdly asymmetrical.

That's a very good point! But don't forget that we already have a standard way of setting element contents from plain text — `textContent`. Yes, innerText setting would have to be assymetrical; I doubt anyone would want to go down the rabbit hole of backwards conversion. Everyone usually agrees that when it comes to setting, `innerText` should simply act like `textContent` (to quote spec: "on setting, no parsing is performed either, the input string is taken as pure textual content.")

> How much horribly slower do you want the DOM to be? Well, as app devs, we still need to implement plain text retrieval. By not having it natively in Mozilla, the joke is really on the users — more strings (in JS land), more DOM iteration, more everything. How is that for a "slow DOM"? ;)

> As you've seen in the post, other people have similar requirements (text editor, selection retrieval, etc.) and similar desire for keeping `innerText`.

> Well, as app devs, we still need to implement plain text retrieval.

This is the were we disagree, and I'm saying that as someone who's current hobby project is a browser based text editor.

Converting a 2D layout of nodes with both layout directives and text content to a string is a lossy operation. It's ambiguous. There are HTML elements that prevent that like textboxes and pre nodes. If you add layout to your text, then you have to deal with it. The DOM doesn't include a way to encode your conversion needs and it should not.

I think if you need to implement plain text retrieval then you've made a design error. At the very least you are fighting the environment in which you chose to implement your software.

*a two way translation

Reply on news.ycombinator.com