In the end I found four different ways of doing it, each with different levels of support: from the cleanest approach that only worked in one browser, to the most robust that works in everything back to IE6.

All of them work on the same core principal; black borders for shade and white borders for highlighting are overlaid on top of an image, and then blended with some form of opacity. In each case, browsers without support for that technique will simply show the image as normal.

Technique 1: Using Generated Content on the Image (Demo)

• Pros: Ultra-clean technique requires no additional markup
• Cons: Only works in Opera

With this first technique we create a pseudo-element using :after, then style it to be perfectly overlaid on top of the image. Then we add borders to the overlaid element, and use RGBA to define each border color: the top and left borders are rgba(255,255,255,0.4), white with 40% opacity; and the bottom and right borders are rgba(0,0,0,0.4), black with 40% opacity:

img.beveled
{
    position:relative;
}
img.beveled:after
{
    position:absolute;
    left:0;
    top:0;
    display:block;
    content:"\00a0";
    box-sizing:border-box;
    width:100%;
    height:100%;
    border:5px solid;
    border-color:rgba(255,255,255,0.4)
                 rgba(0,0,0,0.4)
                 rgba(0,0,0,0.4)
                 rgba(255,255,255,0.4);
}

<img class="beveled" src="stormtroopers.jpg"
     alt="A legion of Lego Stormtroopers, standing in formation." />

This technique only works in Opera because no other browser supports generated content on multimedia replacement elements like <img> and <object>. But since we’re only addressing Opera, we have the freedom to use box-sizing and 100% dimensions, rather than having to define the dimensions explicitly.

(Note: the value of the content property in all these examples is a unicode non-breaking space. This is added because pseudo-elements have to contain something or they’re not rendered.)

Technique 2: Using Generated Content on a Wrapper Element (Demo)

• Pros: Wider range of supported browsers
• Cons: Requires additional markup and explicit dimensions

The second technique is essentially the same as the first, but this time we create the overlay element using generated content on a wrapper <span> for browsers that don’t support generated content on the <img> itself. For this technique we also need to begin defining explicit dimensions on the wrapper element and the generated content (although we could use vendor-specific versions of box-sizing on the generated content, we’d still have to define the dimensions of the wrapper, so we may as well do the same for both):

span.beveled
{
    position:relative;
    width:200px;
    height:200px;
    display:block;
}
span.beveled:after
{
    position:absolute;
    left:0;
    top:0;
    display:block;
    content:"\00a0";
    width:190px;
    height:190px;
    border:5px solid;
    border-color:rgba(255,255,255,0.4)
                 rgba(0,0,0,0.4)
                 rgba(0,0,0,0.4)
                 rgba(255,255,255,0.4);
}

<span class="beveled">
    <img src="stormtroopers.jpg"
         alt="A legion of Lego Stormtroopers, standing in formation." />
</span>

Technique 3: Using Shadows instead of Borders (Demo)

• Pros: The most visually attractive technique
• Cons: Only works in Firefox 3.5 or later

The third technique is a diversion from the second, where instead of using RGBA borders we’re using -moz-box-shadow:inset to create the beveling effect. Since box shadow effects have an alpha gradient (rather than the same opacity at all points), the overall effect is much prettier and more rounded; and the spread radius parameter can be subtly used to blend away the corner sharpness.

This effect is only supported in Firefox 3.5 or later; although Safari does implement box-shadow (as -webkit-box-shadow), there’s no support for inset:

span.beveled
{
    position:relative;
    width:200px;
    height:200px;
    display:block;
}
span.beveled:after
{
    position:absolute;
    left:0;
    top:0;
    display:block;
    content:"\00a0";
    width:200px;
    height:200px;
    -moz-box-shadow:-5px -5px 2px rgba(0,0,0,0.4) inset,
                    5px 5px 2px rgba(255,255,255,0.4) inset;
}

<span class="beveled">
    <img src="stormtroopers.jpg"
         alt="A legion of Lego Stormtroopers, standing in formation." />
</span>

I suppose we could have added a -webkit version anyway, in the hope of forward compatibility, but that would be a risk since we can’t know what any future implementation will be like — it might be worse than nothing!

Technique 4: Everybody’s Happy (Demo)

• Pros: Works in all modern browsers
• Cons: Requires more additional markup and explicit dimensions

The fourth and final technique is the most cross-browser compatible, but also requires the most HTML modification. It’s essentially the same as the second technique, but with two important differences: firstly, it uses a second physical <span> rather than generated content; and secondly, it uses ordinary hex border colors rather than RGBA, and then blends the whole element with opacity. Even Internet Explorer can handle this:

span.beveled
{
    position:relative;
    width:200px;
    height:200px;
    display:block;
}
span.beveled span
{
    position:absolute;
    left:0;
    top:0;
    display:block;
    width:190px;
    height:190px;
    border:5px solid;
    border-color:#fff #000 #000 #fff;
    filter:alpha(opacity=40);
    opacity:0.4;
}

<span class="beveled">
    <img src="stormtroopers.jpg"
         alt="A legion of Lego Stormtroopers, standing in formation." />
    <span></span>
</span>

Further Development

You could take this further by using colorful borders for a gel-like effect, or even multiple staggered overlays to create effects that are more subtle or intricate.

But the basic idea is here, and I hope you find it useful. It’s certainly been great fun to play with!

Related posts:

1. The Two Ways of Sizing Absolute Elements in CSS Most developers have used left, right, top and bottom properties...
2. How To Create A Cool Halftone Effect With Text & Images In Photoshop Jennifer demonstrates how to create the retro print effect of...
3. Censor Your Images With A Mosaic In Photoshop Jennifer shows you how to apply a pixelated mosaic effect...

Well it’s actually quite simple. First of all, both methods expect a thisArg as the first argument. This is the argument that gives the function a context; it determines the value of the JavaScript keyword this inside the function that is called or applied. The single difference is that the call method requires that arguments are specified separately; the apply method takes them as an array. It’s clearer if you see the syntax:

function.call(thisArg[, argument1[, argument2[, ...]]]);

function.apply(thisArg[, argumentArray]);

So if you’re working with the arguments object in your JavaScript, you can call any function by using the apply method and simply pass in the existing arguments object as the array argument.

Hope that’s useful to you!

Feature image by Sudhamshu. Can you work out the significance?

Related posts:

1. Cross-browser JSON Serialization in JavaScript JSON serialization can be incredibly useful, but few browsers support...
2. Getty Images Call For Artists On Flickr Getty Images are making a formal call for artists through...
3. The Pareto Principle: Does the 80/20 Rule Apply to Your Life? The 80/20 Rule states that 80% of the output comes...

The Problem

Most web designers rely largely on a set of free, widely distributed fonts for much of their site’s text content. Yet, no matter how widely available a font is, there’s still a chance it will be absent from a given visitor’s system. Fortunately, CSS lets us specify a stack of fonts to use in case the preferred font is missing. By specifying three or four fonts in this manner, followed by a generic catch-all serif or sans-serif, we ensure that our content is displayed in a font that at least resembles the one we wanted. In theory that’s great, but if the appearance of the site isn’t tested with each of the potential fallback fonts, problems can arise. For example, when viewing the PharmQD website on my home machine (running Ubuntu Linux), I see the following:

As you can see, the titles break onto an extra line, which was clearly not anticipated by the designers when they were putting together the layout. Why? Because the font stack used for these titles is Tahoma, Verdana, Arial, Helvetica, sans-serif;, and Tahoma is significantly narrower (at the same font size and weight) than Verdana or Arial. So when viewed on a system without Tahoma, the fallback font is used, and since all the fallbacks are wider, the text takes up more space than was anticipated in the design. Here’s what the design was intended to look like, this time viewed on my work machine, running OS X:

Tahoma isn’t the only font vulnerable to this kind of breakdown. Microsoft’s Vista fonts (Calibri, Cambria, Candara, and Constantia) are significantly smaller than most others fonts at the same point size, so using any of these in a stack can result in similar issues.

Testing Tools

Strangely enough, despite the wealth of testing tools available for web developers, there’s no simple answer for testing font stacks. One less-than-ideal solution is to use Firebug to manually edit the font-family declarations associated with the parts of the page that are highly dependent on font size: buttons, navigation items, headings, and so on.

A quick Google search also revealed this promising-looking project on Github: Font Stack Tester, by Robert Lee-Cann. It’s a jQuery script that adds an overlay at the top of a page with buttons to disable any of the fonts found on the page. The developer wants to eventually turn it into a bookmarklet, but at the moment it’s definitely in its infancy.

Update: In the few days since I originally posted this, an enterprising individual has registered http://fontstacktester.com/ and put up a hosted version of that GitHub project. Just enter your site URL, and it will take you there, adding a bar along the top that you can use to disable fonts one by one to test how your stacks hold up. Kudos to Chris for the speed with which this was developed!

No matter how you go about it, font stack testing should definitely not be neglected: when something breaks as badly as the example above, it can really damage that visitor’s impression of your site.

Related posts:

1. IKEA and the Font Fiasco IKEA have recently changed their font from Futura to Verdana,...
2. The Sans Serif Typeface Continuing our ongoing series on Typefaces, Jennifer takes a look...
3. Serif Fonts Vs. Sans Serif Fonts: A Working Case Study Sans serif fonts are the norm for web sites, but...

jQTouch is described on the site as a jQuery plugin for web development on the iPhone and iPod Touch. But it’s more than just a plugin; its simplified development approach helps you create and theme the various screens of your web app and apply animated transitions between them.

It will help in all manner of ways, but app development using jQTouch is quick if you follow a simple recipe. You create a series of div elements (one for each screen in your application), give each one an id, and give the home screen the class of current. You then place an unordered list within the home screen div. In each list item you place an anchor tag with a href that links to one of the other divs.

With just that simple recipe jQTouch will hide all the divs except the home screen, and render your list with attractive gradients as the main menu. It’ll also wire up the tap action so that a tap on one of the list items will make the home screen slide off and the linked div element slide on. This is very similar to the style of the default menus.

It’s definitely worth checking out. Campaign Monitor revealed recently that they used jQTouch on their recent iPhone app, and there’s a demo on the jQTouch site that’ll also work in desktop Safari.

With RIM announcing that it’s developed a WebKit-based browser for BlackBerry devices, it’s probably not a stretch to imagine this library could eventually be used to develop for iPhone, iPod Touch, Android, and Blackberry.

Related posts:

1. UI Stencil Kit for iPhone App Designers iPhone interface design is über-cool right now, as is hand...
2. 7 Reasons Why Developers are Deserting iPhone Apps Are developers being enticed away from bespoke mobile application development...
3. 40 Essential iPhone Applications For Web Designers With an iPhone or iPod Touch, web designers can finally...

Although jQuery compresses to under 70Kb, the uncompressed file comprises 6,000 lines of JavaScript code. Your text editor or IDE may offer a function list, but there are dozens of methods to wade through and it’s not always easy to find the code block you need. Fortunately, UK web developer James Padolsey has come up with a neat solution — the jQuery source viewer.

The tool will find the code for any function name you enter (note that names are case-sensitive). By default, it will return version 1.4 code, but versions 1.3.2 and 1.2.6 are also available.

Other jQuery methods are highlighted and click-able so it’s easy to jump to other code blocks. You can also find functions from the URL, e.g.

• http://james.padolsey.com/jquery/css
  shows the css method for the latest version of jQuery supported (1.4)
• http://james.padolsey.com/jquery/1.3.2/attr
  shows the attr method for jQuery version 1.3.2

The tool’s a fantastic idea and will certainly save time when hunting through the jQuery source. Thanks James. My only request: a case-insensitive auto-suggest box would make it absolutely perfect.

Related posts:

1. How To Develop a jQuery Plugin Creating a jQuery plugin is easier than you might think....
2. Make Your Own Web Site Badges with jQuery and JSON Now that most social media sites offer a JSON API,...
3. jQuery 1.4 Released jQuery 1.4 has been released. Craig looks at the new...

Let’s pretend that we want to create an image gallery. Doing our best at honoring the ideals of progressive enhancement, we first make sure that the images are contained within an HTML list. Eventually we want to use JavaScript to create a fade-in/fade-out slideshow effect, but our base is a single column of images. If a visitor has JavaScript disabled that’s what they’ll see.

Okay, so far so good. When we come to make a print style sheet, however, we’ll discover a flaw in our plan: when you use JavaScript to animate HTML elements, you inevitably end up modifying the elements’ style attribute. In our slide show, JavaScript has altered the position and opacity of the images, so only one is revealed at a time. When we go to print the gallery page, although we want a single column of images, what we end up printing is only a single image. That’s because you’re unable to specify a target media type for CSS declared in an element’s style attribute; you cannot say that all styles declared in the style attribute are for screen only.

So what you need is a way of specifying print styles that can override the inline styles. There’s only one way to do that: !important. In your print style sheet, reset the image elements’ position and opacity, and add !important:

img.gallery {
  position: static !important;
  opacity: 1 !important;
}

That’s it really; I found a legitimate use for !important and wanted to share it.

Related posts:

1. Create Inset-Style Type In Photoshop Jennifer shows you how to create the popular inset or...
2. 9 Reasons Why SVGs are Important for the Web Few developers use the SVG format because it's not supported...
3. How To Style Your Type With CSS Jennifer demonstrates how to use CSS to style type and...

Unfortunately, you’ll need a WebKit-based browser (Safari or Chrome, for example) to see it. So, sure it’s a WebKit proprietary CSS extension — the CSS3 animation and transformation modules are working drafts at the moment — but it’s always fun to experiment. And this experiment sure got me thinking.

But first, how is it done? Each part of the animation is separate; that is, the foot, shin, and thigh of each leg. CSS is then used to define the animation. Here’s the animation definition for the foot on Leg D, the front right one:

#atat #leg-d .leg-foot {
	-webkit-animation-name: foot-d;
	-webkit-animation-duration: 7s;
	-webkit-animation-iteration-count: infinite;
	-webkit-transform-origin: 50% 0;
}

It’s given a name, a duration (for how long the animation lasts), an iteration count (how many times the animation is run — infinitely in this case), and a position of origin. The next piece of the puzzle is the information for key frames:

@-webkit-keyframes foot-d {
  0% {
    -webkit-transform: rotate(0deg);
  }
  10% {
    -webkit-transform: rotate(-20deg);
  }
  30% {
    -webkit-transform: rotate(0deg);
  }
  100% {
    -webkit-transform: rotate(0deg);
  }
}

With the @-webkit-keyframe at-rule you define the style rules to apply at certain stages of the animation duration. Here we have apply rules at the start of the animation (0%), when it’s 10% through, 30% through, and then when it’s finished (100%). In the case of this example, the -webkit-transform declaration is used to apply a rotation, although any CSS property could be applied.

By applying different degrees of rotation, for different animated parts at different times during the animation sequence, the illusion is almost like puppetry.

There’s also an alternative syntax to use inside a @-webkit-keyframe block; you can specify to and from values like so:

@-webkit-keyframes fade-in {
  from {
    color: #fff
  }
  to {
    color: #000
  }
}

What do you think? To me it looks like a really straightforward syntax for describing animation. But you know what would be really cool? If a jQuery plugin was written that could read CSS3 animation syntax and execute the animation, making it cross-browser compatible.

Now that would rock.

You can read more about CSS3 animations on the WebKit blog.

Related posts:

1. Add More Sparkle with CSS3 Have you noticed that when EA Games release a...
2. jQTouch Makes Web Development on the iPhone and iPod Touch a Snap jQTouch is a jQuery plugin for web development on the...
3. Brainstorming: Making Sense and Taking Action Alyssa wraps up her series on brainstorming with a step-by-step...

It’s not as bizarre as it sounds. There is one very good reason for a JavaScript-based player: the Flash plugin isn’t available on all platforms. Most notably, you can’t run Flash on a iPhone or Apple’s new iPad.

“Gordon” is a cleverly-named project by Tobias Schneider which hopes to rectify the situation. It translates Flash SWF files to Scalable Vector Graphics which are supported on the iPhone. The project runs on most modern browsers with the exception of Internet Explorer (which doesn’t offer native SVG support … yet).

Gordon currently supports the SWF 1.0 format and SWF 2.0 is in development. There are several demonstrations available and, although they’re simple, they work well and show the potential.

Of course, all this work might be in vain if the real Flash plugin appears on the iPhone. But that seems fairly unlikely — Steve Jobs has little regard for Flash and states that it runs too slowly on the device. It’s also a competitor to the standard iPhone/iPad applications platform.

However, Gordon has been tested on the iPhone and it runs fast enough even though it’s built on interpreted JavaScript code. If the project becomes a success, there will be nothing Apple can do to prevent Flash running on the device. Could that provide developers with another reason to desert iPhone applications?

Have you tried Gordon? Could it ever be a viable alternative to the Flash plugin on unsupported browsers? Should Adobe hire the developer immediately?!

Related posts:

1. iPad vs Flash: Developers, Choose Wisely The newly revealed Apple iPad offers no support for Flash....
2. Adobe Hits Back at Apple’s Criticism of Flash Adobe's Kevin Lynch has hit back at Steve Jobs following...
3. JSNES: a NES Emulator Written in JavaScript Just when you thought you'd seen everything in JavaScript, along...

I was recently contacted by a frustrated developer who’d experienced disappearing absolutely-positioned elements in IE. The bug is quite bizarre, it’s not often you experience it, and there’s little information about it on the web. Hopefully, this article will go some way to rectifying that situation.

The Problem

Consider this layout:

The HTML elements are coded in the order specified, i.e. content blocks 1 and 2, header 3, right-hand block 4, and footer 5. The outer container is set to position: relative and all items have widths assigned so IE hasLayout. It may not be the most efficient layout but it’s valid and works in all browsers. Except IE6, IE7, and possibly IE8 … sometimes.

The first time you visit the page, IE can refuse to show the header. However, the header may re-appear when visiting a similarly-coded page on the same site. It can also re-appear when you return to the first page?

The problem is caused by an IE bug that hides an absolutely-positioned element when it’s coded immediately before or after a floated element (it’s next to a floated sibling). Unfortunately, this condition does not necessarily trigger the bug — it’s time dependent! The timing of the file downloads and the rendering speed affect whether it occurs or not. In my experience, the bug seemed less likely to occur if some files were cached.

So, here’s an example page.

Unfortunately, the bug is so inconsistent that it’s impossible to create one that’s guaranteed to work (or fail?)

On my local PC’s server, the header disappears in IE6, 7 and 8. On the SitePoint server, it only disappears in IE6 and 7. You may have a different experience.

In addition, fake IEs such as IETester do not necessarily exhibit the same problem. I’d recommend using a real version of IE such as one within a VM (see Run IE6, IE7, and IE8 on the Same Machine Using Windows 7 XP Mode or How to Run IE6, IE7 and IE8 on Windows 7 HOME).

The Solution

Fortunately, there is a quick and dirty solution: simply place an empty un-positioned static <div></div> immediately before and/or after the absolutely-positioned element. In the fixed example, an empty <div></div> after the header prevents the problem occurring.

Semantic HTML devotees will be horrified but I’m afraid there doesn’t appear to be a CSS-only fix … unless anyone knows otherwise?

A better solution would be a more efficient layout without the absolutely-positioned header. Unfortunately, that can require a significant amount of code re-factoring if you haven’t tested IE early and often.

Have you experienced this strange bug before? Or have you given up on IE altogether?

Related posts:

1. IE8 Automatic Update Starting Soon Internet Explorer 8.0 will shortly be rolled out to IE6...
2. Firefox 3.5 is the World’s Most Popular Browser Firefox 3.5 has just overtaken IE7 to become the most...
3. The Two Ways of Sizing Absolute Elements in CSS Most developers have used left, right, top and bottom properties...

• jQuery 1.4 minified (23kb)
• jQuery 1.4 regular (154kb)
• Google-hosted: http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js
• jQuery 1.4 documentation

What’s New in jQuery 1.4?

jQuery is probably the most popular JavaScript framework on the web. Many developers insert the script by habit (yes W3C.org, I’m referring to you!), so the jQuery team needs to be extremely cautious when creating new releases.

The code base has been heavily restructured to reduce complexity and increase performance. There are some impressive bar charts on jquery14.com which highlight how good the optimizations are.

207 bugs have been fixed and the framework now passes 100% of all tests in IE6, IE7, IE8, Firefox 2, Firefox 3, Firefox 3.5, Safari 3.2, Safari 4, Opera 10.10, and Chrome.

There is a substantial number of new methods and two new events: focusin and focusout. These are equivalent to focus and blur, but they implement an event bubbling-like technique (focus and blur do not normally bubble). For example, you can attach a handler to all your forms which is fired when any of the internal controls receive focus, e.g.

$("form").focusin(function(event) {
	alert("event fired!");
});

Useful stuff.

What Will Break If You Upgrade?

The jQuery team has provided a list of the most likely problems. I suspect the following issues will cause the most confusion:

1. jQuery() returns an empty set
In previous versions of the library, running jQuery() (no arguments) returned jQuery(document). It now returns an empty set, although the jQuery().ready() event will still fire as expected.

2. Ajax requests must use valid JSON
If you’re passing JSON data in Ajax calls, you must ensure it’s not malformed.jQuery now use the browser’s native JSON.parser in preference to eval when possible.

3. jQuery.browser returns the engine version
If you’re sniffing for browsers, jQuery.browser now returns the rendering engine version rather than a specific browser type, e.g. “webkit” rather than “chrome”.

I mentioned how difficult user agent parsing had become in a previous post. The jQuery developers have reduced complexity and increased speed by simplifying the returned information.

Although jQuery still supports browser-like detection, I strongly recommend you avoid it and use feature/object detection instead.

Is jQuery 1.4 For You?

If you’re after a solid JavaScript library, jQuery remains one of the obvious choices. It’s lightweight, functional, and supports the majority of modern browsers. For those upgrading from previous versions, it might be advisable to wait a few weeks to ensure there are no major problems.

Have you tried jQuery 1.4? Comments welcome.

Related posts:

1. How to Build an Auto-Expanding Textarea jQuery Plugin, Part 1 Auto-expanding HTML textarea boxes have become popular on many web...
2. Make Your Own Web Site Badges with jQuery and JSON Now that most social media sites offer a JSON API,...
3. How to Build an Auto-Expanding Textarea jQuery Plugin, Part 3 Auto-expanding HTML textarea boxes have become popular on many web...

Three systems are provided for eager client-side developers:

1. The Google Closure Compiler

“Compiler” is a confusing term — this is a Java-powered JavaScript optimizer that reduces file sizes by removing dead code, renaming variables, and removing whitespace and comments.

You can either:

1. download the Closure Compiler, or
2. use the online Closure Compiler tool.

In my brief tests, a 28Kb JavaScript file was reduced to 15Kb (46% reduction) using “Simple” compression to remove white-space and comments. The reduction factor was almost identical to Yahoo’s YUI Compressor.

“Advanced” compression with variable and function renaming reduced the file size to a little under 10Kb (64% reduction). The code continued to work correctly, although a couple JavaScript warnings were generated about uninitialized variables which were not evident in the uncompressed version.

The Closure Compiler is certainly worth trying if you want to speed up your web page’s download speeds. However, be careful to fully test the resulting JavaScript code.

2. The Google Closure Library

The Closure library is an alternative to jQuery or the YUI Library. The usual features are available, e.g. helper functions, Ajax, DOM manipulation, event handlers, CSS control, animation, effects, etc.

The code, comments, and documentation are generally good, although I could not find information about browser support. Some of the examples are a little basic but I suspect they will be improved over time.

Kevin Yank’s recent article features comments from Dmitry Baranovskiy who has expressed concerns about the quality of the code. They are valid criticisms and I doubt the Closure will win over many jQuery aficionados, but choice is always a good thing and the library is will improve now it’s in the public domain.

3. Google Closure Templates

Closure Templates is a templating system for client-side JavaScript and server-side Java. It’s a system that allows you to add small language-neutral components that create a full user interface.

Documentation is sparse and there are few examples. Server-side Java developers may adopt the system, but I’m not convinced it will appeal to ASP.NET or PHP developers.

Will you try Google’s Closure Tools? Or has the choice of tools become so bewildering you’ll stick with what you know?

See also: Google Closure: How not to write JavaScript

Related posts:

1. Google Closure: How not to write JavaScript What if Google released a JavaScript library that sucked, and...
2. SitePoint Roundup #1: RIP Dan Schulz, Google Closure Debate, and the Podcast Turns One Is Dmitry Baranovskiy's critique of Closure valid, or just nitpicking?...
3. BBC Glow – a New JavaScript Library The British Broadcasting Corporation has released a new open source...

Having delivered a talk on how to write your own JavaScript library (detailed notes) at the conference, Dmitry shared his thoughts on the new library over breakfast the next morning. “Just what the world needs—another sucky JavaScript library,” he said. When I asked him what made it ‘sucky’, he elaborated. “It’s a JavaScript library written by Java developers who clearly don’t get JavaScript.”

For the rest of the day, to anyone who would listen, Dmitry cited example after example of the terrible code he had found when he went digging through Closure. His biggest fear, he told me, was that people would switch from truly excellent JavaScript libraries like jQuery to Closure on the strength of the Google name.

“I’ll make you a deal,” I told him. “Send me some examples of this terrible code and I’ll publish it on SitePoint.”

The Slow Loop

From array.js, line 63:

for (var i = fromIndex; i < arr.length; i++) {

This for loop looks up the .length property of the array (arr) each time through the loop. Simply by setting a variable to store this number at the start of the loop, you can make the loop run much faster:

for (var i = fromIndex, ii = arr.length; i < ii; i++) {

Google’s developers seem to have figured this trick out later on in the same file. From array.js, line 153:

var l = arr.length;  // must be fixed during loop... see docs
⋮
for (var i = l - 1; i >= 0; --i) {

This loop is better in that it avoids a property lookup each time through the loop, but this particular for loop is so simple that it could be further simplified into a while loop, which will run much faster again:

var i = arr.length;
⋮
while (i--) {

But not all of Closure Library’s performance woes are due to poorly optimized loops. From dom.js, line 797:

switch (node.tagName) {
  case goog.dom.TagName.APPLET:
  case goog.dom.TagName.AREA:
  case goog.dom.TagName.BR:
  case goog.dom.TagName.COL:
  case goog.dom.TagName.FRAME:
  case goog.dom.TagName.HR:
  case goog.dom.TagName.IMG:
  case goog.dom.TagName.INPUT:
  case goog.dom.TagName.IFRAME:
  case goog.dom.TagName.ISINDEX:
  case goog.dom.TagName.LINK:
  case goog.dom.TagName.NOFRAMES:
  case goog.dom.TagName.NOSCRIPT:
  case goog.dom.TagName.META:
  case goog.dom.TagName.OBJECT:
  case goog.dom.TagName.PARAM:
  case goog.dom.TagName.SCRIPT:
  case goog.dom.TagName.STYLE:
    return false;
}
return true;

This kind of code is actually pretty common in Java, and will perform just fine there. In JavaScript, however, this switch statement will perform like a dog each and every time a developer checks if a particular HTML element is allowed to have children.

Experienced JavaScript developers know that it’s much quicker to create an object to encapsulate this logic:

var takesChildren = {}
takesChildren[goog.dom.TagName.APPLET] = 1;
takesChildren[goog.dom.TagName.AREA] = 1;
⋮

With that object set up, the function to check if a tag accepts children can run much quicker:

return !takesChildren[node.tagName];

This code can be further bulletproofed against outside interference using hasOwnProperty (see below for a full explanation of this).

return !takesChildren.hasOwnProperty(node.tagName);

If there’s one thing we expect from Google it’s a focus on performance. Heck, Google released its own browser, Google Chrome, primarily to take JavaScript performance to the next level!

Seeing code like this, one has to wonder if Google could have achieved the same thing by teaching its engineers to write better JavaScript code.

Six Months in a Leaky Boat

It would be unfair to suggest that Google has ignored performance in building Closure. In fact, the library provides a generic method for caching the results of functions that run slowly, but which will always return the same result for a given set of arguments. From memoize.js, line 39:

goog.memoize = function(f, opt_serializer) {
  var functionHash = goog.getHashCode(f);
  var serializer = opt_serializer || goog.memoize.simpleSerializer;
  
  return function() {
    // Maps the serialized list of args to the corresponding return value.
    var cache = this[goog.memoize.CACHE_PROPERTY_];
    if (!cache) {
      cache = this[goog.memoize.CACHE_PROPERTY_] = {};
    }
    var key = serializer(functionHash, arguments);
    if (!(key in cache)) {
      cache[key] = f.apply(this, arguments);
    }
    return cache[key];
  };
};

This is a clever performance trick employed in a number of major JavaScript libraries; the problem is, Google has not provided any means of limiting the size of the cache! This is fine if a cached function is only ever called with a small collection of different arguments, but this is a dangerous assumption to make in general.

Used to cache a function’s results based on, say, the coordinates of the mouse pointer, this code’s memory footprint will rapidly grow out of control, and slow the browser to a crawl.

In Dmitry’s words, “I’m not sure what this pattern is called in Java, but in JavaScript it’s called a ‘memory leak’.”

Code in a Vacuum

In his talk on building JavaScript libraries, Dmitry compared JavaScript’s global scope to a public toilet. “You can’t avoid going in there,” he said. “But try to limit your contact with surfaces when you do.”

For a general-purpose JavaScript library to be reliable, it must not only avoid interfering with any other JavaScript code that might be running alongside it, but it must also protect itself from other scripts that aren’t so polite.

From object.js, line 31:

goog.object.forEach = function(obj, f, opt_obj) {
  for (var key in obj) {
    f.call(opt_obj, obj[key], key, obj);
  }
};

for-in loops like this one are inherently dangerous in JavaScript libraries, because you never know what other JavaScript code might be running in the page, and what it might have added to JavaScript’s standard Object.prototype.

Object.prototype is the JavaScript object that contains the properties shared by all JavaScript objects. Add a new function to Object.prototype, and every JavaScript object running in the page will have that function added to it—even if it was created beforehand! Early JavaScript libraries like Prototype made a big deal of adding all sorts of convenience features to Object.prototype.

Unfortunately, unlike the built-in properties supplied by Object.prototype, custom properties added to Object.prototype will show up as an object property in any for-in loop in the page.

In short, Closure Library cannot coexist with any JavaScript code that adds features to Object.prototype.

Google could have made its code more robust by using hasOwnProperty to check each item in the for-in loop to be sure it belongs to the object itself:

goog.object.forEach = function(obj, f, opt_obj) {
  for (var key in obj) {
    if (obj.hasOwnProperty(key)) {
      f.call(opt_obj, obj[key], key, obj);
    }
  }
};

Here’s another especially fragile bit of Closure Library. From base.js, line 677:

goog.isDef = function(val) {
 return val !== undefined;
};

This function checks if a particular variable has a value defined. Or it does, unless a 3rd party script sets the global undefined variable to something else. This single line of code anywhere in the page will bring Closure Library crashing down:

var undefined = 5;

Relying on the global undefined variable is another rookie mistake for JavaScript library authors.

You might think that anyone who assigns a value to undefined deserves what they get, but the fix in this case is trivial: simply declare a local undefined variable for use within the function!

goog.isDef = function(val) {
  var undefined;
  return val !== undefined;
};

Typical Confusion

One of the most confusing aspects of JavaScript for developers coming from other languages is its system of data types. Closure Library contains plenty of bloopers that further reveal that its authors lack extensive experience with the finer points of JavaScript.

From string.js, line 97:

// We cast to String in case an argument is a Function. …
var replacement = String(arguments[i]).replace(…);

This code converts arguments[i] to a string object using the String conversion function. This is possibly the slowest way to perform such a conversion, although it would be the most obvious to many developers coming from other languages.

Much quicker is to add an empty string ("") to the value you wish to convert:

var replacement = (arguments[i] + "").replace(…);

Here’s some more string-related type confusion. From base.js, line 742:

goog.isString = function(val) {
  return typeof val == 'string';
};

JavaScript actually represents text strings in two different ways—as primitive string values, and as string objects:

var a = "I am a string!";
alert(typeof a); // Will output "string"
var b = new String("I am also a string!");
alert(typeof b); // Will output "object"

Most of the time strings are efficiently represented as primitive values (a above), but to call any of the built-in methods on a string (e.g. toLowerCase) it must first be converted to a string object (b above). JavaScript converts strings back and forth between these two representations automatically as needed. This feature is called “autoboxing”, and appears in many other languages.

Unfortunately for Google’s Java-savvy developers, Java only ever represents strings as objects. That’s my best guess for why Closure Library overlooks the second type of string in JavaScript:

var b = new String("I am also a string!");
alert(goog.isString(b)); // Will output FALSE

Here’s another example of Java-inspired type confusion. From color.js, line 633:

return [
  Math.round(factor * rgb1[0] + (1.0 - factor) * rgb2[0]),
  Math.round(factor * rgb1[1] + (1.0 - factor) * rgb2[1]),
  Math.round(factor * rgb1[2] + (1.0 - factor) * rgb2[2])
];

Those 1.0s are telling. Languages like Java represent integers (1) differently from floating point numbers (1.0). In JavaScript, however, numbers are numbers. (1 - factor) would have worked just as well.

Yet another example of JavaScript code with a whiff of Java about it can be seen in fx.js, line 465:

goog.fx.Animation.prototype.updateCoords_ = function(t) {
  this.coords = new Array(this.startPoint.length);
  for (var i = 0; i < this.startPoint.length; i++) {
    this.coords[i] = (this.endPoint[i] - this.startPoint[i]) * t +
        this.startPoint[i];
  }
};

See how they create an array on the second line?

this.coords = new Array(this.startPoint.length);

Although it is necessary in Java, it is entirely pointless to specify the length of an array ahead of time in JavaScript. It would make just as much sense to create a new variable for storing numbers with var i = new Number(0); instead of var i = 0;.

Rather, you can just set up an empty array and allow it to grow as you fill it in. Not only is the code shorter, but it runs faster too:

this.coords = [];

Oh, and did you spot yet another inefficient for loop in that function?

API Design

If all the low-level code quality nitpicks above don’t convince you, I defy you to try using some of the APIs Google has built into Closure Library.

Closure’s graphics classes, for example, are modeled around the HTML5 canvas API, which is about what you’d expect from a JavaScript API designed by an HTML standards body. In short, it’s repetitive, inefficient, and downright unpleasant to code against.

As the author of Raphaël and gRaphaël, Dmitry has plenty of experience designing usable JavaScript APIs. If you want to grasp the full horror of the canvas API (and by extension, Closure’s graphics API), check out the audio and slides from Dmitry’s Web Directions South 2009 talk on the subject.

Google’s Responsibility to Code Quality

By this point I hope you’re convinced that Closure Library is not a shining example of the best JavaScript code the Web has to offer. If you’re looking for that, might I recommend more established players like jQuery?

But you might be thinking “So what? Google can release crappy code if it wants to—nobody’s forcing you to use it.” And if this were a personal project released by some googler on the side under his or her own name, I’d agree with you, but Google has endorsed Closure Library by stamping it with the Google brand.

The truth is, developers will switch to Closure because it bears the Google name, and that’s the real tragedy here. Like it or not, Google is a trusted name in the development community, and it has a responsibility to that community to do a little homework before deciding a library like Closure deserves public exposure.

Related posts:

1. Google Releases its JavaScript Closure Tools Do we need more JavaScript libraries and tools? Perhaps not,...
2. How to Write a Cookie-less Session Library for JavaScript Craig provides the code for a stand-alone JavaScript session variable...
3. Fixing Object Instances in JavaScript Even experienced coders can get caught out by object handling...

Of course, even the most dedicated SitePoint fan could find it hard to justify a trip to Australia to see me speak; thankfully, the folks at Web Directions were kind enough to share the audio recorded at the event under a Creative Commons license that enables me to share it with you in a richer format.

I am delighted, therefore, to present this video re-creation of the talk including my animated slides, a screencast video demo, and the audio recorded live at Web Directions South 2009. Be sure to visit the Web Directions site for the accumulated audio and slides from the entire conference series!

CSS Frameworks: Make the Right Choice (WDS09) from SitePoint Staff on Vimeo.

SitePoint CTO Kevin Yank presented this talk at Web Directions South 2009 in Sydney, Australia on Friday, October 9th, 2009.

With the proliferation and widespread adoption of JavaScript frameworks, smart developers have wondered if a similar approach to smoothing over the rough spots of CSS might work. Thus, CSS frameworks like Blueprint, YUI Library CSS Tools, Boilerplate, and many others were born. In this session, we will survey the landscape of CSS frameworks and consider how each of them deals with the unique challenge of creating generalised, reusable CSS styles.

There are a number of different approaches, and some are better than others. Choose the right framework and you’ll save yourself a lot of work. Choose the wrong one, and you’ll find your projects weighed down by restrictive assumptions and masses of code that you don’t understand. When it comes to CSS frameworks, making the right choice is everything. By the end of this session, you might just decide that the right framework for you is no framework at all.

Related posts:

1. CSS Frameworks and Semantic Class Names CSS frameworks often contain crufty, non-semantic code. Does it have...
2. Win Signed SitePoint Books at Web Directions South If you're at the Web Directions South conference in Sydney...
3. First Look: Object Oriented CSS Nicole Sullivan's Object Oriented CSS aims to make your styles...

// object constructor
function ObjectConstructor(a, b, c) {

	this.A = a;
	this.B = b;
	this.C = c;
	this.Total = a + b + c;

}

var obj = ObjectConstructor(1, 2, 3);

alert(obj.Total);

Hands up everyone who answered “6.”

Sorry, you’re wrong. The answer is … nothing — or an error stating that ‘obj’ is undefined. So what’s gone wrong?

The simple answer is that we’ve forgotten the ‘new’ operator so an object instance is never created. The statement should be:

var obj = new ObjectConstructor(1, 2, 3);

It’s an easy mistake to make. Novice developers are unlikely to spot the missing operator because the code looks almost identical. Even experienced coders could find it tough to debug (especially since many assume JavaScript is a procedural programming language … which it can be, if you choose to write it that way).

The main problem is that var obj = ObjectConstructor(1, 2, 3); is a perfectly valid JavaScript statement and the interpretor engine will not throw an error. In that context, the value of obj is set to the value returned from the function ObjectConstructor; since no value is returned, obj remains “undefined” (a top-level JavaScript property).

This is unlikely to become a major problem if you’re developing, testing and debugging your own code. However, it could be a different matter when you’re providing a library or API to thousands of third-party developers. At some point, someone, somewhere, will miss that ‘new’ operator and they will blame your code rather than theirs.

Fortunately, JavaScript is a flexible language. We can fix our constructor so an object is correctly created even when the ‘new’ operator is omitted:

// object constructor
function ObjectConstructor(a, b, c) {

	if (!(this instanceof arguments.callee)) {
		return new ObjectConstructor(a, b, c);
	}

	this.A = a;
	this.B = b;
	this.C = c;
	this.Total = a + b + c;

}

The additional ‘if’ statement at the top of the constructor checks whether ‘this’ is an instance of the object and returns one if necessary. The code var obj = ObjectConstructor(1, 2, 3); will now set obj to an object instance and “6″ will be output by the alert statement.

Have you ever encountered this problem in your code or when using another library?

Related posts:

1. Cross-browser JSON Serialization in JavaScript JSON serialization can be incredibly useful, but few browsers support...
2. Truthy and Falsy: When All is Not Equal in JavaScript Anything in JavaScript can be considered to be either truthy...
3. Google Closure: How not to write JavaScript What if Google released a JavaScript library that sucked, and...

One of the most common complaints about CSS frameworks like Blueprint, YUI Grids, and 960.gs is that they require designers to dirty their fingers by adding presentational class names to their HTML documents, like so:

<div class="span-9 last">
<div class="grid_6 alpha">

Class names like "span-9" really bother designers who care about the quality of their HTML code, because they describe the appearance of an element; this should really be left to the CSS properties defined in your site’s style sheets. The problem with presentational class names is explained especially well by the W3C QA tip, Use class with semantics in mind:

Good names don’t change. Think about why you want something to look a certain way, and not really about how it should look. Looks can always change, but the reasons for giving something a look stay the same.

Maybe you’re the pragmatic type who takes no issue with this sort of thing, or decides that it’s a necessary evil given the limitations of the CSS language. Nevertheless, there are plenty of front-end ninjas out there who refuse to use CSS frameworks for this very reason.

It turns out, however, that the latest crop of CSS frameworks provide clever solutions to the problem of presentational class names.

Blueprint CSS, the granddaddy of CSS layout frameworks, now includes a clever Ruby script called compress.rb in its download package. In Blueprint’s compress.rb: A Walkthrough, Blueprint author Joshua Clayton explains how to use the script to generate a custom version of the Blueprint style sheets using your own semantic class names.

The process boils down to writing a simple configuration file that tells the script how to map Blueprint’s presentational class names to your own semantically meaningful class names. The file will look like this:

demo:
  path: /Users/kyank/Documents/myproject
  semantic_classes:
    ".header, .footer": ".span-24, div.span-24"
    ".content": ".span-18, div.span-18"
    ".sidebar": ".span-6, div.span-6,
                 .last, div.last"

The semantic_classes section provides the mapping. In this example, the header and footer classes will be 24 grid units wide and the content class will be 18 grid units wide. The sidebar class will be 6 grid units wide and the last block in its row.

With this configuration file written, you simply run the compress.rb script, and the customized version of the Blueprint style sheet files (screen.css, print.css, and ie.css) will be generated in the specified path. The style sheet will contain rules like this one, that apply the grid dimensions to your custom class names:

/* semantic class names */
.content {float:left;margin-right:10px;
  width:710px;}

… and just like that, you gain all the layout facilities of Blueprint CSS with none of the HTML cruft!

If manually compiling your style sheets with a Ruby script sounds like a bit of a pain (which it can be — especially if you develop on a Windows computer without Ruby installed), a server-side CSS framework might be a better option for you.

CSS frameworks are popping up for all the major server-side programming languages. Two prominent examples include Compass (for Ruby), and Scaffold (for PHP). These frameworks let you write your style sheets with extra language features, and automatically compile them to standard CSS code when sending them to the browser.

Using Scaffold, for example, you could write your style sheet like this:

@grid {
  column-width:30;
  column-count:24;
  right-gutter-width:20;
  baseline:20;
  unit:px;
}
.header, .footer {
  +columns(24);
}
.content {
  +columns(18);
}
.sidebar {
  +columns(6);
  +last;
}

The @grid at-rule sets up the options for Scaffold’s layout plugin, and then lines like +columns(24); (called mixins) are compiled into standard CSS properties when the browser requests the style sheet.

These are just a couple of the ways that the latest CSS frameworks respond to those critics who complain about having to sacrifice HTML code quality to use them. Now you can have all the benefits of a well-tested layout framework, and apply them to your HTML code on your terms.

(photo: Nbauer)

Related posts:

1. Video: CSS Frameworks – Make the Right Choice Choose the right framework and you’ll save yourself a lot...
2. How Semantic Markup Helps Server-side Developers Write Reusable Code As front-end developers, we know how much easier maintenance, testing,...
3. Techy Treasures #5: Fudging CSS Counters in Internet Explorer CSS Counters are a useful but under-used feature of CSS2...

The WSG mailing list gets a lot of CSS layout questions sent to it and last week I noticed this query. Tee wanted to visually reproduce the table layout shown below without adding extra wrapping DIVs or other non-semantic markup.

It’s not quite as simple as it looks.

Anyway, playing around my approach, I came across a CSS property I’ve rarely seen in use: border-spacing.

Now if you’re not super familiar with border-spacing, it’s essentially a better version of the old ‘cellspacing’ table attribute (i.e. <table cellspacing="3px" ..) , and controls the space *between* your table cells. Of course, if you set the table’s border to collapse (i.e. border-collapse:collapse;) there *is* no space between your table cells, so setting border-spacing becomes redundant.

The key advantage that CSS’s border-spacing has over HTML’s cellspacing (besides cleaner markup) is it allows you to set different horizontal and vertical spacing widths — seemingly perfect for creating the 5 pixel row separations required in the example. Cellspacing only accepts a single value.

Guessing the CSS, I didn’t get the result I expected when I tried (try for yourself):

table#grid {
	border-collapse:separate;
	border-spacing:  5px 0px ;
}

Counter-intuitively to the way margin, padding, border and every other CSS property I can think of operates, border-spacing asks for it’s horizontal value before it’s vertical value. Strange.

Other points to note with border-spacing:

• You aren’t able to assign different top, bottom, right and left values. This makes sense if you think about it, as we’re actually talking about an attribute of the TABLE, but I think it’s easy to trick yourself into thinking it’s part of the TD — it wraps around the TD borders after all.
• Support is perfect in all modern browsers, but old IE6 & 7 don’t support this property at all.

Related posts:

1. 5 Rarely-Used CSS Properties It is easy to forget CSS that you don't use...
2. How to Use Operating System Styles in CSS CSS can reference fonts and colors defined for the underlying...
3. Techy Treasures #5: Fudging CSS Counters in Internet Explorer CSS Counters are a useful but under-used feature of CSS2...

Visit the JSNES page…

The emulator is port of the Java-based vNES project. It uses the HTML canvas element for screen rendering (sorry Internet Explorer users) although sound is not supported yet.

There are 17 working games to try. Most will run in Firefox 3.5 or Safari 4, but neither browser offers a playable gaming experience. You’ll be lucky to achieve 10 frames per second on the highest-specification liquid-nitrogen-cooled ninja PC.

The real revelation, however, is Google Chrome — it runs the emulator at full speed (50-60 fps) on a modest PC. Google’s canvas performance optimization appears to be out-pacing the competition by a considerable margin. Both Mozilla and WebKit have raised bugs to investigate why there is such a noticeable speed difference.

Although JSNES is little more than an interesting experiment, it illustrates what can be achieved with modern JavaScript engines, some ingenuity, and lots of caffeine. Ben Firshman — you are a genius. My only question is … why?!!

See also: SitePoint’s Exclusive Interview With Ben Firshman, Creator of JSNES

Related posts:

1. Exclusive Interview With Ben Firshman, Creator of JSNES Craig interviews Ben Firshman, developer of the JavaScript-based NES emulator...
2. Introducing Gordon: the Flash Player Written in JavaScript That's right - it's a Flash player written in JavaScript....
3. Google Chrome Frame: the Technical Details Google's Chrome Frame announcement has been surrounded by hype, fabrication,...

And I don’t mean developers, I mean real people — actual users, who are browsing the Web with assistive devices and making use of ARIA enabled applications?

See, when I first researched the question of accessible Ajax for The JavaScript Anthology, back in 2006, there was no such thing as ARIA; there was only the early draft ideas that would eventually become it, based largely on work done at IBM.

And I was unimpressed. Not because of any specific details, but over the entire concept behind it — the idea that all RIAs needed to make them usable for screenreaders is more information seemed naïve.

And now that we have a formal specification, with browsers and screenreaders that have working implementations, I ask the same question — are RIAs really appropriate to assistive devices if only they had that role and state information, or are we trying to force a square peg into a round hole? Are we just adding layers of information on top of a paradigm that is fundamentally incompatible with the target devices?

What my question really comes down to is, can any Ajax-based application which requires an API to give the consuming device enough information to make sense of it, possibly be better than what we had before — where you submit a form and you get a new page in response — something that generations of devices were well able to comprehend.

I’m not trying to dredge up my stop using Ajax argument again — not at all, I accept that Ajax is here to stay, and welcome it as a valuable addition to the programmer’s toolkit. But the hype has yet to calm down, and Ajax is still over-used. The question of to what extent Ajax applications are expected to progressively enhance from static applications is still very much an issue, as the bulk of the comments in one of Craig’s recent posts highlighted all too sharply.

So where are the ARIA users? And what do they think?

It’s an honest question, because I really don’t know. Is there any information? Have any studies been carried out, that convincingly answer the question of whether ARIA enabled applications are a better user experience for people using assistive technologies, compared with conventional post-and-response style applications, that RIAs should otherwise be expected to degrade to?

Is ARIA really the way forward, or is it just a solution looking for a problem?

Related posts:

1. 5 Reasons Why There are no Killer Offline Web Applications Technologies that implement offline web functionality have been around for...
2. Progressive Enhancement and Graceful Degradation: an Overview It is possible to create a fantastic-looking Ajax-powered Internet application...

View the JavaScript session library demonstration page…

The code provides three main methods:

• Session.set(name, object) — store a named session value/object
• Session.get(name) — retrieve a named session value/object
• Session.clear() — reset all the session data

Another Session.dump() method returns all the JSON-encoded session data. This would normally be used for debugging purposes only.

The JavaScript code is loaded just before the closing body tag. First, we load the JSON library:

<script type="text/javascript" src="json-serialization.js"></script>

The JSON library provides cross-browser serialization methods that are required by our Session library. For more information, refer to Cross-browser JSON Serialization in JavaScript.

The session.js file is loaded next. This is stand-alone code that can be implemented in any system — it does not depend on jQuery or any other JavaScript library. Working through the code:

 if (JSON && JSON.stringify && JSON.parse) var Session = Session || (function() {

	// window object
	var win = window.top || window;

	// session store
	var store = (win.name ? JSON.parse(win.name) : {});

The first line defines our Session module. However, it will only be defined if the JSON library has been loaded and there are no other conflicting Session variables or functions.

The second line sets win to ‘window.top’. It is set to ‘window’ if that is not available (perhaps if the browser does not support frames).

Next, we define a ’store’ object to hold all our session data. Exisiting JSON-encoded data in the window.name property is parsed but, if that is not available, ’store’ is set to an empty object.

	// save store on page unload
	function Save() {
		win.name = JSON.stringify(store);
	};

	// page unload event
	if (window.addEventListener) window.addEventListener("unload", Save, false);
	else if (window.attachEvent) window.attachEvent("onunload", Save);
	else window.onunload = Save;

The private Save() function assigns the serialized the ’store’ object string to the window .name property. The following three lines define a cross-browser event which calls the Save function when the page is unloaded. Your pages can therefore modify the ’store’ as much as necessary, but the heavy work of serializing and saving only occurs at the last possible moment.

	// public methods
	return {

		// set a session variable
		set: function(name, value) {
			store[name] = value;
		},

		// get a session value
		get: function(name) {
			return (store[name] ? store[name] : undefined);
		},

		// clear session
		clear: function() { store = {}; },

		// dump session data
		dump: function() { return JSON.stringify(store); }

	};

 })();

Finally, we have our four public set, get, clear and dump functions which handle the store object accordingly. The Session.get() method will return a JavaScript ‘undefined’ value if a session name can not be found.

I hope you find the code useful. Feel free to use it in your own projects.

Useful resources:

• JavaScript session variables demonstration page
• Full JavaScript session.js code
• Download full code in a ZIP file

See also:

• Cookie-less Session Variables in JavaScript
• Cross-browser JSON Serialization in JavaScript
• How To Develop a jQuery Plugin
• How to Build an Auto-Expanding Textarea jQuery Plugin

Related posts:

1. Cookie-less Session Variables in JavaScript Cookies may be delicious, but they can be clumsy if...
2. Cross-browser JSON Serialization in JavaScript JSON serialization can be incredibly useful, but few browsers support...
3. BBC Glow – a New JavaScript Library The British Broadcasting Corporation has released a new open source...

Fortunately, there is a solution that allows you to store JavaScript data within the browser. The data is retained between page loads, it’ll survive page back/next events (even away from the domain), it does not require plugins or off-line storage facilities, it’ll hold at several megabytes of information, it is never transmitted to the server, and works in every browser. Bizarrely, it works by exploiting the window.name property (or window.top.name if you’re using multiple frames).

It’s rare for developers set the window.name property. Generally, it’s only required when you’re manipulating frames or pop-up windows. Even though I’d hope you weren’t doing that, you do not normally need to define a name for an application’s starting window. Although the name property is still a string, it can hold several megabytes of data. Some versions of Opera limit it to around 2Mb but most browsers offer 10MB or more.

It’s easy to try for yourself. Insert the following JavaScript code into a page on your site:

window.name = "This message will survive between page loads.";

Now add the following code to any other page:

alert(window.name);

Navigate from the first page to the second and you’ll find that the message data is retained.

As normal, there are a number of caveats:

1. The window.name property can be analysed and changed if you navigate to page on another website. That’s easily thwarted by not providing external links within your application’s main window. However, to be on the safe side, don’t use window.name for storing secure data (unlikely to be a major problem for a client-side-only temporary data store).
2. window.name can only store strings. What if we need to save other data types or even complex objects? Serialization is the answer and, fortunately, we have already developed cross-browser code to generate JSON strings from any JavaScript object.

See also: How to Write a Cookie-less Session Library for JavaScript.

Related posts:

1. How to Write a Cookie-less Session Library for JavaScript Craig provides the code for a stand-alone JavaScript session variable...
2. Cross-browser JSON Serialization in JavaScript JSON serialization can be incredibly useful, but few browsers support...
3. How To Create an Offline Web Application Craig provides a quick and simple tutorial which explains how...

The font-size Property

The font-size property can be set for any HTML tag (even if it would not normally contain textual content like br). It can be assigned a variety of absolute, relative, or length size parameters.

An element will inherit the font-size of its parent unless you override it. This is especially important when you specify relative sizes.

Absolute Font Sizing Keywords

Several absolute font-sizing keywords are available. The font size is determined from a browser preset and the element will not inherit its parent’s size.

• font-size: xx-small;
• font-size: x-small;
• font-size: small;
• font-size: medium;
• font-size: large;
• font-size: x-large;
• font-size: xx-large;

Although most browsers support these keywords, the exact sizes will differ. They are a fairly crude method of font sizing and are generally avoided by most developers.

Relative Font Sizing Keywords

Two relative font-sizing keywords are available. The font is sized according to its parent element:

• font-size: smaller;
• font-size: larger;

For example, if the parent has a font size of ‘medium’, a value of ‘larger’ will set the element to ‘large’. Other font units are normally altered by a factor of around 1.2 but, again, there is no standard and browser results will differ.

Absolute Lengths

The font-size property can be assigned an absolute length:

• mm: millimeters, e.g. 10mm.
• cm: centimeters, e.g. 1cm ( = 10mm).
• in: inches, e.g. 0.39in ( ~= 10mm).
• pt: point, where 1pt is generally assumed to be 1/72 inch e.g. 12pt.
• pc: pica, where 1pc is 12pt
• px: pixel, e.g. 14px.

In general, there are issues with all these measurement units. Millimeters, centimeters and inches are inaccurate for a screen-based medium. Points and picas are unreliable since systems can use different dpi settings. Pixel appears to be the most suitable, but it can lead to accessibility issues because the text cannot be resized in IE.

Relative Lengths

The font-size property can be assigned a unit that it relative to its parent’s font size:

• em: 1em is equivalent to the current font size, so 2em is twice as large.
• %: 100% is equivalent to the current font size, so 200% is twice as large.
• ex: 1ex is equivalent to the height of the letter ‘x’ in the current font.

Few developers use ‘ex’, but it can be useful in some situations where you need fine-grained font sizes, e.g. 1ex rather than 0.525em.

Percentage and ‘em’ sizes are equivalent, e.g. 50% = 0.5em, 100% = 1em, 120% = 1.2em, etc. Some browsers exhibit subtle differences but it’s rarely a major problem. If you want to save every byte, you could choose the shortest definition, i.e. 50% is shorter than 0.5em and 1em is shorter than 100%.

Text Sizing and Page Zooming

This is where additional complexity creeps in. Most browsers allow the user to:

1. increase or decrease the base text size (image dimensions are not changed)
2. zoom the page in or out so all the text and graphics change accordingly, or
3. allow both text sizing and page zooming.

Just to complicate matters further, Internet Explorer does not allow text resizing on elements which have a font size defined in pixels (px).

If you’re a designer moving to the web from a print background, it’s disconcerting to give the user that much power. Your design could be ruined by a user zooming in 200% but reducing the text size to 50%. And — no — there is nothing you can do to prevent it. Nor should you.

CSS Font Sizing Recommendations

The general consensus is that ‘em’ or ‘%’ is the best solution in most situations. Fonts can be finely scaled relative to each other and browser text sizing is supported. I would also recommend using a percentage font-size on the body tag; it results in better text-sizing in some older browsers.

There are a couple of other recommendations I would suggest when you’re developing a site:

1. reset the font size and page zoom to their default values in all your browsers before testing (it’s caught me out a few times!)
2. try reasonable combinations of text sizing and page zooming in a variety of browsers to ensure the text remains readable.

Has font sizing ever caused you problems? Do you have any other tips?

Related posts:

1. The Two Ways of Sizing Absolute Elements in CSS Most developers have used left, right, top and bottom properties...
2. 5 Rarely-Used CSS Properties It is easy to forget CSS that you don't use...
3. Creating Beveled Images with CSS In this post, James shows us several variations of a...

Assume we have a fairly complex JavaScript object defined using literal notation:

var obj1 = {
	b1: true,
	s1: "text string",
	n1: 12345,
	n2: null,
	n3: undefined,
	a1: [ 1,1,2,3,5,8, [13, 21, 34] ],
	o1: {
		a: [3, 2, 1],
		b: {
			c: 42,
			d: [ 3.14, 1.618 ]
		}
	}
};

We can access any of the object properties in a variety of ways:

obj1.s1;				// returns "text string"
obj1["n1"];				// returns 12345
obj1.a1[6][1];			// returns 21
obj1["o1"]["b"]["c"];	// returns 42

This object can also be passed to JavaScript functions and methods rather than specifying individual arguments. Useful stuff.

However, what if we need to store this object in a cookie? What if we need to pass the object to a web services via an Ajax request? What if that web service wants to return a modified version of the object? The answer is serialization:

• Serialization is the process of turning any object into a string.
• De-serialization turns that string back into a native object.

Perhaps the best string notation we can use in JavaScript is JSON — JavaScript Object Notation. JSON is a lightweight data-interchange format inspired by JavaScript object literal notation as shown above. JSON is supported by PHP and many other server-side languages (refer to json.org).

There are two JSON methods in JavaScript:

1. JSON.stringify(obj) — converts an JavaScript object to a JSON string
2. JSON.parse(str) — converts a JSON string back to a JavaScript object

Unfortunately, very few browsers provide these methods. To date, only Firefox 3.5, Internet Explorer 8.0 and Chrome 3 beta offer native support. Some JavaScript libraries offer their own JSON tools (such as YUI) but many do not (including jQuery).

However, all is not lost — JavaScript is flexible and we can implement the JSON stringify and parse methods whenever a browser requires them.

At the top of our code, we will create a JSON variable that points to the native JSON object or an empty object if it is unavailable:

var JSON = JSON || {};

The JSON.stringify code is a little more complex:

// implement JSON.stringify serialization
JSON.stringify = JSON.stringify || function (obj) {

	var t = typeof (obj);
	if (t != "object" || obj === null) {

		// simple data type
		if (t == "string") obj = '"'+obj+'"';
		return String(obj);

	}
	else {

		// recurse array or object
		var n, v, json = [], arr = (obj && obj.constructor == Array);

		for (n in obj) {
			v = obj[n]; t = typeof(v);

			if (t == "string") v = '"'+v+'"';
			else if (t == "object" && v !== null) v = JSON.stringify(v);

			json.push((arr ? "" : '"' + n + '":') + String(v));
		}

		return (arr ? "[" : "{") + String(json) + (arr ? "]" : "}");
	}
};

If JSON.stringify is not available, we define a new function that accepts a single obj parameter. The parameter can be a single value, an array, or a complex object such as obj1 above.

The code examines the object type. Single values are returned immediately and only strings are modified to put quotes around the value.

If an array or object is passed, the code iterates through every property:

1. Strings values have quotes added.
2. Child arrays or objects are recursively passed to the JSON.stringify function.
3. The resulting values are added to the end of a json[] array as a “name : value” string, or just a single value for array items.
4. Finally, the json array is converted to a comma-delimited list and returned within array [] or object {} brackets as necessary.

If your brain’s aching, you’ll be pleased to know that the JSON.parse code is much simpler:

// implement JSON.parse de-serialization
JSON.parse = JSON.parse || function (str) {
	if (str === "") str = '""';
	eval("var p=" + str + ";");
	return p;
};

This converts a JSON string to an object using eval().

Before you rush off to implement JSON serialization functions in all your projects, there are a few gotchas:

• This code has been intentionally kept short. It will work in most situations, but there are subtle differences with the native JSON.stringify and JSON.parse methods.
• Not every JavaScript object is supported. For example, a Date() will return an empty object, whereas native JSON methods will encode it to a date/time string.
• The code will serialize functions, e.g. var obj1 = { myfunc: function(x) {} }; whereas native JSON methods will not.
• Very large objects will throw recursion errors.
• The use of eval() in JSON.parse is inherently risky. It will not be a problem if you are calling your own web services, but calls to third-party applications could accidentally or intentionally break your page and cause security issues. If necessary, a safer (but longer and slower) JavaScript parser is available from json.org.

I hope you find the code useful. Feel free to use it in your own projects.

Resource files:

• JSON Serialization demonstration page
• Full JavaScript code (json-serialization.js)
• Download full code in a ZIP file

Related reading:

• How To Develop a jQuery Plugin
• How to Build an Auto-Expanding Textarea jQuery Plugin

Coming soon: a useful application of JSON serialization…

Related posts:

1. How to Write a Cookie-less Session Library for JavaScript Craig provides the code for a stand-alone JavaScript session variable...
2. Fixing Object Instances in JavaScript Even experienced coders can get caught out by object handling...
3. Make Your Own Web Site Badges with jQuery and JSON Now that most social media sites offer a JSON API,...

Before we begin, there are a few caveats:

• Do not rely on these properties working in all OS/browser combinations. If your application must work in Opera on BeOS, then I’d recommend you test it first!
• The properties have been deprecated in CSS3 in favor of the appearance value type (although browser support is extremely limited at this time).
• There is nothing to prevent the user defining unusual, clashing, or ugly color schemes in their OS. Pages will reflect their choices — not your designer’s.

System Fonts

System fonts are assigned using the ‘font’ property. Note that the family, size, and style are all assigned as appropriate, e.g.

body
{
	font: caption;
}

The following font values are available. The ‘Example’ column shows the current font set by your OS.

System Colors

System colors can be assigned to to any property that expects a color value, e.g.

body
{
	color: WindowText;
	background-color: Window;
	border: 2px solid ActiveBorder;
}

The following color values are available. They are shown in CamelCase for legibility, but any casing is valid. The ‘Example’ column shows the color set by your OS.

Would these properties be useful in your next project?

Related posts:

1. The Two Ways of Sizing Absolute Elements in CSS Most developers have used left, right, top and bottom properties...
2. How to Override Inline CSS Styles Inline CSS can be applied to any HTML element using...
3. Write Better CSS with Less I have a confession: I think parts of CSS suck....

Have you noticed that when EA Games release a new title they often simultaneously release the game for every gaming platform from PS3 to Nintendo DS?

There are huge differences in the capabilities of those devices and yet they adapt the games to suit each one. They change the visual design and gameplay while maintaining the games’ core experiences, themes, and branding. They focus on giving each customer the best experience for their chosen gaming device.

I can relate this to CSS development. Issues regarding IE6 support aside, we seem to be in a fantastic situation where we have a capable collection of browsers, all with a decent level of CSS2.1 support: Safari, Firefox, Opera, Chrome and Internet Explorer. In fact, this is the first time I can remember when there are 5 browsers available, all with a mature and compatible level of CSS support.

Over the last few years, best-practice CSS development has shifted from graceful degradation to progressive enhancement. And buoyed by the progress of modern browsers and the demise of older browsers, the excitement about what is possible right now is increasing. More and more designers are considering how to provide the best user experience possible for each browser without risking compatibility.

Here are a few examples I’ve come across recently:

Media queries allow fine control over how CSS rules are applied based on the features of the device on which your web page is being displayed. Device width, color, resolution and more can all be queried for. Reinhold Weber has created a demonstration of how the combination of media queries and CSS3 columns enables you to provide an optimized experience to Firefox, Safari, and Chrome users. The technique increases the number of text columns according to screen width.

Jonathan Snook has demonstrated a text rotation trick using the CSS3 transform extension in Safari, Chrome, and the latest version of Firefox. As a bonus he also demonstrates that by using the proprietary Microsoft filterproperty you can also support Internet Explorer.

Tim Brown achieves a pure CSS text-gradient in Safari while Markus Stange has some fun with box shadows in his post “Fun with Box Shadows.” Markus produces some impressive effects for buttons in Firefox 3.5 and there is also some support for box shadows in Safari and Chrome.

I used the -webkit-box-sizing property in my Adobe AIR application in order to force an element to take 100% width while excluding the width of its borders and padding. Ordinarily the borders and padding would have extended the width of the element to greater than 100% — an often encountered annoyance. Now the box-sizing property has widespread browser support as James Hopkins explains.

CSS text shadows, which have always been supported by Chrome (and much longer by Safari [since version 1.1]), are now supported by the latest versions of Firefox and Opera. Westciv has an excellent CSS text shadow generation tool that you can play with. You can also have some fun with the CSS gradient generation tools, currently supported by Safari and Chrome.

The list goes on: rounded corners, custom fonts, and RGBA colors. It certainly is exciting!

But, as exciting as this stuff is, it still has to be cost effective to be worth the effort. So I’d be interested to hear if anyone is using progressive CSS enhancement in any way in their daily work? If you do so in client work, how do you sell the idea to clients? If a client can see an enhancement demonstrated in one browser, do they demand it in all browsers? And if you have any live examples let us know how you did it.

Related posts:

1. Microsoft Office Online: a Case Against Supported Browser Lists Should you publish an official list of supported browsers for...
2. Progressive Enhancement Techniques 1: the HTML In the first of a 3-part series, Craig explains how...
3. 5 Reasons Why You Should Not Publish Supported Browser Lists Do you publish a list of supported browsers for your...

We are building a jQuery plugin named TextAreaExpander. You can read about the intricacies of jQuery plugin development in this tutorial, but the barebones of our code is:

(function($) {

	// jQuery plugin definition
	$.fn.TextAreaExpander = function(minHeight, maxHeight) {

		// ... our code ...

		return this;
	};

})(jQuery);

The $.fn statement then declares our new jQuery plugin, TextAreaExpander, with the arguments minHeight and maxHeight. We could express these in a JSON object but it’s unlikely we’ll need further parameters so we’ll keep it simple.

Note that ‘this’ refers to the jQuery object; we return it to ensure other jQuery effects can be bound to the same DOM elements.

Initializing the Textarea

The following initialization code is added to our TextAreaExpander function:

// initialize
this.each(function() {

	// is a textarea?
	if (this.nodeName.toLowerCase() != "textarea") return;

	// set height restrictions
	var p = this.className.match(/expand(\d+)\-*(\d+)*/i);
	this.expandMin = minHeight || (p ? parseInt('0'+p[1], 10) : 0);
	this.expandMax = maxHeight || (p ? parseInt('0'+p[2], 10) : 99999);

	// initial resize
	ResizeTextarea(this);

	// add events
	if (!this.Initialized) {
		this.Initialized = true;
		$(this).css("padding-top", 0).css("padding-bottom", 0);
		$(this).bind("keyup", ResizeTextarea).bind("focus", ResizeTextarea);
	}
});

return this;
};

This loops through all the jQuery-selected DOM nodes and runs an anonymous function. The value of ‘this’ within that function is an individual textarea node. The following initialization occurs:

1. The first line ensures that only textareas have the auto-expanding effect applied.
2. The next three lines extract the minimum and maximum height values. The arguments passed to the TextAreaExpander function are used by default. If none are specified, the textarea’s “expand” class HTML is analysed with a regular expression. If we still do not have values, 0 and 99999 are assumed (note that the textarea will always have a minimum height of 1 character, so a zero height is never applied). The values are stored as properties of the textarea node object — we can therefore examine them from any code.
3. The following line calls a ResizeTextarea function and passes the textarea node. This will set the height to an appropriate size when auto-expanding is initialized.
4. Finally, we reset any vertical padding and define “keyup” and “focus” events. The same ResizeTextarea function is called when the textarea receives focus and after text has been updated by the user. The ‘if’ condition around these events ensures that they can only be applied once to any textarea. This condition could have been applied to the whole of the initialization function, however, this code allows us to change the minimum and maximum heights at will.

Resizing the Textarea

We now need to define our ResizeTextarea function.

In part 1, we discussed browser differences and noted that IE and Opera should never set a textarea height of 0px. Therefore, we will assign a variable that returns false if IE or Opera is being used:

var hCheck = !($.browser.msie || $.browser.opera);

It’s dirty, but I’m afraid that we cannot rely on better methods such as object detection. I’m open to suggestions, though!

We can now code our ResizeTextarea function:

// resize a textarea
function ResizeTextarea(e) {

	// event or element?
	e = e.target || e;

	// find content length and box width
	var vlen = e.value.length, ewidth = e.offsetWidth;
	if (vlen != e.valLength || ewidth != e.boxWidth) {

		if (hCheck && (vlen < e.valLength || ewidth != e.boxWidth)) e.style.height = "0px";
		var h = Math.max(e.expandMin, Math.min(e.scrollHeight, e.expandMax));

		e.style.overflow = (e.scrollHeight > h ? "auto" : "hidden");
		e.style.height = h + "px";

		e.valLength = vlen;
		e.boxWidth = ewidth;
	}

	return true;
};

This function is passed the argument ‘e’. This is either a textarea node (during initialization) or an event object (when keyup or focus occurs).

1. The first line changes ‘e’ to a textarea node object if an event was fired.
2. The number of characters entered in the textarea is assigned to vlen. The pixel-width of the box is assigned to ewidth. If these values have not changed, we do not need to worry about resizing the box (the user could just be moving the cursor). vlen and ewidth are retained as properties of the textarea node object named valLength and boxWidth. These are set after the textarea is resized so resizing will always occur the first time ResizeTextarea is called.
3. The next line resets the textarea height to 0px. This only occurs for non-IE/Opera browsers if content has been deleted or the box width has been changed.
4. The textarea’s scrollHeight value is now assigned to variable ‘h’. Math.min and Math.max are used to ensure the value falls within the minimum and maximum pixel limits defined for this textarea.
5. Before we change the textarea height, we change the CSS overflow property. The scrollbars will only be shown if the content height exceeds the textarea height.
6. We can now modify the textarea height and update the values of valLength and boxWidth.
7. Finally, the function returns true to ensure other textarea event handlers are not cancelled.

Our TextAreaExpander jQuery plugin is complete. However, we need to ensure that the effect is applied to all textarea tags with an HTML “expand” class. At the end of our file, we can add an event which initializes all appropriate textareas after the page has loaded:

// initialize all expanding textareas
jQuery(document).ready(function() {
	jQuery("textarea[class*=expand]").TextAreaExpander();
});

I hope you’ve found this series of tutorials helpful. Feel free to use the auto-expanding textarea plugin in your own projects.

Useful resources:

• Expanding textarea example page
• Example page HTML
• Full jQuery plugin code (jquery.textarea-expander.js)
• Download full code in a ZIP file

See also:

• Part 1: building an auto-expanding textarea
• Part 2: textarea initialization
• How To Develop a jQuery Plugin

Related posts:

1. How to Build an Auto-Expanding Textarea jQuery Plugin, Part 2 Auto-expanding HTML textarea boxes have become popular on many web...
2. How to Build an Auto-Expanding Textarea jQuery Plugin, Part 1 Auto-expanding HTML textarea boxes have become popular on many web...
3. How To Develop a jQuery Plugin Creating a jQuery plugin is easier than you might think....