To experiment with these methods and events, you’ll need to be running either IE8, Firefox 3 or the WebKit Nightlies. Opera 9+ provides support as well, but they use an older version of the spec which required the postMessage method to be called from the document object instead of the window object.

There are two key steps involved with HTML5 Cross Document Messaging. The first is posting the message. You do this by calling the window’s postMessage() function. The postMessage function takes two arguments: the message to be sent, and the target origin.

Then, to receive the message in the other window, you need to watch for the window’s message event using window.addEventListener or something similar. To help show how this works, I’ve set up an example for you to see here. In my example, both the sending window and the receiving window are located within the same domain (timkadlec.com), but as long as you have a reference to a window, you can communicate cross domain the same way.

Walking the Code

Take a look at the source code and you’ll see that I’m simply using one window (window A) to open the other (window B) so that I have a reference to it. Window B contains two buttons that when clicked, use the postMessage method to post a message back to window A, like so:

• window.opener.postMessage(‘John Smith’, ‘http://www.timkadlec.com’);

We use window.opener to get our reference to window a, and then call the postMessage function and send the message ‘John Smith’ back to it. We specify that the origin is timkadlec.com in the targetOrigin argument.

Now back in window A, we need to prepare to receive the message. To do so, we look for the message event.

• window.addEventListener(‘message’, receiver, false);

As you can see above, I’m using addEventListener to listen for the message event, and once the event occurs, we call the receiver function.

1. function receiver(e){
2. if (e.origin == ‘http://www.timkadlec.com’) {
3. if (e.data == ‘John Smith’) {
4. alert(e.data);
5. e.source.postMessage(‘Valid User’, e.origin);
6. } else {
7. alert(e.data);
8. e.source.postMessage(‘FAIL’, e.origin);
9. }
10. }
11. }

In the receiver function, we verify that the origin of the event is timkadlec.com (line 2). This is highly encouraged, as it ensures that we only receive messages from domains we are expecting to hear from. If you skipped this step, any domain could freely affect your page, and that could get a bit messy.

Then, we use the event’s data property to retrieve the message that was sent. Based on the message received, we then use the source property of the event to obtain a reference to the window that sent the message. Then, again using the postMessage method (lines 5 and 8), we send a message back to window A.

This is a pretty straightforward example, and is really just meant to demonstrate how easy it is to post messages back and forth between documents. There’s another good example up that makes use of iframes if you want to see another example of cross document messaging.

Some Security Considerations

Hopefully you can see that cross document messaging is both simple, and potentially quite useful for things like widgets, or authentication. However, there are some security risks if you don’t take the time to double check a few things. First, like mentioned before, you should always double check the origin of the sent message. You don’t want to be just accepting messages from anyone…that’s kind of the reason cross-site scripting isn’t allowed in the first place.

Secondly, it is possible to use the asterisk in the targetOrigin argument to allow your message to be posted to any domain. However, you should be sure to never use the asterisk symbol when sending confidential information. In those cases, you should be specifying the targetOrigin specifically so that you can guarantee that only the intended recipient gets the information.

A Quick Look at Attributes

We’ve already seen how to set up the canvas element in HTML:

You’ve probably noticed that we’ve included an id attribute on our canvas element to make it easier for us to access the element in our Javascript. You can also apply other standard attributes like class, title or tabindex. Two other attributes, height and width, will also be used fairly regularly.

You can define the height and width as attributes in the canvas element, or you can use CSS to define the dimensions of your element. If you use CSS, however, your canvas will scale to meet the dimensions you define instead of simply resizing the area. Neither height nor width are necessary, however. If you choose to not define the size of the canvas element, then it defaults to a size of 300 pixels wide by 150 pixels high.

Roll Up Your Sleeves…

All of this so far has been pretty easy…but also boring. The canvas element’s real power, of course, is the ability to use Javascript to manipulate it. To do so, we have to get a rendering context using the getContext() function. The rendering context is what allows us to actually manipulate the content in the canvas element. The function is straight forward and easy to use:

1. var canvas = document.getElementById(‘canvas’);
2. var context = canvas.getContext(’2d’);

Currently, “2d” is the only defined context that we can obtain. In the future, it is not unreasonable to expect to see that expand and include support for a three dimensional drawing context. Of course in a real-world setting you’ll want to check to make sure the browser supports the getContext method in the first place. The canvas element is still relatively new and there will be a fair amount of browsers that will not support it.

The One and Only

Now that we have a rendering context, let’s make use of it by starting to draw something to the canvas. The canvas element only natively supports one shape and that is the rectangle. Don’t panic….you’ll see later that there are plenty of methods available for us to create everything from a basic circle to very complex abstract shapes.

For now though, we’ll keep it simple and just make a rectangle. We have three functions that are available to use for this: fillRect(), strokeRect(), and clearRect(). The functions do pretty much exactly what you would think based on their names. fillRect() draws a filled rectangle; strokeRect() draws a rectangle with border, or stroke, around it; and clearRect() clears the area and makes a fully transparent rectangle. To make it even more simple, each of the functions takes the exact same parameters. Let’s take for example the following line of code:

• context.fillRect(0,0,50,75);

As you can see, the function takes four parameters. The first two define the starting point of the shape, the x and y coordinates. Thankfully the coordinates follow common sense. The origin or (0,0) is the top left of the canvas element. So (0,10) would be at the top and 10 pixels from the left.

The next two parameters are the width and height of the canvas element. In this case, I made a rectangle that is 50 pixels wide and 75 pixels high. So the result of the above line of code is a 50 pixel by 75 pixel, filled rectangle in the top left corner of the canvas element. To get a good idea of the results of each of the rectangle functions, we’ll use the following code (we’ve also set the height and width attributes on our canvas element to 125 pixels each) :

1. context.fillRect(0,0,50,50);
2. context.clearRect(25,25,50,50);
3. context.fillRect(50,50,50,50);
4. context.strokeRect(75,75,50,50);

The result, as you can see here, is four overlapping rectangles. Remember, you’ll need Firefox (1.5+), Safari, or Opera (9+) to view it. As you can see, the clear rectangle clears out the area it covers. The stroke rectangle, on the other hand, doesn’t clear out the area, so you can see the filled rectangle through it.

Next Time

Next time around, we’ll start to look at some of the other functions available, and how we can use those functions to start making a variety of shapes…not just simple rectangles. To wet your appetite a bit in the meantime, have a look at another great example of how the canvas element can be used.

What Is It, and Who Supports It?

The canvas element was originally implemented in Safari, and then became standardized in the HTML5 specification. The element allows developers to dynamically draw onto a blank ‘canvas’ in a website. Thankfully, you don’t have to wait to play around with this element. Currently, you can find support for it in Firefox (version 1.5 and newer), Safari, or Opera (version 9 and newer). In addition, you can twist IE’s arm a bit thanks to Google and Mozilla. Google has created ExplorerCanvas, a script that allows your canvas scripts to work in IE. For more intensive applications, Mozilla created has created an ActiveX plugin for IE to bring canvas support to the widely used browser. So, there’s little reason why you can’t start using it today….Google Maps does!

Unfortunately, there is some discrepancy in the way browsers support the canvas element right now. For example, in Safari, the canvas tag works a lot like the img tag…it doesn’t require a closing tag. In Safari, you can close the element like so:

In Firefox, however, the canvas element requires a closing tag:

The problem comes in with alternate content. In Firefox, we can simply throw our alternate content in between the opening and closing canvas tags. If the browser doesn’t support the canvas element, then the alternate content displays. In Safari, the content displays regardless. There are a few ways you can hack around this however, including this one presented by Matt Snider.

Why It’s Cool

The canvas element is not meant for static images…though it can certainly be used to do that. The real power of it comes when we make use of Javascript to manipulate the canvas element and create dynamic visualizations like data charts and graphs, interactive diagrams and games. In fact, there are a couple impressive Javascript game recreations that have already been developed that make use of the canvas element. You can already play Mario Kart, Super Mario, and an incredibly addicting game called Ooze.

The canvas element is a great example of where implementation precedes standardization. Safari implemented it, then Firefox and Opera caught on, and now the WHAT-WG is incorporating it into the HTML5 specification. Once implemented, it provides us with a standardized, cross-browser means to dynamically display data and react to user events in a way that previously required Flash.

What’s Coming Up

Next time around, we’ll start to look at the canvas element in more detail including the attributes available. We’ll also start diving into some Javascript and some of the methods provided by the DOM to interact with the canvas element.

Some Background

There’s been a lot of talk in the Javascript community over the past 9 years or so about the development of ECMAScript 4, what was to be the foundation for what was being called Javascript 2. It was a controversial and fairly dramatic change from ECMAScript 3 (Javascript). There was going to be support for classes, inheritance, type annotations, namespaces…the whole flavor of the language was going to dramatically change.

ECMAScript 4 was being developed primarily by Adobe, Mozilla, Opera and Google and was primarily based on the features those organizations wished to implement. Others, including Microsoft and Yahoo, found the proposed changes in ES4 to be to dramatic, and instead wanted to implement minor changes and bug fixes to ES3, labeling it ES3.1 instead.

What Happened?

Obviously with division among such major organizations, something was going to have to give. So, at a recent TC39 meeting (the committee in charge of developing the ECMAScript standard) met and a resolution was met. The two sides would merge their ideas together with a new committed focus to ensuring simplicity in the new changes to the language…enter ECMAScript Harmony. In an email, Brendan Eich of Mozilla laid down the 4 primary goals of ECMAScript Harmony:

1. Focus work on ES3.1 with full collaboration of all parties, and target two interoperable implementations by early next year.
2. Collaborate on the next step beyond ES3.1, which will include syntactic extensions but which will be more modest than ES4 in both semantic and syntactic innovation.
3. Some ES4 proposals have been deemed unsound for the Web, and are off the table for good: packages, namespaces and early binding. This conclusion is key to Harmony.
4. Other goals and ideas from ES4 are being rephrased to keep consensus in the committee; these include a notion of classes based on existing ES3 concepts combined with proposed ES3.1 extensions.

What Does It Mean?

Well, for one, it means that the series of posts I had started on Javascript 2.0 are now completely worthless…and no…I will not reimburse you for the time spent reading them.

But far more importantly, it means that progress should speed up immensely. (There are ES4 proposals from 1999.) The plan appears to be to implement certain de facto standards rather quickly. For example, getters and setters are already implemented in each of the major browsers except for IE, and they will be thrown into the ES Harmony specification. (Which, by the way, brings up the interesting situation where implementation precedes specification, something that occurs often on the web and something you’ll probably see me talk more about in the future.)

Meanwhile, ActionScript 3.0 was already built to reflect the ECMAScript 4 proposed specifications…so it would appear they’re kind of left a bit high and dry. It sounds as though they are definitely committed to keeping in line with specifications, and that they plan on implementing new features laid out in the newly developed specification. They are also going to continue to keep their current features, like classes and type annotations, available in their language…think of it as an extension to the ECMAScript standard.

My Thoughts

All in all, I think the outcome is positive. ES4 had been taking forever to get going, and ES3.1 hadn’t been sounding like it would do much besides fix bugs. Now, we’ll have a new implementation soon and while it won’t have the same dramatic changes ES4 had in mind, there will be some interesting new features being added.

While I would’ve enjoyed some of the new features, Javascript gets to maintain a lot of flexibility here. ES4 would’ve tightened that up a bit, and I still haven’t really made up my mind on whether that would’ve been a good thing or not.

It’s also quite encouraging to see so many major players working together. Microsoft, Yahoo, Google, Mozilla, Opera and Adobe all working together in harmony. (I apologize for the pun…it was just there, and I decided to go with it.) One can only imagine having these organizations working together will ensure a high quality specification, and also lead to faster implementation of the spec.

Around the Web

This is certainly a huge development, and there has been no shortage of postings about it. There’s a lot of high quality discussion going on by some major players in the world of Javascript and ActionScript, and I highly recommend checking them out.

• Bredan Eich’s Original Email
• John Resig: ECMAScript Harmony
• Mike Chambers: ActionScript 3 and ECMAScript 4
• Douglas Crockford: The Only Thing We Have To Fear Is Premature Standardization
• Alex Russell: Thoughts on Harmony

Traditionally, Javascript is a loosely-typed language, meaning that variables are declared without a type. For example:

Since Javascript is loosely typed, we can get away with simple ‘var’ declarations…the language will determine which data type should be used. In contrast, Javascript 2.0 will be strongly typed, meaning that type declarations will be enforced. The syntax for applying a given type will be a colon (:) followed by the type expression. Type annotation can be added to properties, function parameters, functions (and by doing so declaring the return value type), variables, or object or array initializers. For example:

NOTE: There has been some confusion about enforcing type declarations so I thought I’d try to clear it up. Enforcing type declarations simply means that if you define a type, it will be enforced. You can choose to not define a type, in which case the variable or property defaults to a type of ‘Object’ which is the root of the type heirarchy.

Type Coercion

Being a strongly typed system, Javascript 2.0 will be much less permissive with type coercion. Currently, the following checks both return true:

In both cases, the language performs type coercion…Javascript automatically makes them the same type before performing the check. In Javascript 2.0, both of those statements will resolve to a ‘false’ value instead. We can still perform comparisons like those above; we just need to explicitly convert the data type using type casting. To perform the checks above and have them both resolve to ‘true’, you would have to do the following:

While adding a strongly typed system does make the language a bit more rigid, there are some benefits to this change, particularly for applications or libraries that may be worked with elsewhere. For example, for a given method, we can specify what kinds of objects it can be a method for using the special ‘this’ annotation. I’m sure there are many of you who just re-read that sentence and are scratching your heads trying to figure out what the heck that meant. An example may help:

The method above accepts two arguments, an int and a string. The first part of the parameters (this:myObject) uses the this: annotation to state that the function can only be a method of objects that have the type of ‘myObject’. This way if someone else is using code we have created, we can restrict which objects they can use that method on, preventing it’s misuse and potential confusion.

Union Types

We can also use union types to add a bit of flexibility. Union types are collections of types that can be applied to a given property. There are four predefined union types in Javascript 2.0:

In addition, we can set up our own union types based on what we need for a particular property:

One final thing I would like to mention is that in contrast to Java and C++, Javascript 2.0 is a dynamically typed system, not statically typed. In a statically typed system, the compiler verifies that type errors cannot occur at run-time. Statically typing would catch a lot of potential programming errors, but it also severely alters the way Javascript can be used, and would make the language that much more rigid. Because JS 2.0 is dynamically typed, only the run-time value of a variable matters.

Whether you like the new features being proposed, think they’re silly and unnecessary, or have no idea what the heck I am talking about, I think it’s important to have a firm grasp on some of the changes being proposed. Doing so will help you to better understand both sides of the debate, and also help to prepare you for when Javascript 2.0 becomes available for use.

There’s far too many changes and fixes to discuss them in one post, so this will be an ongoing serious of posts. I’ll be taking a look at what the new language provides us and why. Hopefully by taking a closer look at all the changes, we can get a better feel for how those changes affect both web developers and javascript in general. First though, we should take a quick look at how Javascript got to this point, and the reasoning behind the changes beings suggested in Javascript 2.0.

Once Upon a Time…

Javascript has been around since 1995, when it was debuted in Netscape Navigator 2.0. The original intent was for Javascript to provide a more accessible way for web designers and non-Java programmers to utilize Java applets. In reality though, Javascript was used far more often to provide levels of interactivity on a page…allowing for the manipulation of images and document contents.

Microsoft then implemented Javascript in IE 3.0, but their implementation varied from that of Netscape�s and it became apparent that some sort of standardization was necessary. So the European Computer Manufacturers Association (ECMA) standards organization developed the TC39 committee to do just that.

In 1997, the first ECMA standard, ECMA-262, was adopted. The second version came along a bit later and consisted primarily of fixes. In December of 1999, when the third version rolled out, the changes were more drastic. New features like regular expressions, closures, arrays and object literals, exceptions and do-while statements were introduced, greatly adding value to the language. This revision, ECMAScript Edition 3, is fully implemented by Javascript 1.5, which is the most recently released version of Javascript.

Like ECMAScript 3, the proposed ECMAScript 4 specification will provide a very noticeable change in the language. As it stands now, Javascript 2.0 will be featuring, among other changes, support for things like scoping, typing and class support.

Let the Debate Begin

While some of the changes are bug fixes, the justification for the major revisions appears to be largely based on providing better support for developing larger-scale applications. With the growing popularity of AJAX, and the rise of RIAs, Javascript is now being used for much larger-scale apps than it was ever intended for. The proposed changes to ECMAScript 4 are intended to help make development of those kinds of apps easier by making the language more disciplined and therefore making it easier for multiple developers to work on the same application.

This is where the debate starts….how much do we need these revisions? Technically, we can implement a lot of the same kinds of structures using the language as it stands currently. The proposed changes are aimed at making that easier, but there are some people who worry about the effect this may have on what is currently a very expressive and lightweight language.

Which group is correct? Are the changes going to make our lives as Javascript developers easier, or force us to lose a lot of what makes Javascript such an attractive scripting language to use today? I think the only way to really judge how the changes will affect us is to take a closer look at the changes themselves and see both the good and the bad.

The Selectors API allows us to utilize CSS (1-3) selectors to collect nodes from the DOM. This is actually quite a common enhancement in a lot of Javascript libraries….CSS selectors are a very efficient and powerful way to quickly look up nodes, and since most people are familiar with CSS syntax, it is very user friendly. The Selectors API offers native browser support for CSS selectors using the querySelector and querySelectorAll methods.

The querySelector method as defined by the W3C returns the first element matching the selector, or if no matching element is found, it returns a null value.

The querySelectorAll method returns a StaticNodeList of all elements matching the selector, or if no matching elements were found, it returns a null value. For anyone familiar with DOM traversal, you are probably familiar with NodeLists. NodeLists are returned by methods like getElementsByTagName. The main difference between the StaticNodeList and a NodeList, is that if you remove an element from the document, a NodeList is also affected and therefore the indexes of the NodeList are altered. A StaticNodeList, however, is not affected…hence the Static part.

The querySelector and querySelector methods are very easily used:



In addition to calling the methods with a single selector, you can also pass groups of selectors seperated by commas, like so:



The first line above would return all elements with a class or error or a class of warning. The second line would return the first element with a class of either error or warning.

You can see the advantage of having native support for the SelectorAPI by taking a look at some test results. SlickSpeed runs the test cases using the popular Javascript libraries Prototype, JQuery and ext as well as by using the Selectors API and the results are substantially quicker using the Selectors API. To run the native support test, you will need to go grab the WebKit nightly build. If you don’t want to do that, Robert Biggs ran the test in various browsers and has the test results up.

Getting More Detailed with Compounds

So far, we haven’t dealt with any compound location paths…each of our expressions has just gotten nodes that are direct children of the context node. However, we can continue to move up and down the document tree by combining single location paths. One of the ways we can do this (and this should look quite familiar to anyone who has moved through directories elsewhere) is by using the forward slash ‘/’. The forward slash continues to move us one step down in the tree, relative to the preceding step.

For example, consider the following:

The expression above will first go to the root node thanks to our ‘//’. It will then get any div elements that are descendants of the root node. Then, we use the forward slash to move down one more level. Now we are saying to get all h3 elements that are direct descendants of one of the div elements that was returned. Finally, we once again use our forward slash to move down one more level, and tell the expression to return any span elements that are direct descendants of the h3 elements we already found.

In addition, we can use the double period ‘..’ to select an elements parent nodes. For example, if we use an expression like ‘//@title’, we will get all title attributes in the document. Let’s say that what we actually wanted, is all elements in the document that have title attributes. Using the parent selector (..), we can do just that. The expression ‘//@title/..’ first grabs all title attributes. Then the double period tells the expression to step back up and grab the parent node for each of those title attributes.

This is a pretty handy little feature. We can use the double period to select sibling elements by doing something like ‘//child/../sibling’ where child is the child element, and sibling is the sibling element we are looking for. For example, ‘//h3/../p’ would get all p elements that are siblings of h3 elements.

Finally, we can use a single period ‘.’ to select the current node. You will see this become useful when we introduce the use of predicates.

Speak Of the Devil

Each expression we’ve seen returns a bunch of nodes matching criteria. Occasionally, we will want to refine this even further. We can do that using predicates, which are simply Boolean expressions that get tested for each node in our list. If the expression is false, the node is not returned in our results; if the expression is true, the node is returned.

Predicates use the typical Boolean operators, ‘+’, ‘<’, ‘>’, ‘<=’, ‘>=’, ‘!=’, ‘and’ and ‘or’. As promised, the single period becomes much more useful when combined with predicates. For example, we can grab all h3 elements that have a value of “Yaddle” by using the following expression:

The dot tells the expression to check for the value of that current node. If the value equals “Yaddle”, the h3 will be returned to us. Let’s take a look at another example, one maybe a bit more practical. Let’s say you have a calendar of events, and all you want to retrieve all the events that occurred between 2005 and 2007. Being the smart developers we are, we wrapped all the event years in a span with a class of year, like so:

Getting all the year spans where the value is between 2005 and 2007 is easy. We can simply do this:

Ok…granted, at first glance that is pretty ugly, so let’s break it down.

1. //span – Get all span elements
2. [@class="year"] – Make sure the only span elements we grab have a class of ‘year’
3. [.>=2005 and .<=2007] – Make sure the value of span is between 2005 and 2007. We use the ‘<=’ and ‘>=’ operators versus the ‘<’ and ‘>’ operators because we want to also return values in the years 2005 and 2007.

Making sense out of all the slashes and brackets can take some getting used to, so don’t be discouraged if it takes you awhile before you can make sense out of what is happening there. Once you get more familiar with the syntax used, you will find you can create some really robust checks in one line of code that would have taken numerous iterations using DOM methods.

This is going to be a multi-post series, as there is just so much you can accomplish by using XPath expressions that if I tried putting it into one post, no one would have the time to sit and read the whole thing.

What is XPath?

Any of you out there who are familiar with XSLT will no doubt be familiar with the XPath language. For the rest of you, XPATH is used to identify different parts of XML documents by indicating nodes by position, relative position, type, content, etc.

Similar to the DOM, XPath allows us to pick nodes and sets of nodes out of our XML tree. As far as the language is concerned, there are seven different node types XPath has access to (for most Javascript purposes the first four node types will most likely be sufficient):

1. Root Node
2. Element Nodes
3. Text Nodes
4. Attribute Nodes
5. Comment Nodes
6. Processing Instruction Nodes
7. Namespace Nodes

How Does XPath Traverse the Tree?

XPath can use location paths, attribute location steps, and compound location paths to very quickly and efficiently retrieve nodes from our document. You can use simple location paths to quickly retrieve nodes you want to work with. There are two basic simple location paths – the root location path (/) and child element location paths.

The forward slash (/) servers as the root location path…it selects the root node of the document. It is important to realize this is not going to retrieve the root element, but the entire document itself. The root location path is an absolute location path…no matter what the context node is, the root location path will always refer to the root node.

Child element location steps are simply using a single element name. For example, the XPath p refers to all p children of our context node.

One of the really handy things with XPath is we have quick access to all attributes as well by using the at sign ‘@’ followed by the attribute name we want to retrieve. So we can quickly retrieve all title attributes by using @title.

Using XPath in Javascript

That’s all well and fine, but how do we use this in Javascript? Right now, Opera, Firefox and Safari 3 all support the XPath specification (at least to some extent) and allow us to use the document.evaluate() method. Unfortunately at this time, IE offers no support for XPath expressions. (Let’s hope that changes in IE8)

The document.evaluate method looks like this:



The expression argument is simply a string containing the XPath expression we want evaluated. The contextNode is the node we want the expression evaluated against. The namespaceResolver can safely be set to null in most HTML applications. The resultType is a constant telling what type of result to return. Again, for most purposes, we can just use the XPathResult.ANY_TYPE constant which will return whatever the most natural result would be. Finally, the result argument is where we could pass in an existing XPathResult to use to store the results in. If we don’t have an XPathResult to pass in, we just set this value to null and a new XPathResult will be created.

Ok…all that talk and still no code. Let’s remedy that shall we. Here’s a very simple XPath expression that will return all elements in our document with a title attribute.



If you take a look at the XPath expression we passed in “//*[@title]“, you will notice that we used the attribute location step followed by the attribute we want to find, ‘title’. The two forward slashes preceding the at sign is how we tell the browser to select from all descendants of the root node (the document). The asterisk sign says to grab any nodes regardless of the type. Then we use the square brackets in combination with our attribute selector to limit our results only to nodes with a title attribute.

The evaluate method in this case returns an UNORDERED_NODE_ITERATOR_TYPE, which we can now move through by using the iterateNext() method like so:



Since each item in the results is a node, we need to reference the text inside of it by using the textContent property (line 3). You can only iterate to a node once, so if you want to use your results later, you could save each node off into an array with something like below:



Now arrTitles is filled with your results and you can use them however often you wish.

This is just the beginning…as we continue to look at XPath expressions and introduce predicates and XPath functions, you will start to see just how truly robust XPath expressions are. At this point, IE doesn’t support using XPath expressions in Javascript, but with each of the other major browsers having some support, and major Javascript Libraries placing an emphasis on using them, it’s only a matter of time before we can begin using these expressions to create more efficient code.

One of those nice features we can add is to display a link’s href directly after the link on our print-outs. This will allow someone who has printed out the page to still be able to know where the links on the page are pointing to. We can do this with CSS by using the :after psuedo-class and some generated content.



There are really four important parts of the statement above:

1. a[href]: Here, we use an attribute selector to select all links in our page with an href attribute.
2. :after: The :after pseudo-class allows us to insert some content after the links and style it if necessary.
3. content: This is what actually generates the content. We could just insert, for example, the letter “a” with a style call like content: “a”.
4. attr(href): This gets the href attribute of the link currently being styled. This way, each link will display it’s own href.

If we put this style in our print stylesheet, all of our links that actually have an href will print out like this: TimKadlec.com [http://www.timkadlec.com]

Obviously, this is a pretty handy enhancement to our print stylesheets. Now, the links printed out actually have some meaning to them. The problem is, Internet Explorer doesn’t support the :after pseudo class, nor does it support the content style. So if a user is using Internet Explorer and tries to print our page out, they still won’t see any href’s displayed.

Javascript to the Rescue

We can use a little bit of browser specific Javascript to fix this problem. Internet Explorer (version 5.0 and up) has a little known proprietary event called onbeforeprint. Just like it sounds, this event fires right before printing a page or viewing a print preview of the page. Since IE is the only major browser that doesn’t create the effect using CSS, a proprietary event is the perfect fix. Now, we can draw up a simple function like so:



Our function simply gets all the links on a page, and appends their respective href’s immediately after them, creating the same effect that we were able to do using CSS in other browsers. You might be wondering why we set the new content we created to be a property of each link. That’s because right after printing or canceling out of the print preview screen, we are now seeing the href on our actual web site. We obviously don’t want this, and it’s simple enough to get rid of with another IE proprietary function, onafterprint.



Here we just again, loop through all the links, find the position of the new content we added, and remove it from the link. This returns the appearance of our site to the original view before trying to print.

Obviously, it would be ideal if we could simply use CSS to manage this. However, as we’ve seen, there is no need to wait for IE to support this feature before we implement it. Some proprietary Javascript events allow us to replicate the effect until it is supported later on.

The script/css effect has been tested in IE7, Opera, Firefox, and Safari. If you are interested, the complete Javascript to create the effect in IE is here: printlinks.js