character counter in web interface

Mar 10, 2006 16:55


Title
character counter in web interface

Short, concise description of the idea
Create a character counter embedded in the update-journal page, so that one could see how many characters remain available as one types an entry.

Full description of the ideaI recently discovered the hard way that posts have a size limit of 65,535 characters or bytes. ( Read more... )

entry editor, user interface, § rejected, data limitations

Leave a comment

afuna March 15 2006, 02:22:44 UTC
Back in July, I tried writing a greasemonkey script along these lines once. I don't have much experience so I don't know whether all implementations will suffer from the problems I ran into, but in short:

a.) Updating it for every character you type eats up a lot of system resources. I didn't have much problem on the desktop (Windows) but it caused major stuttering when I transferred it over to my laptop (Mac).

If it makes any difference, the event handlers I uesd include
were "keyup", "keydown", and "change".

At one point I experimented with "focus", "blur" "scroll", and "select" but I removed them.

b.) In Firefox ( I don't know about other browsers), the focus tends to jump around when you have a scrollbar.

Bug #1: Once you've scrolled down vertically past a certain point, it will keep moving itself up a couple of lines.
Way around it: Hit enter twice so that you have two blank lines at the bottom of your comment, then go up and keep typing from where you left off.

Bug #2: On really long lines of horizontal text -- those that make a horizontal scrollbar show up, you have to use the scrollbar to see what's on the right. If you just keep typing, the focus will "jump" to the left, though you can keep typing to the right. As far as I can tell, the problem happens when you reach the last word of the line and the textbox hasn't decided yet whether the word should be on the next line or not.

I managed to make things less jerky by not tracking the "select" handler, but the scrolling bug was always there, though to a lesser degree. I am pretty sure it has something to do with the event handler, and I think I managed to Google up a solution but I never implemented it because GM and LJ both changed and I wasn't attached enough to it to try to make it work.

--
I like the idea a lot, but I think it would be impractical to update it as the user types because of both the problems I gave above (side note: a resourceful programmer could probably find a way around the second, but I don't know if anyone can do anything about the first and still have it update while the user types).

For the first, either give it a time out along the same lines as the autosave of the draft, or update it only when the user clicks out of the textarea, or update it only when the user clicks on a word count button/link or something.

Reply


Leave a comment

Up