6 ms·

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 b

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
        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.
  - freshhawk 12y ago
    "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?
    - freshhawk 12y ago
      *a two way translation
    - kangax 12y ago
      > 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"? ;)
  - zimbatm 12y ago
    Have you thought of intercepting keyboard strokes to maintain your own internal state of the text ? Instead of having Keyboard-->HTML-(extract)->innerText you would have Keyboard-->innerText-(render)->HTML. Contenteditable is a honey pot, it makes you think that implementing a text editor will be easy, until you hit all the corner cases.
    - kangax 12y ago
      Unfortunately not possible since the editor is part of a browser extension and is activated on any page with textarea/contenteditable. Text could change at any time by other scripts, and the only way to intercept those changes is via MutationObserver. MutationObserver gives you changed node and its text (without getting entire plain text, we can't really "transposition" this all onto a global text to figure out what changed).
- 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]

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
        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.
- freshhawk 12y ago
  "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?
  - freshhawk 12y ago
    *a two way translation
  - kangax 12y ago
    > 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"? ;)
- zimbatm 12y ago
  Have you thought of intercepting keyboard strokes to maintain your own internal state of the text ? Instead of having Keyboard-->HTML-(extract)->innerText you would have Keyboard-->innerText-(render)->HTML. Contenteditable is a honey pot, it makes you think that implementing a text editor will be easy, until you hit all the corner cases.
  - kangax 12y ago
    Unfortunately not possible since the editor is part of a browser extension and is activated on any page with textarea/contenteditable. Text could change at any time by other scripts, and the only way to intercept those changes is via MutationObserver. MutationObserver gives you changed node and its text (without getting entire plain text, we can't really "transposition" this all onto a global text to figure out what changed).
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]