// 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?

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)

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.

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

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?

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

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.

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?

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…

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?