Probably because touchscreen devices weren’t nearly as popular in 1995 as they are today, JavaScript DOM events tend to reflect the mouse ‘click’ paradigm, where each event neatly corresponds to a single, deliberate click of the button. Take the onClick event, for example. How does that translate to a touchscreen device? Not easily, as it turns out.

Treating a ‘tap’ as a ‘click’ is the practical approach. On iOS at least, there’s no onTap event – onClick has been repurposed for that role. But in order to properly handle multiple-touch gestures like pinching or even double-taps, some compromises have to be made. One of these is the roughly 300ms delay between a tap and the firing of a click event, which can make your apps feel laggy and unresponsive even when it’s not technically so.

The technique we use to get around this problem is to track all TouchStart events in our app and fire a click event as soon as we receive a TouchEnd event (unless some application-specific exception is satisfied).

As we refined our fast-clicking code, we turned it into a small and efficient library, which we call FastClick. This code has been tried and tested by hundreds of thousands of users, and so far has proved to be very robust. We’d love to know what others are doing to address this challenge and find ways of improving our own approach, and to help kick off that process, we’re open-sourcing FastClick today. We’d encourage you to try it out, and let us know what you think.

To use FastClick, instantiate it on the layer you’d like to be fast-clickable – we use document.body because we want all our buttons and links to receive fast clicks. In your event listeners, ‘click’ events synthesised by FastClick will have the forwardedTouchEvent property set to true.

If you use buttons and iOS-style menus in your app then there’s a good chance your interface feels unresponsive on touchscreen devices. Here’s a simple example of how we solve that problem for a single button by instantiating FastClick on it:

<button class=”fastclick” onclick=”someHandler()”>Fast click</button>
<button onclick=”someHandler()”>Slow click</button>
<script type='text/javascript'>
var button = document.querySelector(".fastclick");
new FastClick(button);
</script>

In the example, the button with a fastclick class will have its click handler called as soon as your finger is lifted off the screen, while tapping on any other buttons on the page will trigger the same handler after a noticeable delay. Try the live demo.

Unfortunately, the select element doesn’t behave normally when receiving (synthesised) programmatic clicks, so if you apply FastClick to an element that contains selects, FastClick will ignore clicks on the select and allow the normal click event to fire.

If you want any other elements (besides selects) in your FastClick layer to receive non-programmatic clicks, you’ll need to use one of two classes: clickevent or touchandclickevent. For any clickable element in a FastClick layer, tapping the element will cause different effects depending on how you use these classes:

• No class: The element will receive only a programmatic click from FastClick. The default click event triggered by the user will be suppressed.
• clickevent: The element will receive only the default click event, and will be ignored by FastClick
• touchandclickevent: The element will receive both the default click event AND a programmatic click from FastClick (the FastClick one will be triggered first). This is only safe if your handler’s action is idempotent.

Here’s an example of all three:

<div class="fastclick">
	<button onclick="someHandler()">
		Will receive programmatic click event
	</button>
	<button class="clickevent" onclick="someHandler()">
		Will receive non-programmatic click event
	</button>
	<button class="touchandclickevent" onclick="someHandler()">
		Will receive both click events
	</button>
</div>
<script type='text/javascript'>
var button = document.querySelector(".fastclick");
new FastClick(button);
</script>

When is this useful? Try the other live demo we’ve built using a click event handler that attempts to trigger focus on an input element. iOS will only allow focus to be triggered on other elements within a handler function if the event that triggered it was non-programmatic.

We’ll be posting updates and answering questions on this blog. If the interest reaches a stage where FastClick could benefit from the developer community, we’ll move to a public repository host. But for now, concentrate on giving your users the best response time they can get – download FastClick (or minified) and give it a go. Its free to use in all your apps, and licensed under the MIT license.

The details of how fragment navigation (also hash navigation or hash fragment navigation) works have been covered extensively by others, and have been abstracted into various frameworks and toolkits. A number are available for jQuery, such as:

• History
• BBQ (tutorial)
• Address

However, fragment navigation comes with a new set of challenges that we found ourselves having to address, so these will be the focus of this post.

Full page alternatives

Rather than changing all links to the form <a href="#!fragment/path/for/ajax">Link</a> and then detecting and acting upon fragment changes in javascript, we wanted to ensure that our links worked when they were copied and pasted into a new browser window, shared by email, or used with javascript disabled. This meant making them into real URL links, and then progressively enhancing using a Javascript onclick handler to cancel the normal navigation action:

<a href="/path/works/as/fragment/or/normal/page" class="fragnav">Link</a>

And some jQuery to hook the onclick handler on these fragment-navigation-compatible links, and convert them so that rather than navigating to the specified href, the browser changes it’s hash instead:

$("a.fragnav").click(function() {
  var href = this.href.replace(/^https?:\/\/[a-z0-9\.]+\/(.*\#\!)?/, '');
  location.hash = this.href;
  return false;
});

Now you can either click the link with javascript enabled and get a dynamic AJAX behaviour, or right click then ‘Open in new window’ (or click with javascript disabled) to get the full URL of the link to load normally.

Caching

When your user presses ‘back’, you can detect the fragment change and reload appropriate content – great. But this is not as good as what you get from browsers’ normal back button behaviour. Normally, the previous page is cached, so it reappears almost instantly. In the AJAX version, unless your fragment is just switching between different versions of content that are all preloaded, you may fire an AJAX request to load the content again.

It shouldn’t be necessary to reimplement caching yourself, since AJAX requests are subject to the same browser caching as normal page loads, but it’s easy to forget that you should include appropriate cache headers with your AJAX responses. There are four HTTP headers that generally modify a browser’s caching behaviour:

• Cache-Control (Docs)
• Expires (Docs)
• ETag (Docs)
• Last-Modified (Docs)

Cache-Control and Expires are cache directive headers, telling the browser whether and for how long it may cache the resource. Typically we set only Cache-Control, as it is more powerful and flexible, and Expires is generally unnecessary.

ETag and Last Modified are validators. These allow the browser to make a conditional request to the server to find out if the resource has changed, and allow the server to respond with a simple 304 Not Modified if it hasn’t. It’s often the case that your web server will add these automatically, and we prefer to avoid them entirely, relying on a single Cache-Control header to determine browser behaviour.

Cache-Control: max-age:60, public

A nice trick for content that is personalised to an authenticated user is to include the private directive in your Cache-Control header, which allows the page to be cached, but only by the browser, not by any proxies along the way.

Scroll position

One of the things we found to be most difficult was managing scroll position. Consider the default behaviour of a browser when navigating normally. If you scroll down a page and click a link somewhere near the bottom, the browser loads the new page and displays it starting at the top. However, if you then press the back button, it redisplays the last page you viewed and restores your scroll position for that page. You may not have even noticed this, but if it stopped behaving this way you’ get pretty annoyed soon enough!

So, if a user clicks one of your fragment links low down on your page, and the change you make to the page as a result would appear to the user to constitute a new page (obviously the point at which perception of ‘a new page’ is triggered is subjective), consider scrolling the browser window back to the top.

But, you should not do this if the back button is used, because the browser will restore the user’s previous scroll position all by itself. However, this becomes more complex if navigating forwards has considerably shortened the page content, and restoring the scroll position on back would require you to restore the content first in order for the necessary scroll offset to actually exist. This is a bit confusing. Here’s an illustration:

So the solution we use is to remember the scroll position on every navigation action, and then restore it after repopulating the content if it looks like a backwards step. You need to ensure you have got your caching rules right to support this otherwise the delay in refetching the content will make the browser reposition the scroll position twice – once by itself immediately, and again triggered by your JavaScript after the content has loaded.

Loading pause

Normally, the process of clicking a link and navigating to a new page involves the current page remaining on screen while the new page is being requested. The browser only blanks it out when content starts to arrive for the new page. The browser does provide some progress feedback immediately though, in the form of a wait mouse cursor or spinner in the browser chrome.

We aimed to replicate this experience for our AJAX-loaded views. This means avoiding what seems like an obvious solution – empty the container when the link is clicked, and populate it when the AJAX response is received – because you’ll get a flash of blankness between the old content disappearing and new content replacing it. Instead, the old content should remain, and the new content should simply replace it when the AJAX completes.

But this doesn’t provide progress feedback. The risk is, the user will think nothing’s happened and will click the link again. This tends to happen after about 2-3 seconds for most users, but AJAX calls normally don’t take anywhere near that long. So we implemented a timeout that, after 250ms, would blank out the container, replacing the old content with a loading spinner. If the AJAX completes within that time, it cancels the timer.

So, in most cases the user clicks a link and sees an almost immediate cut from old content to new with no flash of blankness. In some cases they see the old content vanish and a loading spinner to reassure them that something is happening while we wait for the new content to come back.

If you regularly have edge cases where content takes more than a few seconds to load, you should consider moving on to a different kind of progress feedback, to avoid hitting that “it hasn’t worked” perception boundary. The aim is to keep pushing that boundary back, keeping the user’s expectations in line with the performance that they’re getting from the site. I like to think of this like a timeline:

By providing better progress feedback, you can expand the ‘Expectation’ phase and avoid the ‘Frustration’ phase. However, it’s also equally important that you don’t display a big piece of progress feedback for the entire operation to then complete in under 250ms – the feedback will be on screen for such a short period that the user will potentially be unsure about what happened and get anxious. So be aware of the ‘instant’ phase, when you should present no feedback at all.

Inline Javascript

Sometimes, it’s convenient to get both new HTML code and new Javascript when your user clicks a fragment link. In our case, we wanted to set some Javascript globals in the response to allow javascript code already loaded on the page to better understand the content that had just been loaded. Say the user has requested a page with a fragment that loads some search results. We also want to tell the browser the search query that produced the results so that it can cache them, or populate the query into a search field that’s outside the fragment container, or something.

Normally, if you load content from a server using AJAX and append it to the DOM using innerHTML, any <script> sections in the HTML are not parsed by the browser’s JavaScript engine. However, to make it do this is as simple as searching the returned source for <script> sections, and evaling them. Make sure you properly filter and escape end user input before allowing it to be evaled though, otherwise you’re opening up your site to XSS attacks.

$('#main script').each(function() { eval(this.text); });

Command, Control and Shift modifier keys

Power users like to open links in new tabs or windows. In fact when faced with a list of links I often hold down Control and hit each link to turn to start preloading all the results into tabs which I can then review in turn without having to wait for each one to load. To avoid annoying users, you need to ensure that whereever possible, control-click (or command-click) and shift-click (normally ‘new tab’ and ‘new window’ respectively) still work.

It’s easy to get lulled into a false sense of security by right clicking on your links and using the context menu to select ‘Open in new tab’. This won’t run your onclick handler, so most likely will work if your link has a non-JavaScript href. But using the keyboard CTRL key while clicking the link will fire the onclick event, and if you are cancelling the normal link navigation action by returning false, you’ll also be cancelling the new tab or new window request. Ensuring that you don’t is quite straightforward (remember to include e.metaKey to detect the Command key on Macs):

if (e.shiftKey || e.ctrlKey || e.metaKey) return true;

Focus rectangles

In most browsers, when you click a link, you get a small dotted rectangle around it. This focus rectangle also appears if you tab through the actionable items on a page, to indicate which one would be followed if you pressed enter. The problem is that if your link fires an AJAX action, and the link itself remains on screen after the action has completed, you’re left with a focus rectangle that you probably don’t want.

A bad way of dealing with this is to simply use CSS to set outline:none on all A tags. This will certainly solve your problem, but kill all hope of keyboard navigation of your site. Better is to study the way that this interaction happens normally, and then mimic it for your Ajax actions. This is actually fairly easy to do generically:

(function() {

  // Keep track of which link element last had the focus (if browser does not support document.activeElement)
  if (!document.activeElement) {
    $("a").live('focus', function() {
      document.activeElement = this;
    });
  }

  // When any AJAX operation completes, blur any focused link
  $.ajaxSetup({complete:function(xhr, textStatus) {
    if (document.activeElement && document.activeElement.is('a')) document.activeElement.blur();
  }});
}());

Drop the above snippet into your javascript and you should find that focus rectangles still appear and stay visible while the ajax is running, but then vanish once it completes – perfect replica of the effect the user has learned to expect. If your links don’t perform any AJAX, you’ll have to deal with those separately.

Conclusion

With all this to think about, you’d be forgiven for concluding that AJAX navigation simply isn’t worth the bother. But bear with it – the benefits of being able to trivilally maintain state and load small fragments of content really makes a difference, both to the quality of the user experience and the load on your servers.

The logic for implementing native animations in the browser is a no-brainer, particularly if you try and use a site that implements scrolling tickers by incrementing an element’s left or margin-left properties every few milliseconds. Watch your interactions with the rest of the page slow down to a sluggish crawl and realise that animating the positioning of DOM elements in JavaScript can sometimes be pretty slow.

With animation increasingly important to creating rich and usable user interfaces, the chance to start optimising the performance of animation in the browser via native implementation is a great step forward. Unfortunately, this is currently only supported by Webkit based browsers. In developing the ticker, I wanted to see if support in Firefox would be possible.

From version 1.9.3 of Gecko, the -moz-transition family of CSS properties have been added, so I tried grabbing the latest version of Minefield (the pre-release codename for Firefox) and running the ticker plugin.

It doesn’t work. Specifically, it doesn’t work for these reasons:

1. It doesn’t seem to be possible to act on position properties. left, right, top and bottom do not appear to animate. It might be possible to work around this by switching to animating margins rather than absolute positioning, but hopefully it will be possible to animate these before the Firefox 3.7 release.
2. It doesn’t appear to fire the mozTransitionEnd event, which you’d expect from a full implementation of the standard. As a result, my ticker can’t loop.
3. It doesn’t seem to be possible to change animation properties (such as the duration) from JavaScript. I need this to disable animation while repositioning the ticker for the next loop.

This is clearly an early pre-release version, and it’s encouraging to see support starting to emerge from the Firefox camp. I think I might have retired by the time this kind of feature hits Internet Explorer!

In the process, I was pointed at the gorgeous Panic status board. Our objectives were similar and I was attracted to the idea of adding the scrolling tickers (at least, we assume they are scrolling from Panic’s photograph), which run along the bottom of their board. I was reminded of the kind of tickers you get on 24 hour news channels (here’s one from BBC World):

Tickers in web browsers are difficult for a number of reasons. First, continuously animating the left or margin-left properties of an element in JavaScript is computationally expensive, particularly if you want to reposition the element often enough to create a properly smooth animation. Sites that use Javascript for tickers in this manner tend to hog your computer’s CPU and feel slow and laggy as a result. Many sites give up on the traditional ticker and go for something that’s easier for the browser to animate, like a ‘type in’ reveal (eg the BBC News homepage ticker), or a vertical ’scroll up’ ticker.

Another issue with continuous tickers is making them loop properly. When your animation reaches the end of the text, you have to scroll it all the way off the left edge of the screen before it can be repositioned and re-enter the frame from the right. This leaves an ugly gap in your ticker.

Finally, if your ticker is updating with new information in real time, making changes that are noticeable in the visible portion of the ticker is amateur hour stuff.  You rarely see TV tickers suddenly change mid-scroll, and yet stories are seamlessly added and removed as necessary, outside of the visible frame.

Since Panic didn’t release any code (boo), I set out to produce a jQuery plugin that would enable news tickers to be easily added to a page, using CSS3 animation effects.  If it’s working for you, you should see a couple of tickers scrolling away right here:

If it’s not working, you’re probably not using a browser that supports CSS3 transitions.  Try it in Chrome, or Safari.  Support should be added to Firefox pretty soon.  But the objective here is not to get universal compatibility, since I can easily dictate which browser our status board will use.

With CSS3 transitions, we substantially improve the performance issue of tickers.  And this will improve further with browsers implementing these effects at an increasingly lower level.  This leaves the looping and updating issues to resolve before we can claim a properly news-grade ticker.

Looping

There are two possible solutions to the looping problem.  The first is to target segments of the ticker just after they have left the frame on the left, and move them to the end of the ticker on the right.  The second is to make several copies of your ticker content, and when you get to the end of the second copy, reposition the entire ticker element so that the first copy lines up with where the second copy had got to, then scroll on into the second copy again and repeat.

I chose the second approach, because you need several copies of the ticker anyway if it’s too short to fill the width of the frame with enough left over to sort the looping out.

Updates

In order to enable the ticker to be updated dynamically, and yet not suffer any noticeable changes in the visible portion, I added some public methods – addMessage() and removeMessage(), which allow you to pass a list element and have it queued for addition or removal at an appropriate moment.

This does require breaking a rather holy tenet of jQuery, namely returning a reference to the ticker rather than returning the jQuery chain, so you have an object on which you can call the public methods.

Every time the ticker hits the end of the text, it is repositioned with the penultimate copy in view, all copies of the ticker text are updated to match the copy to their right, and the final copy (the original set of elements) is updated with the queued additions and removals (out of view).   As a result, when you call the add or remove methods, you may have to wait some time before you see the effect, but the ticker will never judder or change while it is visible to the user.

How to use

Your ticker must be a block element containing a UL. This is because the ticker needs a frame to mask the content as it slides through.

<div id='ticker1'>
  <ul>
    <li>Headline one</li>
    <li>Headline two</li>
  </ul>
</div>
<script type="text/javascript">
  var ticker = $('#ticker1').ticker();
  var newid = ticker.addMsg('Headline three');
  setTimeout(function() {
    ticker.removeMsg(newid);
  }, 60000);
</script>

Settings and methods

The following settings are available, which can be passed to the ticker() function in a standard json object:

• pxpersec: Speed of the ticker in pixels per second (optional; default is 30)

Calls to the ticker() function return a reference to the ticker, not the jQuery chain. The ticker reference exposes the following methods:

• string addMsg(msg): Add a new message to the ticker. Can be a jQuery object or raw list item element (which will be moved from its current location in the DOM), or a plain text string. Returns a string identifier for the message (to enable you to remove it later). If you pass an element that already has an ID attribute, that ID is used (and returned).
• void removeMsg(msg): Remove a message from the ticker. Can be a jQuery object or raw list item element (which must be in the ticker already), or a string identifier returned from the addMsg call that added the message to the ticker. Returns nothing.

Get the code

• Download development (commented, 7KB)
• Download production (minified, 4KB)

Try scrolling either of the panels in this example:

You should find it scrolls madly and unpredictably until you press stop.

The first problem is that onscroll is not simply fired when you finish scrolling. It fires like a machine gun continuously while the mouse cursor is moving on the scroll handle. The solution to this is a watchdog. A watchdog is a timer that will execute action A if action B does not happen within X seconds. So every time onscroll fires, we reset the timer, and if it gets to zero we know that the user has finished scrolling (or at least has paused for long enough for us to do something about it).

You’ll find that although it’s not quite as crazed, the panels do keep scrolling, one after the other.

The problem now is that when you scroll DIV 1, and this causes an automatic scroll of DIV 2, that automatic scroll ALSO triggers the onscroll event and so we then scroll DIV 1 again. The solution is to have a variable that flags whether we are currently paying attention to scroll events, and turn it off when we don’t want to detect scrolling (ie just before the auto-scroll) and then on again after the scroll has completed (I’m using an animation library so the scroll takes around half a second to complete). Try this (don’t click the button yet, just scroll the panels):

Success. However, this approach is a bit short-sighted.

You also need to turn off scroll detection when adding or removing content from either DIV, because changing the height of the content within the element can also fire the onscroll event. So if this is a chat window, and we’re adding and removing content in the DIVs, we have to disable scroll detection while we’re doing that and then turn it on again afterwards.

Sadly, our scroll detection flag is crude – it’s a sheer yes/no, and if it’s already set to no (say in order to execute a lengthy scrolling animation), and in the meantime we need to do something quick (say adding a line to one of the DIVs) then that quick operation is going to disable scroll detection (unnecessarily, as it’s already disabled) and then crucially enable it again before the scroll animation has finished. Click the button in the example above to demonstrate this (and then scroll). You should, intermittently, get the unwanted cascade effect you saw in example 2.

What we need is a list, not a flag. Enter the blocker list – an object that collates tokens from each procedure in the script that is currently blocking scroll detection. So if a procedure wants to disable scrolling for a period of time, it adds its token to the blocker list, and then removes its token when it’s done. When a scroll event fires, we now only need to know whether there are any items in the blocker list, and then we can work out if it’s ok to process the event.

It’s also worth noting that there’s no need to actually count the number of items in the blocker list – it’s enough simply to know that there is at least one item in there. And as a further optimisation, we don’t actually need to compute this when scroll events fire (frequently), because the value will only change when some function wants to add or remove its token from the list (less frequent). So we can have enableScrollDetection and disableScrollDetection functions that deal with the blocker list, and which ultimately simply change the old scrolldetection flag to true or false.

There might be a neater way of achieving this, but this certainly works for me. I’d welcome any comments or suggestions. The sources for all these demos are available in the iframes above.

But this was clearly not my problem, and various sources suggested that this had in any case been fixed for Firefox 3. I discovered that my problem was rather simpler. If you disable an element that has focus, and then re-enable it, you don’t get the cursor back.

Solution: blur (remove focus from) the element before you disable it. Those sources that do refer to this specific problem tend to suggest that you focus a different element before you disable the text box. But this is not necessary – you can just blur the element that has focus and leave the page with nothing focused.

Problem test case

Try clicking and typing in the field below – if your browser exhibits this problem, the text cursor will not appear. If it does, then your browser does not have this problem.

This demo has a single text field which, when you click into it, is briefly disabled, and then enabled again. The disabling of the field while it has focus triggers this problem, so the text cursor does not appear (but you can still type into the field!).

Solution test case

Now try typing in this field – the cursor should appear consistently.

This demo still briefly disables and re-enables the text field when it gets focus, but this time it blurs it right before it’s disabled, then focuses it again after re-enabling it. The result is that when you place your mouse cursor in the field to manually give it focus, the text cursor appears as normal.

Recently I needed to use this method to serialise some data in a JavaScript library that might be used in ‘foreign’ web pages. My own library was nicely encapsulated, and didn’t interfere with any other JavaScript that might be running on the page, and it included Douglas Crockford’s JSON2.js implementation.

But on one of our clients’ sites, it didn’t work. I got this:

{"key":"val",[\{\"key\":\"val\"\},\{\"key\":\"val\"\}]}

What’s happened here is that any arrays in my data structure have been stringified twice. This didn’t happen in my dev environment. I narrowed down the differences and realised what was causing this effect. They’re using Prototype. We’re not.

Prototype modifies a number of JavaScript’s native objects, including the Array object, and… you guessed it, adds a toJSON() method to it. Unfortunately it does not return what Crockford’s JSON implementation is expecting. From the docs for json2:

A toJSON method does not serialize: it returns the value represented by the name/value pair that should be serialized, or undefined if nothing should be serialized.

Prototype’s toJSON() is serialising. There don’t seem to be any sensible solutions to this online, but it’s actually relatively simple to solve using a replacer function, allowed for in the json2 API:

var reqdata = JSON.stringify(req, function(key, value) {
	if (typeof this[key] == 'object' && Object.prototype.toString.apply(this[key]) === '[object Array]') {
		return this[key];
	} else {
		return value;
	}
});

Essentially this says ‘for each key in the data structure, if the value is an array, use the raw value, otherwise use the value you gave me’. This makes sense when you look at the sequence of steps that stringify() goes through for each key it encounters:

1. If the value has a toJSON() method, call it.
2. If a replacer function has been given, call it.
3. If the remaining value is a scalar, return it.
4. If the remaining value is an object, stringify each member, then concatenate keys and values within braces {key:val,key:val}
5. If the remaining value is an array, stringify each element, then concatenate values within brackets [val,val,val]

So, stringify() has already called Prototype’s toJSON() method by the time it executes the replacer function, but we can use the replacer function to restore the original value, allowing stringify() to then deal with the array by calling itself recursively.

The result is that we can ensure that even if a toJSON() method does exist on the Array object, its output is ignored, and we then get the JSON string that we wanted. ]]> http://assanka.net/content/tech/2009/09/02/json2-js-vs-prototype/feed/ 2 http://assanka.net/content/tech/2009/05/04/auto-growing-textareas/ http://assanka.net/content/tech/2009/05/04/auto-growing-textareas/#comments Mon, 04 May 2009 16:24:52 +0000 Andrew Betts http://assanka.net/content/tech/?p=3 This feels like a topic that’s been explored to death already, but I really don’t like most implementations of this technique, so here’s how we do it.

First, in case anyone has just arrived from Mars, or even more unlikely, isn’t familiar with Facebook, the auto-growing textarea is a text box that gets bigger as you type into it, so that you never see a scroll bar (unless you’re typing war and peace).

There are lots of ways of doing each part of this. The parts I’ll look at are (a) what triggers a review of the text box’s size, (b) how to determine whether a resize is required, and (c) how to perform a resize.

Triggering a review

There are four ways this is typically done:

1. On an interval, say every 50ms
2. On keypress
3. On change
4. On keyup

I’m staggered by how many scripts insist on doing this kind of thing on an interval. Setting up interval timers for no good reason is a shortcut to terrible performance and memory leaks galore. So we won’t be doing that. onkeypress and onchange events are triggered before the box is updated with the latest keypress, so we want to avoid those, as the latest keypress might have been the one to bring us onto a new line. That leaves onkeyup, which is fired after the box is updated with the new character, and allows us to inspect it and decide whether to increase its size.

To resize or not to resize

How to determine whether to resize the box comes in three flavours:

1. Count the number of newline characters in the textarea’s value, and see if that matches the number of rows the textarea has.
2. Create a ’shadow’ DIV which is off screen (eg. margin-left: -10000px) and has no height declared, but otherwise has the same style properties as the textarea, fill it with the textarea’s content, measure the subsequent height of the DIV, then see if that height matches the current height of the textarea.
3. Check whether scrollHeight (the height of the scollable content of the box) > clientHeight (the height of the box itself).

In this case I was suprised at the number of implementations that favoured counting newlines. This only works if combined with counting the number of characters in the textarea’s value, AND a monospaced font, AND knowing the number of columns in the textarea. In short, er, it’s mad.

Second option, and the one favoured by a lot of the framework plugins due to the ease with which you can create shadow elements in the likes of jQuery, is to create a shadow DIV. This has the advantage of telling you the actual pixel height of the text, even where it is LESS than the height of the textarea box. Otherwise, you’re limited to measuring clientHeight and scrollHeight, which are exactly the same if the textarea isn’t scrolling, regardless of how much space you’ve got to spare at the bottom. My issue with this method is that it basically requires use of a framework to not be painful, and even then it’s non-trivial amounts of code, and adds needless pollution to the DOM.

So that leaves relying on scrollHeight and clientHeight. These are well supported and efficient to read, so provided that you work around the issue of scrollHeight always being at least equal to clientHeight, this offers a very lightweight solution. The features that you can achieve with a shadow DIV that you can’t do by simply reading scrollHeight and clientHeight are (a) you can ensure there is always a blank line at the bottom of your textarea, and (b) you can shrink the textarea if the user deletes text from it. I’m personally of the view that neither of these is actually particularly desirable. There’s potentially an argument for leaving a blank line at the bottom, but equally the uer might feel like they’re just being pressured to write more.

How to resize the box

OK, so if you’ve concluded that the user is writing chapter and verse and the textarea is in need of a bit more space, how do we go about doing it?

1. Animate the CSS height property
2. Add some height via the CSS height property
3. Add 1 to the rows attribute

A fair few of the framework plugins use their framework’s animation capabilities to animate the grow effect. I don’t like this. Just because you have an animation effect available doesn’t mean it’s appropriate to use it, and there are many situations where the end user just doesn’t want to wait 300ms for the privilege of using a fresh line.

Simply adding height to the CSS property is a fair way of doing it, but unless you do some maths on the user’s line height (or hard code some magic numbers), you can’t necessarily guarantee that the resulting height will be a multiple of the textarea’s line height.

Easiest, most efficient solution: add one to the rows attribute of the textarea. rows is part of XHTML as well as HTML 4.01, and has universal support going back yonks.

Pasting

Watch out for pastes. If the user pastes in a large quantity of text, they will trigger only one keyup event, but will have added many lines to the textarea. Make sure that if a resize is required, you trigger another review after the resize is complete.

Max height: the war and peace scenario

If the user really does seem to be writing a novel, we probably should call it a day on growing the textarea at some stage, and certainly before it gets to be taller than the viewport. You can check the height against the viewport height, though I typically just restrict it to an arbitrary height, say 30 rows.

The code

You’ll need a textarea element with an ID of mytextarea to make this code sample work, and obviously you can easily modify it to use selectors from your favourite framework rather than the native document.getElementById.

document.getElementById('mytextarea').onkeyup = function() {
	var ta = document.getElementById('mytextarea');
	var maxrows = 30;
	var lh = ta.clientHeight / ta.rows;
	while (ta.scrollHeight > ta.clientHeight && !window.opera && ta.rows < maxrows) {
		ta.style.overflow = 'hidden';
		ta.rows += 1;
	}
	if (ta.scrollHeight > ta.clientHeight) ta.style.overflow = 'auto';
}