FAHNZ

MODE

JavaScript (jQuery) Text Resizer

First off, let it be known that I think that JavaScript-based text resizers suck. I firmly believe that the text size should be controlled by the user via the web browser controls. I’ve found that most clients want a JS-based text resizer because they think that it will make their website more accessible when, ironically, these types of resizers are not accessible by nature (since they require JS to work).

So, having seen poor implementations of this functionality in the past, I had a few requirements that I wanted my version of the text resizer to meet:

  1. Must be accessible or not be available at all.
    In other words, if it’s going to be non-usable or broken, then don’t even display it. There’s nothing worse to me that having something on a page that requires JavaScript to work, but doesn’t do anything at all to account for when a user does not have JavaScript. Especially when there is an incredibly easy way of addressing this (see below).
  2. Must account for the initial font-size and allow the user to return to that size
    The design mock-up that I received for this project showed that the text size controls would be a series of three letter “A” links, each larger than the previous. I decided that it made sense to make the smallest “A” represent the initial font-size. The subsequent links would add the ability for “bigger” and “biggest”.
  3. Must persist across page views
    I have seen many, many implementations of this that don’t even persist from one page to the next. That has got to be annoying if you’re really trying to use this feature.
  4. Must work on only specified areas of the design (as opposed to the whole page)
    This requirement was from the client and – in my opinion – is the closest thing to a good reason for implementing this type of functionality.

So, the first item on my list was “Must be accessible or not available at all” and was nice ‘n easy to implement. Simple solution that I’ve used in the past is to render the JavaScript-requiring-component with JS. If the user has JS, then JS will make the component available. If not, then it will never even be rendered. Simple! Now, I realize that this could be made to work server-side using AJAX or postbacks, but that was out of the scope of this particular project (not to mention getting to the point of needing to argue the downfalls of doing it this way to the client).

The third and forth items on my list were also easy. To get this to work only on specified areas of a page, I would make it work on only those elements that have a specific CSS class applied to them. To get it to work from page to page, I’d just store the requested size in a cookie. Easy-peasy!

What I found to be the most problematic once I got into this was accounting for the initial font-size when the page is first requested. I have my default font-size set in the CSS as 0.76em (which is around 12px). Using jQuery, most browsers would return the correct value in pixel units (12 point something), but – ever the oddball – Internet Explorer 7 would return some bizarre value in the vicinity of 600-or-so pixels. Needless to say, that ended up being a bit too big when the text was resized. So, researching on the ‘net showed be that this is a common problem and I didn’t come across a good, simple solution. The primary solution I came across involved measuring the height of a hidden div to get the font height pixels so that everything could then be rendered with pixel font sizes. So there was a lot of discussion out there of how to find out what the current pixel size is of the font.

The pixel size of the font seemed dangerous and irrelevant to me. Potentially dangerous since pixel sizes don’t scale well in early versions of IE (I know, I know, I have ridiculous – but oftentimes necessary – browser compatibility requirements). Irrelevant since I really don’t care what specific font size is shown initially since the user will just be wanting to make the font size “bigger” or “biggest”. All I care about is that the font size is bigger relative to the initial font size. After pondering and experimenting, I came up with the following solution: upon the font resize function, add an inner HTML element to the area being resized, then add a percentage value to that element to resize the text.

I’m sure there’s room for improvement and added flexibility, but it seems to be working out pretty well so far. Code below:

HTML:

Text Size:
  <a href="javascript:ResizeText(1);">A</a>
  <a href="javascript:ResizeText(1.2);">A</a>
  <a href="javascript:ResizeText(1.6);">A</a>

<div>
  <p>This is text that will get resized.</p>
</div>

JavaScript (using jQuery):

// Global Variables
var fontSizeArea = ".body-outer"; // use 'html' for entire page
var textResizeCookie = "textResizeFactor";
var originalFontSize;

// Initialization Function
$(document).ready(function() {
  $(".text-sizer").show();

  originalFontSize = $(fontSizeArea).css("font-size"); // remember the original font size
  if (originalFontSize == null) { originalFontSize = $("html").css("font-size"); }

  var savedResizeFactor = $.cookie(textResizeCookie);
  var resizeFactor;

  if (savedResizeFactor == null) {
    resizeFactor = 1;
  }
  else {
    resizeFactor = parseFloat($.cookie(textResizeCookie));
  }

  if (resizeFactor != 1) {
    ResizeText(resizeFactor);
  }
});

// Resize Text Function
function ResizeText(resizeFactor) {
  var wrapperClassName = "g-fs-wrapper"; // global font-size wrapper
  var newFontSize = (100 * resizeFactor) + "%";

  if ($("."+wrapperClassName).length > 0) {
    $("." + wrapperClassName).css("font-size", newFontSize);
  }
  else {
    $(fontSizeArea).wrapInner('<div class="' + wrapperClassName + '" style="font-size:' + newFontSize + '"></div>');
  }

  $.cookie(textResizeCookie, resizeFactor); // remember the new size
}

Comments are closed.