7 ms·

The poor, misunderstood innerText

178 points by antouank 12y ago

AshleysBrain 12y ago
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 12y ago
  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 12y ago
    (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 12y ago
      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.
      - greggman 12y ago
        I'm guessing that means you're stuck with western languages only? Languages requiring an IME for input are hard to do in canvas. Also copy to clipboard?
        moron4hire 12y ago
        I've got the clipboard handled, and no existing IME works well in a head-mounted display anyway, so it's not a concern for my project.
      - frik 12y ago
        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/contentEditable https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement... , http://caniuse.com/#feat=contenteditable http://caniuse.com/#feat=contenteditable
        moron4hire 12y ago
        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 12y ago
  - mxfh 12y ago
    Not even counting the numerous cases of white spaces[1], combining characters, non-breaking space, figure space, soft hyphens or zero-width joiners. This sounds difficult enough in latin script, almost impossible to capture all cases in non LTR, non-latin grapheme based texts. [1] http://en.wikipedia.org/wiki/Whitespace_character http://en.wikipedia.org/wiki/Whitespace_character
    - kangax 12y ago
      But browsers already take care of this. They collapse all the spaces in markup for non-pre-formatted blocks; they render block/inline elements accordingly; insert newlines where needed, etc. And then, once you select some text from the page — there's your "plain text" representation. We probably can't avoid differences among browsers (simply due to the vast nature of HTML — form controls, media content, generated content, new elements like <template>, non-standard extensions, etc.) but in context of a single browser, the logic already exists beneath. It's just not exposed conveniently.
- btilly 12y ago
  He addressed that with a simple JS implementation and a performance test against the native property. There was an order of magnitude performance difference. JS lib compatibility is the best of all easily achievable worlds. That doesn't mean that it is very good.
- userbinator 12y ago
  but maybe a JS lib could step in to come up with a reliable way of doing it That just moves the problem of its definition being vague from the browser developers to the JS lib developers... and there are so many more of the latter than the former that I could see it resulting in various libraries adopting slightly different definitions. It does make it easier to adopt one definition across browsers though.
- deleted 12y ago
  [deleted]
rntz 12y ago
The first live example doesn't work in Firefox, for a reason the article already mentioned: Firefox doesn't support innerText.
- coldtea 12y ago
  So what's the purpose of this comment?
  - efraim 12y ago
    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 12y ago
      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 12y ago
        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.
      - heinrich5991 12y ago
        Yes, there are! I cared for the contents, but not enough to open another program…
userbinator 12y ago
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."
deleted 12y ago
[deleted]
- deleted 12y ago
  [deleted]
JacksonGariety 12y ago
>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.
gsnedders 12y ago
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.)
frik 12y ago
> 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/contentEditable https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement... (see bugs list). * and additional touch related bugs in mobile browsers.
timdown 12y ago
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

178 points by antouank 12y ago

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 12y ago
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 12y ago
  (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 12y ago
    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.
    - greggman 12y ago
      I'm guessing that means you're stuck with western languages only? Languages requiring an IME for input are hard to do in canvas. Also copy to clipboard?
      - moron4hire 12y ago
        I've got the clipboard handled, and no existing IME works well in a head-mounted display anyway, so it's not a concern for my project.
    - frik 12y ago
      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/contentEditable https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement... , http://caniuse.com/#feat=contenteditable http://caniuse.com/#feat=contenteditable
      - moron4hire 12y ago
        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 12y ago
- mxfh 12y ago
  Not even counting the numerous cases of white spaces[1], combining characters, non-breaking space, figure space, soft hyphens or zero-width joiners. This sounds difficult enough in latin script, almost impossible to capture all cases in non LTR, non-latin grapheme based texts. [1] http://en.wikipedia.org/wiki/Whitespace_character http://en.wikipedia.org/wiki/Whitespace_character
  - kangax 12y ago
    But browsers already take care of this. They collapse all the spaces in markup for non-pre-formatted blocks; they render block/inline elements accordingly; insert newlines where needed, etc. And then, once you select some text from the page — there's your "plain text" representation. We probably can't avoid differences among browsers (simply due to the vast nature of HTML — form controls, media content, generated content, new elements like <template>, non-standard extensions, etc.) but in context of a single browser, the logic already exists beneath. It's just not exposed conveniently.
btilly 12y ago
He addressed that with a simple JS implementation and a performance test against the native property. There was an order of magnitude performance difference. JS lib compatibility is the best of all easily achievable worlds. That doesn't mean that it is very good.
userbinator 12y ago
but maybe a JS lib could step in to come up with a reliable way of doing it That just moves the problem of its definition being vague from the browser developers to the JS lib developers... and there are so many more of the latter than the former that I could see it resulting in various libraries adopting slightly different definitions. It does make it easier to adopt one definition across browsers though.
deleted 12y ago
[deleted]

rntz 12y ago

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

coldtea 12y ago
So what's the purpose of this comment?
- efraim 12y ago
  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 12y ago
    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 12y ago
      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.
    - heinrich5991 12y ago
      Yes, there are! I cared for the contents, but not enough to open another program…

userbinator 12y ago

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."

deleted 12y ago

[deleted]

deleted 12y ago
[deleted]

JacksonGariety 12y ago

>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.

gsnedders 12y ago

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.)

frik 12y ago

> 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/contentEditable https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement... (see bugs list). * and additional touch related bugs in mobile browsers.

timdown 12y ago

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