Inside any function you can access it through the variable: arguments, and it contains an array of all the arguments that were supplied to the function when it was called. It’s not actually a JavaScript array; typeof arguments will return the value: "object". You can access the individual argument values through an array index, and it has a length property like other arrays, but it doesn’t have the standard Array methods like push and pop.

Create Flexible Functions

Even though it may appear limited, arguments is a very useful object. For example, you can make functions that accept a variable number of arguments. The format function, found in the base2 library by Dean Edwards, demonstrates this flexibility:

function format(string) {
  var args = arguments;
  var pattern = new RegExp("%([1-" + arguments.length + "])", "g");
  return String(string).replace(pattern, function(match, index) {
    return args[index];
  });
};

You supply a template string, in which you add place-holders for values using %1 to %9, and then supply up to 9 other arguments which represent the strings to insert. For example:

format("And the %1 want to know whose %2 you %3", "papers", "shirt", "wear");

The above code will return the string "And the papers want to know whose shirt you wear".

One thing you may have noticed is that, in the function definition for format, we only specified one argument: string. JavaScript allows us to pass any number of arguments to a function, regardless of the function definition, and the arguments object has access to all of them.

Convert it to a Real Array

Even though arguments is not an actual JavaScript array we can easily convert it to one by using the standard Array method, slice, like this:

var args = Array.prototype.slice.call(arguments);

The variable args will now contain a proper JavaScript Array object containing all the values from the arguments object.

Create Functions with Preset Arguments

The arguments object allows us to perform all sorts of JavaScript tricks. Here is the definition for the makeFunc function. This function allows you to supply a function reference and any number of arguments for that function. It will return an anonymous function that calls the function you specified, and supplies the preset arguments together with any new arguments supplied when the anonymous function is called:

function makeFunc() {
  var args = Array.prototype.slice.call(arguments);
  var func = args.shift();
  return function() {
    return func.apply(null, args.concat(Array.prototype.slice.call(arguments)));
  };
}

The first argument supplied to makeFunc is considered to be a reference to the function you wish to call (yes, there’s no error checking in this simple example) and it’s removed from the arguments array. makeFunc then returns an anonymous function that uses the apply method of the Function object to call the function specified.

The first argument for apply refers to the scope the function will be called in; basically what the keyword this will refer to inside the function being called. That’s a little advanced for now, so we just keep it null. The second argument is an array of values that will be converted into the arguments object for the function. makeFunc concatenates the original array of values onto the array of arguments supplied to the anonymous function and supplies this to the called function.

Lets say there was a message you needed to output where the template was always the same. To save you from always having to quote the template every time you called the format function you could use the makeFunc utility function to return a function that will call format for you and fill in the template argument automatically:

var majorTom = makeFunc(format, "This is Major Tom to ground control. I'm %1.");

You can call the majorTom function repeatedly like this:

majorTom("stepping through the door");
majorTom("floating in a most peculiar way");

Each time you call the majorTom function it calls the format function with the first argument, the template, already filled in. The above calls return:

"This is Major Tom to ground control. I'm stepping through the door."
"This is Major Tom to ground control. I'm floating in a most peculiar way."

Create Self-referencing Functions

You may think that’s pretty cool, but wait, arguments has one more surprise; it has another useful property: callee. arguments.callee contains a reference to the function that created the arguments object. How can we use such a thing? arguments.callee is a handy way an anonymous function can refer to itself.

repeat is a function that takes a function reference, and 2 numbers. The first number is how many times to call the function and the second represents the delay, in milliseconds, between each call. Here’s the definition for repeat:

function repeat(fn, times, delay) {
  return function() {
    if(times-- > 0) {
      fn.apply(null, arguments);
      var args = Array.prototype.slice.call(arguments);
      var self = arguments.callee;
      setTimeout(function(){self.apply(null,args)}, delay);
    }
  };
}

repeat uses arguments.callee to get a reference, in the variable self, to the anonymous function that runs the originally supplied function. This way the anonymous function can call itself again after a delay using the standard setTimeout function.

So, I have this, admittedly simplistic, function in my application that takes a string and pops-up an alert box containing that string:

function comms(s) {
  alert(s);
}

However, I want to create a special version of that function that repeats 3 times with a delay of 2 seconds between each time. With my repeat function, I can do this:

var somethingWrong = repeat(comms, 3, 2000);

somethingWrong("Can you hear me, major tom?");

The result of calling the somethingWrong function is an alert box repeated 3 times with a 2 second delay between each alert.

arguments is not often used, a little quirky, but full of surprises and well worth getting to know!

I’m going to stick my neck out and say yes, even if you just replace all your table, tr, and td tags with div tags that display like those table elements, it’s better than using HTML tables for layout.

No one is negatively affected by the overuse of structural div tags. The same can’t be said for the use of HTML tables for layout.

A web page that uses nested tables for layout will be difficult to print, difficult to view on a mobile device, and difficult to navigate for users of screen readers. A screen reader application will often stumble over nested HTML tables, announcing something like “table with 5 rows and 2 columns” as it enters the table content and “table end” as it leaves. The same web page using nested div elements can be styled to stack neatly for print and viewing on a mobile device, and screen readers ignore div elements.

By using HTML tables you are implying that the contents of each cell relate to the contents of other cells in 2 dimensions: in the same row and in the same column. On the other hand a div implies no such relation with other div elements. It’s simply content scaffolding, and no meaning is derived from their use.

OK, blindly replacing all table-related tags with div elements may not be the correct approach to the problem, but to say that it is “just as bad” as using HTML tables for layout is wrong. HTML 4.01 defines the div as a “generic language/style container” or more specifically:

The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents. These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content. Thus, authors may use these elements in conjunction with style sheets, the lang attribute, etc., to tailor HTML to their own needs and tastes.

So we can use div elements to define content blocks; sounds like using nested div elements for structuring content is perfectly valid. As long as you don’t use div elements in place of more appropriate ones like headings, paragraphs, blockquotes, lists, and of course, tables for tabular data, then you’re doing fine.

The approach you take when creating a layout using HTML table elements is to first lock-in the layout in HTML before you style your web page. This is wrong and flies in the face of established best practice: separate your presentation from your content.

This is completely different to the CSS layout approach, even when using a lot of div elements. For example, I could wrap all of the content that represents site branding in a div tag, and all of the content that represents additional site information in a another div tag. The fact that, in CSS, I may apply a style that places the site branding at the top of the web page and the additional site information at the bottom, is not important yet. At the layout stage I might do that, or I may use the CSS table-related display values to make them into columns or rows. The markup can be styled in multiple ways because the approach does not lock-in the layout in the HTML markup.

While building my little widget I couldn’t find anything quite like what I was after, so I threw something together with PHP and jQuery, and now I’d like share it with you.

The Server-Side Twitter Proxy

This one’s dead simple. Check it out:

<?php
header("Content-Type: text/xml");
// replace Foobar with your URL-encoded search term
echo(file_get_contents(
    "http://search.twitter.com/search.atom?q=Foobar"));
?>

Here we simply grab the search results from http://search.twitter.com/search.atom?q=Foobar, and return it straight to the client. We also set the content type of the response to text/xml; without this, jQuery doesn’t know to handle the response as an XML DOM Document.

Client-Side Twitter Buzz Widget

With our server-side proxy and jQuery in place, we can start injecting the response into our document. Place a hidden div with the id twitter-buzz somewhere in your document, then include the following JavaScript:

$(function() {
    $.get("twitter-proxy.php", function(data, status) {
      // check for success
      if(status == "success") {
        // check for entries
        if($("entry", data).size() > 0) {   
          // create the list               
          var list = $("<ul>").get(0);
          // iterate through entries
          $("entry", data).each(function(index, entry) {
            // parse out the details of the tweet
            var authorElement = $("author", entry).get(0);
            var authorName = $("name", authorElement).text();
            var authorUri = $("uri", authorElement).text();
            var authorImage = $("link[rel='image']", entry).attr("href");
            var text = $("title", entry).text();
            // add the tweet to our list
            $(list).append("<li><a href=\"" + authorUri + "\">" +
                "<img src=\"" + authorImage + "\" alt=\"" + authorName + "\" />" +
                "</a><span>" + text + "</span>");
          });
          // add the list to the document
          $("#twitter-buzz").append(list);
          // reveal the area
          $("#twitter-buzz").show("slow");
        }
      }
    });
});

This simply grabs the Atom response from the Twitter proxy we created earlier, creates an unordered list of tweets, then adds them to the document. Even if something goes wrong, or the search returns zero tweets, the page won’t be corrupted at all; all we’ll have is a hidden, empty div in the page.

There are certainly improvements that could be made to this widget, such as adding automatically refreshing itself on a timer and automagically adding links for @replies, but I’ll leave adding these features up to you.

And to start with, a neat little function that checks whether a variable is empty, inspired by PHP’s function of the same name:

function empty(data)
{
	if(typeof data == 'undefined' || data === null) { return true; }
	else if(typeof data == 'string' && (data === '0' || data.replace(/^\s+|\s+$/g, '') === '')) { return true; }
	else if(typeof data == 'number' && data === 0) { return true; }
	else if(typeof data == 'boolean' && data === false) { return true; }
	else if(typeof data == 'object')
	{
		if(data instanceof Array && data.length == 0) { return true; }
		else
		{
			var n = 0;
			for(var i in data)
			{
				if(!data.hasOwnProperty(i)) { continue; }
				n++;
			}
			if(n == 0) { return true; }
		}
	}
	return false;
}

So a variable is considered empty if it’s:

• undefined
• null
• a string, and its value is "0", or an empty string, or only whitespace
• a number, and its value is 0
• a boolean, and its value is false
• an array, and it has no values
• an object, and it has no enumerable properties

It works for any kind of variable, for example, used as a condition:

if(!empty(data)) 
{
	//data is not empty
}

You could even pass the return value of another process, thanks (as ever!) to JavaScript’s ability to handle almost anything as an argument:

if(!empty(function()
{
	//do some process and return a value
}))
{
	//return value was non-empty
}

I’ve been finding it particularly useful for validating function arguments, for example a simple shortcut function for getting element references:

function get(id)
{
	return document.getElementById(id);
}

But what if the id parameter is empty, or null, or not there at all? We can check all those possibilities with a single statement, and then handle the situation accordingly:

function get(id)
{
	if(empty(id)) { return null; }
	return document.getElementById(id);
}

And there you go — a neat, simple, and elegant method for validating any kind of variable.

See you soon for another Techy Treasure!

I became a bit of a JavaScript fanboy while writing Simply JavaScript last year, so it was especially thrilling to get to sit down with Douglas Crockford—possibly the world’s biggest JavaScript fanboy—and geek out on our mutual love of JavaScript at Web Directions South 2008 a couple of weeks ago.

One of the most amazing things about JavaScript is that such an elegant, subtly powerful, and forward-looking language could have been born of the fiercely competitive innovation of the so-called “browser wars” of the mid-nineties. Really, all Netscape needed to get ahead was a simple scripting language to run in its browser, but somehow what it ended up building was this amazingly capable little programming language. I asked Douglas Crockford how this happened:

They were really lucky. Given the process that created the language, we should have gotten something much, much worse, because they didn’t do a careful design of requirements. They certainly didn’t give enough time for its design or its implementation. They took a prototype, which was intended just as a proof of concept, and that’s what they shipped. And it had all the problems that you would expect such an implementation to have. That’s what we had. And it was partly on the basis of that implementation that the language got the terrible reputation that it had. And a lot of those defects are still in the language.

In his talk at the conference, Crockford had outlined a number of fundamental security problems that he would like to see fixed as JavaScript moves forward. Problems aside, perhaps JavaScript’s greatest strength as a language is how accessible it is to beginners.

As JavaScript moves forward, I wondered, would we be able to preserve that low barrier to entry that makes JavaScript something you can pick up as your first language and feel confident after just a day or two?

I think so, and I think we need to. I think we would be making a tragic mistake if we didn’t retain the language’s simplicity. Most of the modifications I would like to make in the language would be to make it even simpler. There’s some cruft on it, there are some attractive nuisances in it, which we don’t need, which people become dependant on. We’d be better off without that.

Unfortunately, the thing about the Web is, once something bad gets in it, it takes years to get it out. Ajax didn’t happen until 2005, but all of the technology that we needed to do Ajax was in place and in the field in 2000. Most of that five years was spent removing old browsers from the marketplace until there was enough of an audience on IE6 that Ajax became a viable application platform.

The main set piece of Crockford’s talk was the story of how he became convinced that a second “browser war”—as scary a prospect as that might be—was exactly what would be needed to kick the evolution of JavaScript and the Web back on track.

Fundamentally, Crockford believes, web standards have failed in their attempt to lead innovation on the Web:

For example, CSS2 was un-implementable, and eventually it had to be revised as CSS2.1, which was an attempt to cut CSS2 down to what people were actually able to figure out how to implement. That sequence was totally backwards—or it started backwards, but eventually they got it right. Let’s look at what can actually work and make a standard out of that, and then let everybody catch up with each other. I think that’s a proper role for standards.

What I see happening now with HTML5 is appalling. There is some stuff there that I really like: I really like that they figured out what the rules of HTML parsing are. Brilliant. That’s long overdue. And you can look at any individual feature that they’re doing and say, “Yeah, that makes sense.” But there’s just too much stuff, and there’s not a good set of tradeoffs, there’s not a complexity budget. It’s not motivated by real need, it’s more motivated by what’s shiny in front of a committee.

So, I would like to find a way to inject more discipline into the process, and I think one way to do it is to change it to an evaluation and description process, where we’ll observe what’s going on out in the wild, and document the best of it.

Read my full interview with Douglas Crockford at sitepoint.com.

Image credit: Web Directions

Traditionally, web designers have avoided specifying font sizes in pixels, because the text could not be resized by users who needed a larger font size to read it. Today, every major browser provides a Page Zoom feature that works even with pixel fonts, but one older browser version still in common use does not: Internet Explorer 6.

Pixel font sizes make it easier for the designer to match up the heights of lines of text with the other design elements on the page and achieve a uniform “vertical rhythm”. The same can be achieved with relative font sizes, but the math involved for the designer is considerably trickier.

Jeff argued that users who needed the ability to resize all text could simply upgrade to a current browser version, so for most projects pixel fonts were fair game. He admitted, however, that in projects where he had a little extra time, or where accessibility was a particular concern, he would still use relative font sizes for now.

This approach to the issue didn’t sit well with a number of audience members at the conference.

I asked web accessibility expert Derek Featherstone what he thought about the controversy in an interview the following day. Here’s what he had to say:

I’m still going to use relative units basically until IE6 disappears. And I don’t know when that will be. I know one of the metrics that I’ve used to gauge whether or not I’m going to support a particular browser is when Microsoft basically says they’re not going to support that browser anymore, or whatever piece of technology—whether it’s a browser, or operating system, or whatever it is. When they stop support for it, that’s when I feel much more comfortable eliminating my support for it as well.

[…] the assumption that Jeff makes is that somebody that will require the capability to resize text will choose a better tool, to me that’s still a bit of a jump. I would like to believe that, I really do. I think we have a long way to go, though, in terms of end-user education, because people don’t… there’s a lot of people that use computers, sadly, that … they don’t necessarily know that they can change browsers. They use what’s on their computer and that’s the end of the story.

Now, having said that, we’re in a position now where, I mean, I have three children; they know more about computers at age four, seven, and nine, than probably I did when I was nineteen, just because we didn’t use them when I was younger. So, times are definitely changing. We still have a group of people that did not grow up with computers, and they’re not necessarily as comfortable. Is that our problem? That’s a really good question, and I’m not sure.

Hear or read the full interview on sitepoint.com:

Listen to the interview (16′06, 11.1MB)
Read the transcript

Image credit: Jeff Croft

SitePoint: Right, I thought my first question should be: why did you write Raphaël? What inspired you to write it?

I was doing a FedEx project. Internally at Atlassian, we have FedEx Days when you are given the time to present a project you’ve been working on.

SP: FedEx Day–did you say?

It’s called "FedEx" because you have to deliver something cool. You show it off at a small competition (it’s not about big prizes–it’s more for fun), and of course it should be related to the projects you work on. Because I’m a front end engineer and all the other guys are Java developers, I thought I’d focus on a front end project that will impress people. It’s hard to impress back end developers.

So I thought I’d do something the programmers might not know anything about, and because I’ve had experience with SVG before, it made sense to work with SVG. But, as a front end developer, I’m concerned about creating something that only works in Firefox, so I wanted to create a bridge for VML on IE. My original project was to create a charting application, like a simple line chart. I quickly knocked it up in a day and a half from scratch, showed it, but it didn’t win anything. It didn’t impress people.

SP: Not even a little bit?

Oh, maybe a little bit, but not in general. So I left it for a while. Then we started our 20% projects (just like Google). I decided to pick up this project and extend it a little bit. I got rid of the charting part and turned it into a generic drawing library. Just a bridge between SVG and VML to enable me to do more cool stuff without worrying about browser compatibility.

So at the next FedEx Day, I used this library to create a Skitch-like application. You could take a picture and add things like arrows and ellipses. It even saved the image, but obviously that’s not the hardest part.

Then I started working more on this 20% project. To be honest, I spent more than one day a week: I worked with my laptop on the train — one hour to work and one hour back — two days a week in general, for about a month. Then I decided that it was good enough to release, because it’s better to do so before another developer releases the same thing. So, I released it in the middle of August.

I was stunned by the feedback. I didn’t expect it, to be honest, because I wrote about it on my blog and I usually get about 20 hits per day; but after it was released and made it to the front page of Delicious and Reddit, I got about 8,000 hits per day. It chewed through my bandwidth and I had to create a new domain. It actually started costing me money!

SP: So do you actually use it in your job at Atlassian?

Not yet, but we have plans to integrate it into products for charting and so on, but we haven’t found many use cases for it so far. I Personally think people are a bit afraid of the technology. But I hope it will find a place. It’s still quite raw. So it’s enough to show the concept, have fun, and do some stuff here and there. I’m always finding bugs (especially bugs for IE), so it’s not really, absolutely ready. Well, it’s only one month old.

SP: Where would you like to see it used?

Oh, well, everywhere. World domination is my goal! Of course the first thing people think of is charting, and that’s how I came to this idea, but what I was trying to show was that charting is just one obvious part. You could use it to add effects to a page, like the rotation of an image.

Say, if you’re on Flickr and you want to rotate an image by 90 degrees because you’ve shot the photo on the side. Currently, you press a button, it sends the request to the server, the server does the rotation, sends it back, and you see the rotated picture. Instead, you could use Ajax to just send the basic information: rotate 90% to the right, and on the client you’d have a smooth animation of rotating to the right. That would be a much more pleasant experience to the user for obvious reasons.

It’d be cool, and it’s really easy to implement using Raphaël. Without it, it’s a bit complicated to implement because you have to do a the IE version separately from the version for all other browsers. Actually that’s the whole reason why I built Raphaël — you do something in FireFox and in IE it just works. It’s not absolutely there yet, but it’s getting there.

SP: When I was doing my demo I did notice one snag. In all the non-IE browsers you could do a path, then avoid specifing a fill color, and it would just draw the line. But in IE if you didn’t specify a fill color it would choose white, and it would start attempting to fill in the white.

Yeah, I fixed it.

SP: Oh really? Oh good, fantastic. Because I resorted to setting the fill opacity to 0.

Yeah I noticed it when I looked at the code I thought “Oh, why did you use opacity for the fill?” So I started playing around and thought “Ah yeah, oh, ok.”

SP: Hey thanks!

Yeah, I often find bugs when I test in IE. SVG and VML are absolutely different languages. You can’t really replace one with the other. Sometimes it’s just impossible to do something in IE that’s easy to do in SVG. So I have to find a compromise solution. I can’t have an API for something you can’t do.

For example, in SVG you can rotate an object around a point, while in IE rotation is very wonky; you can’t specify the point. It rotates around some magical center and this center point is very randomly located in the center of… well I don’t know what it’s the center of. I found if you put the object inside a group it will be the center of the group, and it would do some juggling of the objects and they’d be jumping around the place. So I’ve succeeded in getting all the objects to rotate around their centers in all the implementations, but people ask me if they can specify the point of rotation. I say “Oh yeah, I wish.” So, not yet, but maybe later. I wish to do it, but it’s not that easy to do. In SVG it’s easy; it’s built in. But in VML it’s not.

SP: I thought it was maybe a weakness but also a strength of Raphaël, that if you approach the task thinking about how you can doing it using the Raphaël API then you avoid those kinds of problems.

Well maybe, sort of… Well for example I was trying to implement a blur effect and you can do it in Explorer, Firefox, and Opera, but Safari doesn’t support it, surprisingly. As soon as I discover I can’t do something across all browsers I don’t add it to the API. As soon as Safari supports it I’ll put it in. But for now there’s no point because the whole point of Raphaël is that you write it and it just works. Well, I hope it will. In version 1 it should be like that.

It could also help you to understand, you know, if you try to do something and you say “Could I do this cross-browser?” The answer may well be “No.” Of course, when I was creating Raphaël I was trying to cover as much functionality as possible, so if I removed something I removed it for reason. Maybe I’ll find a way to do it later, maybe there’s no way to do it in Internet Explorer.

Sometimes I do some extra calculations in SVG to emulate IE functionality. If I have a choice I’ll probably add the extra calculation into the SVG side because the JavaScript engines are faster in browsers other than IE. If you have to compromise and do a calculation in IE or do a calculation in Firefox, for example, it’s better to do the calculation in Firefox, it will be faster, and the user wont notice. If you do it in IE, it will be slower, and IE users will be upset.

SP: I was talking to some of the developers at SitePoint and a few of us agreed that, down the track, using SVG and VML driven by JavaScript could easily replace Flash.

I wouldn’t say easily. There are some things that Flash is good at, like streaming video and animations. But if you look at, for example, the Google Analytics charts, then I can’t see any reason why it can’t be done with Raphaël.

Yesterday morning I was trying to reproduce the Google charts functionality. I did it on the train; it’s really easy to do, and it works cross-browser straight away. Of course, to do this you need a JavaScript developer in your team who will use a program like Raphaël, or as I mentioned in my talk, excanvas, or dojox. To be honest, I think that Raphaël has the more correct approach. It’s probably not as well-developed yet, but those other libraries don’t approach the usage correctly. They mix canvas, SVG, and VML together, and canvas is completely different. SVG and VML are ideologically the same. Well, to some extent, I guess.

I don’t think it will replace Flash, but if in some task you could use SVG instead of Flash, I’d be happy to see that. Something native, something you can hack–the whole concept of the open web. SVG, and even VML, is more open than Flash. You can hack it up, you can view source, whatever. And, of course, Flash doesn’t work on iPhone. That’s another reason for doing this using native browser technologies. I’m not talking about Raphaël specifically; I think SVG is the way to go for a lot of things.

SP: The issue of accessibility comes up a lot in regards to Raphaël, although when I look at your demos you tend to stick to the ideal of unobtrusive JavaScript anyway.

When you talk about images and charts–and whatever SVG produces, it’s always an image, dynamic or not–it’s always an accessibility issue. At my talk, we spoke about how a screen reader should read SVG; how they should read circles, and ellipses, and combinations of them. Even if you had a good parser that could read the shapes you create on the page, you couldn’t tell what the shapes actually create: the final image. It’s really complicated and very difficult to explain if the user is blind. Like how would you explain the Web Directions logo to a blind user? I don’t think screen readers will ever be able to do this.

So it’s all up to the developer to do it properly. For example, in the case of my charts, I have a table on the page. A screen reader can see that table, and if you have JavaScript turned off, you can see the table. You still have access to the data; it’s not as pretty, not as visually rich, but you can still read it and understand.

I don’t think it’s a problem with SVG, or a problem with Raphaël; I think it’s a generic problem and there are already many articles and books about how to deal with it.

SP: Well thank you very much, really good to talk to you

No worries.

An exciting development in the world of DOM scripting is the W3C Selector API. Up until now, using the DOM Level 2 API, the only way to obtain references to HTML elements in the DOM was to use either document.getElementById or document.getElementsByTagName and filter the results manually. With the rise of CSS, JavaScript programmers asked the obvious question, “If the browser has a really fast way of selecting HTML elements that match CSS selectors why can’t we?”.

The Selector API defines the querySelector, and querySelectorAll methods that take a CSS selector string and return the first matching element or a StaticNodeList of matching elements, respectively. The methods can be called from the document object in order to select elements from the whole document or a specific HTML element to select only from descendants of that element.

To illustrate how much easier your life will be using the Selector API, have a look at this example HTML:

<ul id="menu">
  <li>
    <input type="checkbox" name="item1_done" id="item1_done"> 
    <label for="item1_done">bread</label>
  </li>
  <li class="important">
    <input type="checkbox" name="item2_done" id="item2_done"> 
    <label for="item2_done">milk</label>
  </li>
  <!-- imagine more items -->
</ul>

Our task is to check all the checkboxes for the list items that have the class “important”. Using only DOM Level 2 methods we could do it this way:

var items = document.getElementById('menu').getElementsByTagName('li');
for(var i=0; i < items.length; i++) {
  if(items[i].className.match(/important/)) {
    if(items[i].firstChild.type == "checkbox") {
      items[i].firstChild.checked = true;
    }
  }
}

Using the new selector API we can simplify it to this:

var items = document.querySelectorAll('#menu li.important input[type="checkbox"]');
for(var i=0; i < items.length; i++) {
  items[i].checked = true;
}

That’s much nicer! The methods also support selector grouping — multiple selectors separated by commas. The Selector API is working right now in Safari 3.1, the Internet Explorer 8 beta, and Firefox 3.1 alpha1. Opera is also working on adding support for the API.

If you’re a fan of one of the many JavaScript libraries available you’re probably thinking “But, I can already do that.” One of the great examples of the benefits of using JavaScript libraries are the implementations of CSS selectors found in nearly all of them. Recently we’ve seen huge speed improvements in the CSS selector implementations because library authors have been sharing their techniques. So what’s the benefit of using the Selector API? In a word: speed — native implementations are fast! And better yet all of the javascript libraries are poised to benefit. jQuery and Prototype are already developing implementations that make use of the Selector API, while The Dojo Toolkit, DOMAssistant and base2 have already made use of it.

There’s a reason why those 3 libraries were the first ones to benefit. Kevin talked about the potential problem back in Tech Times #190 in the article titled “Is Your JavaScript Library Standards Compliant?” The Selector API makes use of standard CSS selectors so if the browser doesn’t support a certain selector then you won’t be able to use it. The libraries that have already taken advantage of the Selector API are those that only supported standard CSS selectors. For those libraries, supporting the API was (almost) as easy as doing this:

if(document.querySelector) {
  return document.querySelector(selector);
} else {
  return oldSelectorFunction(selector);
}

Libraries that support custom selectors will have more work to do. The risk is that if you have used custom CSS selectors extensively in your project, it may be difficult for your chosen library to pass on the speed benefit to you because the library will have to use its default selector instead of the Selector API. If the library somehow rewires its custom selectors so that they can utilize the Selector API, the secondary risk is increased code bloat.

Hopefully the Selector API will encourage the use of standard CSS selectors over custom ones. In fact if uptake of the new browser versions is good and the performance benefits of the new Selector API are compelling enough we could see custom selector functionality moved to supplementary libraries you only need to use in case of legacy compatibility requirements.

Dean Edwards’ base2 Library has the nicest implementation in my opinion. Base2 implements the API exactly, which means you can write your JavaScript using standard the standard API methods — Base2 only creates custom querySelector and querySelectorAll methods if the browser doesn’t support them. You can’t get any cleaner than that. Base2 does, however, implement the non-standard “!=” attribute selector in it’s custom selector function, apparently because of peer pressure, so it’ll have to have points deducted for that.

Regardless of whether you use a JavaScript library or roll your own, the new browser implementations of the Selector API give everyone an instant speed boost. We all win, hooray!

Image credit: Yogi

If you were to guess who recently made that statement you’d be forgiven for thinking it came from the Opera, Safari, or Firefox team; they have always seemed to be the most standards-conscious browser vendors. In fact, this quote comes from Doug Stamper of Microsoft, regarding Internet Explorer 8.

It seems the very thing web designers have been asking for—mature support for CSS2.1 across all major browsers—is actually about to happen. Back in Tech Times #185, I wrote about what this would mean to web designers in Table-Based Layout Is The Next Big Thing. In short, I said that CSS tables would become the best tool for CSS page layout.

There were mixed reactions to that article, particularly on the point of row and column spans. HTML tables let you create cells that span multiple rows or columns, but CSS tables don’t provide that same freedom.

Well, in my research for an as yet unannounced, potentially controversial book on CSS, I’ve figured out how to simulate row and column spans in CSS tables. Rather than make you wait for the book, I thought I’d show you this useful technique right away!

Nothing Up My Sleeve…

If you’ve had experience building layouts using HTML tables, you’ll be familiar with the use of the colspan and rowspan attributes of the td element. These attributes offer complex possibilities to a simple table, enabling cells to span columns and rows.

CSS tables lack any concept of row or column spanning, making it trickier to use one single layout structure than what might have been possible when using tables. However, similar layouts can be achieved by using nested CSS tables.

Of course, nested tables are not a perfect solution. When you want to match the dimensions of cells across nested tables, for example, things can get messy in a hurry, and the extra <div> tags really start to add up.

As it turns out, it’s also possible to simulate row and column spanning using absolute positioning of table cells, in many cases. In this example, we’ll make the second cell of the first row of a table span both rows of the table (as if it had a rowspan of 2). First, let’s take a look at the HTML code:

<div class="tablewrapper">
  <div class="table">
    <div class="row">
      <div class="cell">
        Top left
      </div>
      <div class="rowspanned cell">
        Center
      </div>
      <div class="cell">
        Top right
      </div>
    </div>
    <div class="row">
      <div class="cell">
        Bottom left
      </div>
      <div class="empty cell"></div>
      <div class="cell">
        Bottom right
      </div>
    </div>
  </div>
</div>

You’ll notice that we’ve wrapped our table div in an extra div with a class of "tablewrapper". This extra div is needed to provide a CSS positioning context—which we create by giving it relative positioning:

.tablewrapper {
  position: relative;
}

According to the CSS spec, we should be able to simply apply relative positioning to the table div, but current browsers don’t seem to support this.

Sleight of Hand and Absolute Positioning

Now, we can use absolute positioning to control the size and position of the div with class "rowspanned cell":

.cell.rowspanned {
  position: absolute;
  top: 0;
  bottom: 0;
  width: 100px;
}

With the top and bottom properties both set to zero, the cell will stretch to fill the full height of the table, simulating a row span. Depending on the needs of your layout, you could use different values for top and bottom, or even set the cell’s height directly to achieve other row-spanning layouts.

You also need to specify the width of the cell. Usually, the easiest way to do this is just to set its width property, but depending what you know of the dimensions of surrounding table cells, you could also do this by setting left and right.

Since the positioned cell doesn’t actually span multiple rows of the table, the table must still contain a corresponding cell in each of the other rows. These cells are simply empty placeholders, though; note the div with class "empty cell" in the HTML code above. The function of this cell is to hold open the space that will be occupied by the “spanned” cell, so we must ensure its width matches the width we specified for the "rowspanned cell":

.cell.empty {
  width: 100px;
}

And that’s all there is to it! To complete the style sheet for this example, we need only set the appropriate display property values, and add some borders so we can see what’s going on:

.tablewrapper {
  position: relative;
}
.table {
  display: table;
}
.row {
  display: table-row;
}
.cell {
  border: 1px solid red;
  display: table-cell;
}
.cell.empty
{
  border: none;
  width: 100px;
}
.cell.rowspanned {
  position: absolute;
  top: 0;
  bottom: 0;
  width: 100px;
}

In essence, by using absolute positioning we are telling the browser, “Let me handle the layout of this table cell—you take care of the rest.” Here’s what the results look like:

Try it for yourself. This example works in all major browsers except for Internet Explorer 7, and also works in the current IE8 Beta 2 release.

What do you think? Can you see yourself switching to CSS tables for layout as your Internet Explorer users make the move to IE8?

Now, demos involving circles and squares are fine, but I wanted to create an example that demonstrated a legitimate, practical use of vector graphics. So how about real-time statistics measurement? Here’s a screenshot of my Current Sprocket Usage line graph that plots real-time “sprocket” usage levels. Best of all, it was a snap to make.

The HTML is simple; we just need a heading and container to hold our canvas — a div element:

<h1>Current Sprocket Usage: <span id="readout"></span></h1>
<div id="graph"></div>

To start we have to generate a new graphics canvas. I always like to place all my code within an object definition in order to create a separate namespace, so we’ll start with the following code:

var SpGraph = {
  init : function(){
    SpGraph.graph = Raphael("graph", 400, 200);
    SpGraph.graph.rect(0, 0, 390, 110, 10).attr("fill", "#000");
  }
}

window.onload = function () {
  SpGraph.init();
};

Using the window.onload event we call our SpGraph.init method. Within this method we create our canvas using Raphael("graph", 400, 200). The first argument is the ID of our container element, the other two represent width and height. We store the returned canvas object in our SpGraph.graph property. With the next line we create a rectangle and set some attributes:

SpGraph.graph.rect(0, 0, 390, 110, 10).attr("fill", "#000");

The rect method allows us to draw a rectangle specifying the x coordinate, y coordinate, width, height, and optionally a corner radius. Notice that we’ve also chained a call to the attr method to set the fill color. All Raphaël graphic objects support the attr method and there’s a range of attributes you can set. Raphaël supports chaining all its methods, which we will take advantage of soon. Our effort so far has resulted in this lovely black rectangle with rounded corners.

Now lets add stripes! To do this we add the following loop to the SpGraph.init method:

for(var x = 10; x < 110; x += 10) {
  var c = (x > 10) ? "#333" : "#f00";
  SpGraph.graph.path({stroke: c}).moveTo(0, x).lineTo(390,x);
}

The loop executes 10 times drawing a line each time; a red line for the first one and a gray line for the others. The Raphaël path method initializes the path mode of drawing, returning a path object. It doesn’t actually draw anything itself; you have to use the path object methods, which are chainable. The moveTo method moves the drawing cursor to the specified x and y coordinates and the lineTo method draws a line from the cursor point to the point specified. The result is the stripey background below:

So now we have to draw the actual graph line. The vertical axis (represented by the stripes) is the percentage usage level. The horizontal axis will represent time in 10 pixel increments. In the real world each update of the graph would be obtained via an Ajax call, say every 5 seconds, but here I just create random values and update the graph every second. Once again, we use the path method to draw a 5 pixel wide line.

We initialise the path and store the reference to it in the SpGraph.path property like so:

SpGraph.path = SpGraph.graph.path({
    stroke: "#0f0",
    "stroke-width": 5, 
    "fill-opacity": 0
}).moveTo(20, 110);

Every update, we extend the line using the lineTo method like so:

SpGraph.path.lineTo(20+SpGraph.updates*10, 110-perf);

perf is a random value between 0 and 100. The SpGraph.updates property is a simple counter that allows us to control how many updates before the line is reset. The counter value is also used to plot the location of the line on the horizontal axis. After 35 updates the line is reset by removing it, using the SpGraph.path.remove method, and starting a new one.

So the whole script looks like this:

var SpGraph = {
  init : function(){
    SpGraph.graph = Raphael("graph", 400, 200);
    SpGraph.graph.rect(0, 0, 390, 110, 10).attr("fill", "#000");

    for(var x = 10; x < 110; x += 10) {
      var c = (x > 10) ? "#333" : "#f00";
      SpGraph.graph.path({stroke: c}).moveTo(0, x).lineTo(390,x);
    }
    SpGraph.startPath();
    SpGraph.updateGraph();
  },
  startPath : function() {
    if(SpGraph.path) {
      SpGraph.path.remove();
    }
    SpGraph.path = SpGraph.graph.path({
        stroke: "#0f0",
        "stroke-width": 5, 
        "fill-opacity": 0
    }).moveTo(20, 110);
  },
  updateGraph : function() {
    if(SpGraph.updates++ < 36) {
      // imagine this value comes from an ajax request
      var perf = Math.floor(Math.random() * 100);
      SpGraph.path.lineTo(20+SpGraph.updates*10, 110-perf);
      document.getElementById('readout').innerHTML = perf+'%';
    } else {
      SpGraph.updates = 0;
      SpGraph.startPath();
    }
    SpGraph.timer = setTimeout("SpGraph.updateGraph();",1000);
  },
  updates : 0
}
window.onload = function () {
  SpGraph.init();
};

Don’t forget to see it working in the demo. OK, so maybe a sprocket usage graph isn’t exactly the legitimate, practical example I promised, but at least you got a look at what you can achieve with Raphaël with only a little effort. The documentation on the site isn’t complete, but it’s not too difficult to work out anyway. Why don’t you have a go yourself? Quick, Simple, cross-browser compatible, vector graphics on the web has never been easier.