{"id":109,"date":"2008-11-15T14:33:26","date_gmt":"2008-11-15T19:33:26","guid":{"rendered":"http:\/\/osric.com\/chris\/accidental-developer\/?p=109"},"modified":"2008-11-15T20:15:20","modified_gmt":"2008-11-16T01:15:20","slug":"javascript-textarea-counter","status":"publish","type":"post","link":"https:\/\/osric.com\/chris\/accidental-developer\/2008\/11\/javascript-textarea-counter\/","title":{"rendered":"Javascript textarea counter"},"content":{"rendered":"

I’ve been thinking more about the textarea counter issue that I mentioned in my previous post (“Users Paste Differently<\/a>“).<\/p>\n

First of all, I noticed that some of the textarea counter scripts date back to at least 2000, so this has been a problem that developers have been looking to solve for 8 years. I checked the HTML 5 specification<\/a> and found that in HTML 5, the textarea element has a maxlength attribute<\/a>. Presumably user agents will build in the most elegant solution.<\/p>\n

But what is the current most elegant solution?
\nI checked a couple sites that I know use textarea counters well: Delicious<\/a> and Twitter<\/a>.<\/p>\n

Delicious<\/strong>
\n

\"Textarea<\/a>
Textarea counters on Delicious.com<\/figcaption><\/figure><\/p>\n

Twitter<\/strong>
\n

\"Textarea<\/a>
Textarea counters on Twitter.com<\/figcaption><\/figure><\/p>\n

I like how prominent the character count is in Twitter, although perhaps too terse, but if Javascript is disabled it displays nothing at all. On the other hand, in Delicious displays “1000 characters max” if Javascript is off (instead of “1000 characters left”), which is still useful information. (I would avoid using the abbreviation max<\/em>, though, and use maximum<\/em> or limit<\/em> instead, which might be better understood by those for whom English is a second language.)<\/p>\n

I like Twitter’s “warning track” that lets the user know they need to keep it concise and wrap it up, although I find it confusing that they used bright red to denote both the “dangerously close to” as well as “over” the limit. The positive bright red numbers could easily be misconstrued as over the limit, since red is a color we frequently use to denote errors.<\/p>\n

Twitter’s counter responds to onBlur and onChange, whereas the counter in Delicious is triggered by neither.<\/p>\n

Both get one thing right that I think most other textarea counters get wrong: they don’t truncate the user’s text. Deleting something that the user has typed (or pasted) is definitely a bad idea for at least two reasons: the user may not realize the input was truncated and may submit incomplete info, and that the user, upon discovering that the input requires editing, may choose to cut text from someplace other than the end. Instead, both versions alert the user that they are over the limit and provide information on how many characters need to be cut to stay within the limit.<\/p>\n

(As an aside, one thing I find curious is that both count an Enter<\/em> keystroke as one character. I’ve run into issues with this before because a line break on a Windows-based system should insert 2 ASCII characters: a Carriage Return (CR) and a Line Feed (LF). *nix systems, including OS X, will insert a Line Feed (LF). However, I haven’t been able to reproduce this issue with recent testing. If it is still an issue, I imagine they handle this on the back-end by converting the CRLF to LF before inserting it into the database?)<\/p>\n

In short, my recommendations are:<\/p>\n