

The poor, misunderstood innerText - antouank
http://perfectionkills.com/the-poor-misunderstood-innerText/

======
AshleysBrain
My impression from this is that "take the text nodes and format them with
whitespace that corresponds to the browser layout" is a vague enough
definition that browsers can't agree on precisely how to do that. So it seems
like it shouldn't be standardised, but maybe a JS lib could step in to come up
with a reliable way of doing it?

~~~
crazygringo
Completely agreed. There are such a ridiculous number of edge cases here, that
it makes much more sense for this to be done by a JavaScript library that
either comes with a huge number of configuration flags (which would be totally
inappropriate for a built-in DOM function), or else whose source code is
designed to be edited directly. (E.g. do you want a bullet to become a "•" or
a "*" or a "-", etc.)

~~~
kangax
(author here)

I'm working on text editor with real-time spelling correction where
`innerText`-like retrieval has to happen quite frequently; it's what pushed me
to research the state of affairs with `innerText` in the first place.

It __pains __me that we don 't have a quick, native way of doing that; that I
have to traverse the DOM manually instead — a horribly, horribly slow process
— essentially writing what `innerText` was supposed to be.

I guess HTML/DOM were never really designed to be good at a task like this.
The closest thing is Selection/Ranges API but it's still way behind in terms
of performance.

The fact that there's `innerText` in some browser sarcastically starring in
your face ("I'm here, but you can't really use me") just makes this so much
crappier.

I guess a lot of this boils down to performance. It's certainly possible to
emulate `innerText` but we can't possibly match native speed. And speed is
crucial for any kind of real-time editing that needs to have a quick access to
plain text version of an element.

~~~
moron4hire
This would be one of the (many) reasons why, in _my_ browser-based text
editor, I just avoided the DOM entirely, drawing everything to a Canvas.

~~~
frik
Font rendering in Canvas2D is _slow_ plus you have to reinvent the wheel with
things like word-wrap/new line. Using a texture based font in Canvas/WebGL is
a lot faster and is used in many (older) games, but with the obvious
downsides.

Browsers should finally fix all issues of _contentEditable_ API:
[http://www.quirksmode.org/dom/execCommand/](http://www.quirksmode.org/dom/execCommand/)
, [https://developer.mozilla.org/en-
US/docs/Web/API/HTMLElement...](https://developer.mozilla.org/en-
US/docs/Web/API/HTMLElement/contentEditable) ,
[http://caniuse.com/#feat=contenteditable](http://caniuse.com/#feat=contenteditable)

~~~
moron4hire
It's fast enough, and newline/wordwrap are not that hard to implement.

Do you really expect them to fix those issues? I'm not holding my breath. In
the mean time, I've got a text editor that works identically in almost every
browser, with very little browser-specific code, in VR.

~~~
frik
Really interesting your VR editor!

> Do you really expect them to fix those issues?

Mozilla could fix the issues without hurting their business. Their legacy
Thunderbird email client as well as various FirefoxOS system apps would profit
too.

Microsoft, Apple and Google all have Office cloud apps and a really bug free
contentEditable implementation would be a competition to their online
Word/Pages/Docs. Google Docs v1 used contentEditable, but with v2 they coded a
page layout render JS library.

~~~
moron4hire
I'm just saying, these issues have been issues for a long time, and to your
point Mozilla does dog-food its own contentEditable (especially RE: the Ace
editor) and it _still_ hasn't seen fit to fix these issues. Yeah, it's clear
that it's in their interest, but I think they've all demonstrated that it's
just not a big enough deal to them.

------
frik
> Coming back to a text editor... Let's say we have a _contenteditable_ area
> in which a user is writing something

Browsers should fix all issues of _contentEditable_ API:

* [http://www.quirksmode.org/dom/execCommand.html](http://www.quirksmode.org/dom/execCommand.html) (see compatibility table (old but still valid), and demo: [http://www.quirksmode.org/dom/execCommand/](http://www.quirksmode.org/dom/execCommand/)) ,

* [http://caniuse.com/#feat=contenteditable](http://caniuse.com/#feat=contenteditable) (see issues tab) ,

* [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement...](https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/contentEditable) (see bugs list).

* and additional touch related bugs in mobile browsers.

------
rntz
The first live example doesn't work in Firefox, for a reason the article
already mentioned: Firefox doesn't support innerText.

~~~
coldtea
So what's the purpose of this comment?

~~~
efraim
I would think the examples are there to show the difference between the two
methods but in firefox the innertext column only shows "undefined". Maybe a
picture could be used for firefox users?

~~~
coldtea
Are there "firefox users" upon the HN crowd though (or the intended technical
/ web dev crowd)?

I'd say that pretty much all of those of article was intended for have 3 or
more browsers installed and regularly test things on each. It wouldn't be much
for them to check the article in a different browser if they cared for its
contents.

~~~
mweibel
why shouldn't there be "firefox users" in the HN crowd?

Anyway, the purpose of the code example there was to show how it looks and
explains some more things in the text afterwards. If you don't see what he
means because you're using a different browser, it's essentially pointless to
show it at all.

------
userbinator
That table is another interesting opportunity for browser fingerprinting, and
also shows how difficult it is to define precisely a concept that at first
seems deceptively simple: "retrieve the text contents inside an element."

------
gsnedders
Note that WebKit/Blink are very unlikely to change their behaviour to be more
interoperable/sane if it ever gets standardised because so many of their tests
rely on it, and making sure all the test expectations stayed valid while
updating it would be an enormous amount of work. (Lots of their tests load a
webpage, take the innerText of it, and compare that string with an
expectation.)

------
timdown
I've had a go at implementing a simple version of innerText:
[https://github.com/timdown/rangy/wiki/Text-Range-
Module](https://github.com/timdown/rangy/wiki/Text-Range-Module)

------
JacksonGariety
>Thankfully, at least Chrome (Blink) and Safari (WebKit) were considerate
enough to immitate it [innerText].

This looks to me like a small error when the standard spec was written which
has become more important over time and needs to be updated—not a case for
praising proprietary software.

