innerText on content editable doubling some line breaks

Question

I am trying to read multi line user input on a content editable div, and I don't get the right number of line breaks when I read the input with contentEditableDiv.innerText.

I tried textContent, but it doesn't return any line break, while innerText returns too many sometimes. innerHTML doesn't seem appropriate since I don't want any HTML code, just text.

If my div contains:

a
b

It returns "a↵b" (97 10 98 in the example)

But if my <div> contains:

a

b

innerText returns a↵↵↵b (one too many ↵, 97 10 10 10 98 in the example)

var input = document.getElementById("input");
var button = document.getElementById("button");
var result = document.getElementById("result");
button.addEventListener("click", (event) => {
  var charCodes = "";
  for (var i = 0; i < input.innerText.length; ++i) {
    charCodes += input.innerText.charCodeAt(i) + " ";
  }
  result.innerText = charCodes;
});

<div id="input" contenteditable="true" spellcheck="true" style="border:1px #000 solid"></div>
<button id="button">check</button>
<div id="result"></div>

If this is a standard `` element, have you tried accessing `input.value` to see if that's accurate? — jake, Jun 11 '19 at 01:53
Please edit your question to include a [minimal, complete, verifiable example](https://stackoverflow.com/help/minimal-reproducible-example). — Tyler Roper, Jun 11 '19 at 02:04
@Carlo the result from your code snippet was `97 10 97` for input `a↵a` in my environment, which is Chrome 74.0.3729.169 on Windows 10. Is it different from what you are seeing? — Yas Ikeda, Jun 11 '19 at 02:45
FWIW, if you run the above example in Firefox `a[empty line]b` returns: `97 10 10 10 98 10`. You can find more explanation on `.innerText` and its cross-browser issues [here](http://perfectionkills.com/the-poor-misunderstood-innerText/) — IronGeek, Jun 11 '19 at 02:46
Have you tried this? https://stackoverflow.com/a/24689420/4048698 — Jie Wang, Oct 26 '20 at 06:46

Jan Turoň · Answer 1 · 2020-11-27T13:48:05.700

The standard is a bit vague:

UAs should offer a way for the user to request an explicit line break at the caret position without breaking the paragraph, e.g. as the default action of a keydown event whose identifier is the "Enter" key and that has a shift modifier set. Line separators are typically found within a poem verse or an address. To insert a line break, the user agent must insert a br element.

If the caret is positioned somewhere where phrasing content is not allowed (e.g. in an empty ol element), then the user agent must not insert the br element directly at the caret position. In such cases the behavior is UA-dependent, but user agents must not, in response to a request to insert a line separator, generate a DOM that is less conformant than the DOM prior to the request.

To conform this definition, it is safe to wrap the <br> element into <div>, which Chrome does, but it is UA dependent, so you should not rely on this. The side effect on this behavior and the cause of your problem is that both div and br elements produces line break in the innerText property.

The innerHTML of a↵↵b looks like this in Chrome:

a
<div>
  <br>
  <div>
    <br>
    <div>
      b
    </div>
  </div>
</div>

But if you paste it (instead of typing char by char) it looks like this

<div>a</div>
<div>
  <br>
</div>
<div>
  <br>
</div>
<div>b</div>

To reduce the line breaks, you need to further process the innerHTML and treat <div><br></div> after every input change as a single line-break and then read the innerText (with caution on places where phrasing content like br is not allowed, but in real life browsers can handle them well).

innerText on content editable doubling some line breaks

1 Answers1