SXSW Anticipation and Twitter

After having been signed up to attend since early October, it just dawned on me yesterday that I only have one full "work week" left until SXSW. This will be my first major web conference, and to say I am excited about going is a vast understatement. I believe my wife is probably looking forward to it as much as I am, if only for the fact that once it is over she no longer has to hear every little update from me about panel programming and new social events.

I can only imagine that being surrounded by that many people who are passionate about the web for 5 days will be quite inspiring and reinvigorating. While this is the first conference I will be attending, I hope that there will be many more.

In fact, ideally I'd like to go to several each year. Listening to the presentations and having the chance to mingle with other web-minded folk seems to me an incredible way to keep in tune with the trends of the industry, and an effective way to find new techniques or skills to pursue.

After having looked over the panels roughly 100 times, there are several that I am particularly excited to check out.

Secrets of Javascript Libraries

I was excited for this back when I thought only John Resig, he of JQuery fame, would be presenting. Now that I hear people who either created or contributed other major libraries like Dojo, Prototype and Scriptaculous are also going to be there, this panel has really shot up to the top of my list.

Browser Wars: Deja Vu All Over Again?

Finally, a question I have long wondered about will be answered: What happens when you stick major players at Firefox, Opera, and IE in a room together? Cage match anyone?

Design Eye for South By

I've heard nothing but great things about this panel from year's past. Can't wait to see what they come up with this time around.

Everything I Know About Accessibility I Learned From Star Wars

Honestly....Derek Featherstone had me at Star Wars. The fact that the presentation covers such an important topic like accessibility is really just gravy.

Design is In the Details

Actually not sure what to do here. Naz Hamid's presentation sounds fantastic, but Slideshare is also talking about the lessons learned about AJAX and Flash while creating SlideShare.net during this time. Decisions, decisions.

I could name many more that sound great, but then you would just get bored and move on if you haven't already.

In addition to the panel programming, from everything I hear, the networking opportunities are amazing at SXSW, and I am quite excited to have the opportunity to meet some people in person for the first time. I always enjoy running into another passionate web developer or designer. The discussions are always interesting.

I am amazed by the amount of social events currently scheduled. Should be a good time, but I am quite curious as to how people actually manage to stay at these things the whole time and then be ready to go again in the morning? I hope there is a Starbucks near by.

For anyone interested, I did break down and sign up for Twitter recently, in no small part because I hear last year it turned into quite an essential tool to stay in the loop as far as where to meet up with people and such. So, if any of you are going to be at SXSW, you should follow me on Twitter so we can meet up some place. I'd love the opportunity to meet some of you in person.

And for those of you who aren't going to be there, but want to follow me anyway, feel free to. I'm going to do my best to keep up with the updates there and I may even have something interesting to say from time to time.

XPath in Javascript: Predicates and Compounds

Welcome to the second part of my look at XPath and how it can be used in Javascript. Part one served as a real basic introduction to what XPath is, how it can traverse the document tree, and an introduction to using XPath expressions in Javascript using the evaluate method. So far what we have seen is really basic. There is some value in it, but we can build much more robust expressions with a bit more knowledge.

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:

1. myXPath = "//div/h3/span"


2. var results = document.evaluate(myXPath, document, null, XPathResult.ANY_TYPE, null);

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:

• //h3[.="Yaddle"]

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:

• <span class="year">2007</span>

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

• //span[@class="year"][.<= 2007 and .>=2005]

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.

XPath in Javascript: Introduction

As reported by John Resig, Prototype, Dojo, and Mootools have all switched their CSS Selector engines to be using XPath expressions instead of traditional DOM methods. With the attention being placed on XPath expressions, now is a good time to get familiarized with them and what they can accomplish.

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:



• var theResult = document.evaluate(expression, contextNode, namespaceResolver, resultType, result);

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.



• var titles = document.evaluate("//*[@title]", document, null, XPathResult.ANY_TYPE, null);

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:



1. var theTitle = titles.iterateNext();


2. while (theTitle){


3. alert(theTitle.textContent);


4. theTitle = titles.iterateNext();


5. }

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:



1. var arrTitles = [];


2. var theTitle = titles.iterateNext();


3. while (theTitle){


4. arrTitles.push(theTitle.textContent);


5. theTitle = titles.iterateNext();


6. }

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.

Share Your Site with the Masses

Originally, it was never going to get this complex. The internet was never meant to be this popular. However, as time has gone by and this wonderful beast of resource has evolved, it is becoming important to be able to provide our content to a wide variety of devices. In addition to simply viewing a site on a computer screen, or printing it, our information may be accessed by Braille feedback devices, speech synthesizers, handheld devices, etc. More often than not, one set of styles will not be adequate to provide our content optimally to each of these devices. That is where media types come into play.

Media types can be extremely useful. For example, there is very little reason to display a site's navigation on a print-out. Using the print media type, we can then set up a style that hides our navigation section. Handheld devices which have very small screens and often low-bandwidth, may benefit from not displaying a bunch of images.

CSS 2 offered us 10 media types as a way to designate which styles are applied depending on the device that accesses our site:

1. All - all devices (this is default)


2. Aural - speech synthesizers


3. Braille - Braille tactile feedback devices


4. Embossed - paged Braille printers


5. Handheld - handheld devices (usually small screen, low bandwidth, possibly monochrome)


6. Print - printing or print preview


7. Projection - projected presentations (projectors, printing on transparencies)


8. Screen - computer screen


9. Tty - media using a fixed-pitch character grid (terminals or teletypes)


10. Tv - television devices

If no media type is declared, the default is "all". Using these media types, we can tell devices to only use certain sets of styles. There are three basic ways of doing this:

Using Inline Syles




1. <style type="text/css">


2. @media print{


3. body{ background-color:#FFFFFF; }


4. #heading{ font-size:28px; }


5. }


6. </style>

Inline style sheets are not a very good solution, as they do not separate content and presentation.

Imported Stylesheets




1. <style type="text/css" media="print"/>


2. @import "print.css";


3. </style>

Imported style sheets are a much better solution, and are fairly widely used. A distinct advantage of imported style sheets is that a styles sheet is only downloaded if that specific media type is being used. For example, if I defined the above styles to be associated with the handheld media type and someone using a regular computer came to my site, they wouldn't have to download the styles.

Linked Stylesheets




• <link rel="stylesheet" type="text/css" media="print" rel="print.css" />

This is the most widely supported. As you may have guessed, a user will download each stylesheet regardless of the media type, and then use the appropriate ones. A bit unfortunate, as it wastes a little bit of time downloading styles we're not really going to use.

It is important to note that some styles only have meaning within a certain media type, and others are not applicable to certain media types. For example, the aural media type has no use for the font-size style while the page-break-before style is really only useful in the media types like projection, printing, and tv.

Unfortunately, the support for most media types is quite minimal. You can pretty much depend on all, screen, and print. However, at this point, only Opera supports the projection media type, and the handheld media type isn't widely supported yet on handheld devices. Feel free to use them anyway, as even if the user agent doesn't recognize the media type named, it will just ignore it.

Media Types on Steroids: Media Queries

Media types will eventually become even more useful. CSS3 will implement media queries, which will allow us to check for certain criteria. For example, with media queries we can do something like the following:




• <link rel="stylesheet" type="text/css" media="screen and (color)" rel="print.css" />

What we are telling the user agent is to only use those styles if the device uses a screen media type AND the device is a color device, not monochromatic. The parentheses are required around the text expression to indicate that it is a query. Media queries will allow us to check for items like, width, height, max-width, max-height, min-width, min-height, color, resolution, etc.

Opera already has some limited support for media queries. You can check for height and width values using the pixel measurement in Opera. Hopefully other browsers won't be to far behind. Actually, to try and push the concept forward a bit, media queries are one of the criteria being built into the new Acid 3 browser test.

You can check out a more detailed look at media queries by looking at the W3C candidate recommendation on the subject.

It's All in the Details

When coding and designing there are a lot of steps and techniques that may seem trivial and appear to have little importance in the grand scheme of things. Does it really matter if we are using meaningful names for our variables in our code, or for our CSS id's and classes? Who really cares if we use deprecated elements in our X/HTML so long as browser recognize them? So what if I am not consistently formatting my code the same way?

I am a huge fan of basketball, and find the history of the game particularly enjoyable. One of the basketball figures from the past that I have always admired the most was John Wooden, who coached the UCLA basketball team to 10 NCAA national titles, including 7 in a row at one point. He had four 30-0 seasons, and at one point his team won 88 consecutive games. Point being...the man was quite good at his job.

Each year, Wooden started out his season by having all of his players come into the locker room for his first lesson. He'd sit them all down, then pull out a pair of socks and slowly demonstrate the proper way to put them on. He'd roll the socks over the toes, then the ball of the foot, arch and heel, and then pull the sock up tight. He would then have the players slowly run their fingers over the socks to make sure there were no wrinkles. Seems kind of trivial right?

However think about it for a second...if he put that much attention into ensuring that such a small task was carried out so precisely, wouldn't it follow that each task his team performed would be given the same kind of thought and attention to detail?

It's that way with programming and design as well. If we think details like semantic names, using progressive enhancement, and consistently formatting our code are important, won't we also be concerned with much bigger details like making sure our code is efficient, our program is easy to use, and our design is effectively portraying the message we are trying to send?

And what if we do decide that some of these "trivial" details are not important enough to worry about? Where do we then draw the line between what matters and what we can just kind of ignore? If it's ok to not use meaningful names for our variables, is it also ok if our code takes a few more seconds to load, or if one of our scripts is not unobtrusive? When does something become important enough to matter?

It may seem somewhat trivial to make sure that all our identifiers in CSS are meaningful names, and that in our programs we always format our functions the same way. However, if we put that kind of attention into all the little things that go into programming and design, just imagine the high quality finished product we will have. It is that attention to detail that separates the good programs from the great, a good looking design from a "wow" design.

That's why we can never sit still. We need to always push ourselves to find better solutions...more efficient code, more effective design. Just because something works doesn't mean it works well. Only by taking time to pay close attention to the "minor" details that go into our development process can we be sure that our final, finished product will be one of high quality and durability.