3

I tested this code in Chrome and there seems to be a bug involving the newlines. I am reaching the maxlength before I actually use all the characters.

var ta = document.getElementById('myText');

document.getElementById('max').innerHTML = ta.maxLength;

setInterval(function() {
    document.getElementById('count').innerHTML = ta.value.length;
}, 250);
<textarea id="myText" maxlength="200" style="width:70%;height:130px">
Lorem Ipsum is simply dummy text of the printing and typesetting industry.
Lorem Ipsum has been the industry's standard dummy text ever since the 1500s
Type more words here...
</textarea>

<div>
    Char Count <span id="count">0</span>/<span id="max">0</span>
</div>

How can I accurately get the char count of a textarea?

Update 1 I reported the bug to the Chromium team and it seems to be low priority.

Update 2 That bug was merged into another bug.

Update 3 The bug appears to be fixed!

styfle
  • 22,361
  • 27
  • 86
  • 128
  • Roll your own `maxlength` property instead of using the browser's. – Waleed Khan Oct 16 '12 at 22:45
  • 1
    So do you want the newlines counted or not? And rather than polling with `setInterval`, use `keyup` or `keypress` as appropriate. – RobG Oct 16 '12 at 22:55

1 Answers1

1

Seems to be a WebKit bug (consider filing it) related to treating CR/LF pair as two characters instead of one. Since it's usually noncritical if, say, 197 characters are allowed instead of 200, it's fine to ignore this.

But if you want, you can try to continuously save caret position, replace all \r\n to \n, and restore caret position in textarea while user is typing.

Marat Tanalin
  • 13,927
  • 1
  • 36
  • 52
  • I don't see that "bug" in either Chrome or Safari on Mac OS, I get exactly the same results as Firefox. There is a difference with certain word processors that don't count new line or line feed characters as characters, which likely is a result of their different view of the world. IE, on the other hand, inserts a linefeed and carriage return so counts new lines as two characters and has done so for a long time. – RobG Oct 16 '12 at 23:09
  • It is a big problem if your maxlength is 50000 and this counter is maxing out at 49000. – styfle Oct 16 '12 at 23:10
  • @RobG: I'm on Windows, are you? – styfle Oct 16 '12 at 23:10
  • IE 6 was tested on Windows, the others on Mac OS. Firefox is consistent on Windows and Mac OS (only inserts a single new line). – RobG Oct 16 '12 at 23:15
  • 1
    @RobG: Unlike Windows (where line feed consists of 2 characters: CR+LF, `\r\n`), line feed on Mac OS consists of one character (carriage return, CR, `\r`), so `\r` and `\n` have same length — 1, and it is logical to expect that the issue is not reproduced on Mac OS. IE6 is irrelevant here since support for HTML5 validation is just added in IE10 (and, BTW, works correctly, unlike Chrome). – Marat Tanalin Oct 16 '12 at 23:16
  • So it's not a bug in WebKit. If there are two characters, shouldn't two be counted? [*maxlength*](http://www.w3.org/TR/html4/interact/forms.html#adef-maxlength) in HTML 4 applied to text input elements only. HTML5 is confusing, the section for [maxlength](http://dev.w3.org/html5/spec/single-page.html#attr-input-maxlength) says it's for input elements, the section in [common form controls](http://dev.w3.org/html5/spec/single-page.html#attr-input-maxlength) applies it more generally. Must make copy and paste between browser and other apps a pain. – RobG Oct 17 '12 at 01:48
  • It sounds like the textarea needs to be standardized. It shouldn't matter what OS. Why would a Unix user be able to type more than a Windows user? Not to mention `maxlength` should be using the characters reported in the textarea. – styfle Oct 18 '12 at 17:12
  • I'm marking this as the correct answer but I don't think it is a Webkit bug since Safari on Windows does not have the same issue. – styfle Oct 30 '12 at 23:41
  • The essense is that the issue is a browser bug. It this is not a WebKit bug, then this is a Chromium [bug](http://code.google.com/p/chromium/issues/detail?id=158652). ;-) – Marat Tanalin Oct 31 '12 at 08:21