Tim Kadlec

Improving Web-Ed

One topic that I have been interested in for quite some time now is secondary education when it comes to web development and design. It is a very unfortunate truth that when it comes to web development, the curriculum is in serious need of some help.

As a recently graduated student, I can reflect on both my training and the training of other people my age who attended other colleges for web development that I interacted with. Unfortunately, the majority of the people I've communicated with stated the same thing: standards based development was not presented as a priority. CSS was glossed over and there was little to no mention of the DOM and unobtrusive scripting techniques in the Javascript courses.

Why Colleges Can't Keep Up

A large part of this is due to the fact that our industry moves so quickly. Progress is made at such an incredible pace and new technologies soon emerge while old ones fade away. In contrast, changing the curriculum at a college usually takes awhile, making it very difficult for schools to keep up.

Another issue is that some of the best candidates for taking on the role of instructor in these courses are overlooked due to a lack of degree. It would be great to have industry-tested professionals teach the courses...who better to teach a class about the techniques and tools that will be necessary in the field than those who are doing it, and have been doing it for some time.

That is not meant to be a criticism of all current instructors. As always, there are exceptions to the rule. There are industry professionals who have no place standing in front of a class and teaching technique, and likewise there are instructors who do a fantastic job of presenting their classes with quality information. And many of the other instructors simply have their hands tied by what the college allows them to do and not do.

One thing I do like seeing is that a few instructors who are pushing standards-based development forward in their courses have published their class information. Daniel Mall and William Craft are just two examples of people who are pushing forward with standards based development instruction and then sharing with others what they are doing. This opens the door for critiquing from industry professionals and provides an example of what other instructors might consider basing their coursework around.

How Do We Fix It

So what needs to be done? Universities and colleges need to adjust. Traditional methods of updating curriculum simply do not work when it comes to such a fast-paced industry. These institutions need to be making a concerted effort to keep their curriculum up to date with current industry standards, and as a result, the curriculum should be re-evaluated on a very regular basis.

In the mean time, a temporary fix may be to implement some sort of a rotating course, a generic web development study course. The course could be used to highlight emerging industry standards and could rotate on a semester basis. Again, just a temporary fix, but at least it provides a small level of attention to the techniques that the students will be needing.

I'd also like to see a few schools start taking a look at allowing existing professionals to instruct more courses, regardless of higher-education degree status. There is a lot of insight they can offer and it's a shame that schools are not tapping into that.

Of course, that door swings both ways. I'd love to see us as professionals get more involved in helping colleges to evaluate and update their curriculum. I applaud Opera and the people behind their new Web Standards Curriculum. If you haven't seen it yet, take a look. They are putting together a series of 50 articles or so highlighting areas in web design and development. This is exactly the kind of thing that can really help colleges by providing a guideline for what to build their new curriculum around.

Let Me Hear Your Thoughts

This is a topic that interests me very much. Eventually I would love to start teaching a bit myself...I love sharing what I've learned with others and find the teaching experience to be very rewarding. That is why I pay attention to what the current colleges are doing to try and stay ahead of the game a bit. I would love to hear any input you might have on the topic. Trying to improve web education in colleges is not an easy task and I think getting more opinions and discussion on the matter are exactly what is needed to come up with a better way to help get colleges up to speed and keep them there.

Elsewhere on the Web

Test Driven Development

There was a nice article at Sitepoint about Test Driven Development. The author, Chris Corbyn, walks through the TDD process using PHP examples, and describes some of the benefits he has discovered in the TDD process.

Firefox 3 Memory Benchmarks and Comparison

With both Firefox 3 and Opera 9.5 being freshly released, here's a nice memory performance comparison of those browsers, as well as the IE Beta version 1 and Flock. The memory tests are computed by a custom built .NET application, and provide a good look at how these browsers compare in memory management on the Windows operating system.

Sketching in Code: the Magic of Prototyping

The folks over at A List Apart offer us yet another excellent write-up. David Verba, Technology Advisor for Adaptive Path, takes a look at using prototypes in the web application development process, and what prototyping can offer that wireframes cannot.

Same DOM Errors, Different Browser Interpretations

Hallvord R. M. Steen of Opera offers a very interesting look at how the different browsers interpret the DOM, and what tools each of them provide for debugging. Some attention is also given to Opera's new debugging tool, Dragonfly.

A Better Way To Globalize

Lately I've been working quite a bit with some PHP code that made heavy use of global variables. It made the code quite rigid to work with...when changes were made in one function it had a ripple effect on many other key functions and more than once, made me curse global scope.

But sometimes it's necessary to share information between different functions, so what's a programmer to do? Global variables certainly make that possible, but they also create some problems. Heavy reliance on global variables makes it difficult to reuse code. Rarely can we uproot functions with a large dependency on global variables and insert them into different contexts or scripts without problem.

Debugging code also becomes difficult. When a variable is global in scope, it could be being instantiated virtually anywhere making it tough to track down. What's even worse is coming back to that code after a year, or as it was in my case, trying for the first time to decipher code that relies on global variables.

Luckily there's a much better way: the registry pattern. The registry pattern simply creates a class that servers as a central repository, or registry, of objects that we can now utilize throughout our code. It accomplishes this by utilizing static methods and properties, which means you'll want PHP5 to accomplish it....you can use it in PHP4 but it requires some workarounds. This pattern is particularly useful when used to store a data connection.

Breaking It Down

The best way to explain this is to walk through the code.

class Registry{
private static $instance;
static function instance(){
if ( ! isset( self::$instance ) ){
self::$instance = new self();
}
return self::$instance;
}
}

The code above first simply creates our registry class, aptly called Registry (line 1). We then create a static function (line 3) and variable (line 2). This is how we will keep track of whether or not an instance of this class exists. If it doesn't, then we create a new instance of the class.

Now we just need to create set and get functions for anything we want to use globally. In this case, we'll create set and get functions for a very simple object that we'll call a TestObject and a variable to contain that object.

class Registry{
//.....
private $testObject;
function getTestObject(){
return $this->testObject;
}
function setTestObject( TestObject $test){
$this->testObject = $test;
}
}

Our two new methods do exactly what they sound like...the get and set methods simply retrieve or save our testObject to the $testObject variable. That's all there is to it...now we can use our registry class to make a TestObject instance that we can use globally (for this post, just accept that TestObject allows us to set and display a message...all the code is available for those who want a closer look). Since we are using a static property and method to ensure that all instances of that class have access to the same values, it doesn't matter where we initially instantiate the class.

function setting(){
$myTest = new TestObject();
$myTest->setMessage ( "Registry Patterns Rock!" );
$reg = Registry::instance();
$reg->setTestObject( $myTest );
}
function retrieve(){
$reg = Registry::instance();
$myObject = $reg->getTestObject();
echo ( $myObject->getMessage() );
}
setting();
retrieve(); //outputs Registry Patterns Rock!

Now despite the fact that we create the two instances of the registry class within two separate functions, you can see that they both have access to the same values thanks to the Registry pattern, without all the mess that can be caused by global variables. To add more values to our registry class, we simply add more private variables and some set and get functions.

But Wait...There's More!

Another handy way of utilizing the registry pattern, is to use our Registry instance to create and then cache an object, skipping the need for a set or get function. For example, if I have a data connection that I know I want to be standard throughout the project I can create a function like this inside of my Registry class:

class Registry{
//.....
function dataConn(){
if ( ! isset ( $this->dataConn ) ) {
$this->dataConn = new dataConn();
$this->dataConn->setHost( 'localhost' );
}
return $this->dataConn;
}
}

Now, instead of worrying about the set and get functions, I can just call the dataConn() function. If the data connection has already been created, then it returns the connection. If not, it first creates my connection, and then returns it. So I can safely call the function without concerning myself with whether or not I've already created the connection...it takes care of that for me.

The registry pattern is so incredibly useful and a definite improvement over using the dreaded global variable in your code. I highly encourage you to play around with the sample code and see the different ways that the registry pattern can manage your code.

Javascript: The Good Parts

Who Wrote It?

When I first heard Douglas Crockford was writing Javascript: The Good Parts (let's just call it JTGP from here on out) I was anxiously awaiting the release. Crockford has been responsible for many highly regarded articles and presentations, as well as for his incredible work with JSON, JSLint and much more. While Brendan Eich may be the father of Javascript, Crockford is probably the Godfather. Even Eich himself called Crockford "the Yoda of Lambda JavaScript programming."

What's Covered?

JTGP does as promised...it brings to attention the best parts of the Javascript language. Topics like Objects, Inheritance, Arrays, Functions and Regular expressions are discussed throughout the book. While focusing on the "good parts" of Javascript, Crockford also points out the not-so good parts and explains why these other parts don't fall into the good category by pointing out caveats and pitfalls.

I've seen it mentioned before that people complained about the book being a bit short. It weighs in at a very light 145 pages, 45 of which are appendixes. The information is quite dense however, and I thought the appendixes were extremely valuable. The appendixes include looks at what Crockford considers to be the "awful parts" and the "bad parts" of Javascript. They also include looks at JSLint and JSON as well as providing some helpful syntax diagrams.

Should I Read It?

As mentioned before, the book is short, but very dense. As a result, there is a lot of information covered, but not always a lot of explanation involved. The book seems to take a bit of a different approach than the typical Javascript book...it's more focused on why than it is on how.

That is not at all a bad thing though. Assuming you have a nice handle on the language and it's syntax, there is a lot to get out of reading this book. In fact, there is so much information crammed in here that it will probably take several readings to truly grasp all the information being delivered. Don't make the mistake of assuming that because it is short it is an easy-read...this book covers advanced information and does so at a very rapid pace.

The Final Verdict

JTGP is a great book for anyone who wants a deeper understanding of the why behind the how. I would recommend it to anyone, though I would warn that you'll want to have a decent understanding of the syntax before reading it...since the book focuses so much on why, there's not a lot of explanation on how things work, and to get all that this book has to offer, you'll want to know that. Overall, a very good book that is good enough to demand several readings.

Great...Where Do I Get a Copy?

Libraries and Frameworks

A question I get asked often through emails and other discussions is how I feel about frameworks and libraries, both for scripting and for CSS. I've been meaning to share my thoughts on it for awhile, and now that I see NetTuts.com has posted an article about choosing a CSS framework, I figured now is as good a time as any.

Any of you who have been reading my site since the beginning might remember I wrote a post about the importance of forcing yourself to reinvent the wheel. I still stand by that, but that doesn't mean I am entirely against all frameworks. In fact, in the case of scripting libraries, I can definitely see the value in using them. The key point is to be able to tell when to use a library and when not to.

Why Should You?

One nod for using libraries and frameworks is that reusable code is a good thing. It saves you time and money, and I think most developers have at least some amount of code that they reuse on various projects. I am all for that. We programmers are lazy...errr...efficient. If we can create a solution that is flexible and reusable...then more power to us.

Libraries are also quite handy in large teams. They provide a common base for everyone on the team to start from, and if you stick to a certain naming or formatting convention, in combination with a library of some sort (either in-house developed or not), you can make communication very easy and eliminate a lot of the questions that can arise when passing code from developer to developer.

Large applications also provide us a good reason to use a library. In Javascript, for example, there are a fair amount of browser incompatibilities. These incompatibilities are taken care of by most Javascript libraries, allowing a developer to focus on developing the actual logic for the application not the browser differences that arise.

On the Other Hand...

There are many issues though that can arise from consistent use of libraries and frameworks. If you use a library exclusively, you can become quite dependant on it. It's important to understand the underlying code that the library is using. If you continue to depend entirely on a library to cover all browser bugs for you, there will come a time when there will be a bug it doesn't cover, and you aren't going to know where to turn to troubleshoot it.

Also, and this is particularly true in CSS frameworks, you can become too attached to what the framework provides and start conforming your code to fit in with the framework or library you are using. There is a saying that goes "When the only tool you have is a hammer, everything looks like a nail." If you are using a CSS framework to create your layout and there is a particular visual style that the framework doesn't quite get right, the most common approach, unfortunately, is to conform to the framework. You start to look for ways to make the layout fit within the frameworks provided structure.

Continuing with CSS frameworks, there is also a definite lack of semantics. You end up with mixing content with presentation by providing HTML markup that uses classes like yui-gb or span-8. I understand that semanticity is not no everyone's top 10 list of important things to do (though I do feel it should be a priority). But if semantics aren't particularly important, why not just use tables to mark up the page. It would take less code and would work almost seamlessly browser to browser. (Please note, I am not in any way condoning the use of tables for layout...I'm just making a point.)

For those Interested

So, in case you're wondering...here's where I stand on using libraries and frameworks. For Javascript, I occasionally use a library for code, usually on larger apps. Most of my code though is hand-created, however I do try to build with reusability in mind. I guess you could say I have my own personal library that I use.

As far as CSS goes...I don't use frameworks and can't see a time where I will actually do so. The lack of semantics rubs me the wrong way and to be honest with you, most of my CSS is not that similar from site to site. That being said, I have used reset styles of some sort on most projects, and there are a few other basic styles that I tend to include on all of my CSS, but it's no more than a few lines. It doesn't take me particularly long to get a layout set up in CSS, so I don't feel like a framework would help increase my efficiency in doing so.

That last paragraph sounds a bit harsh...but hopefully you understand that that's just one man's opinion. Again, I am not opposed entirely to frameworks and libraries; in fact as I said above I have used Javascript libraries in particular on more than one occasion. I just think it's important that frameworks are used only when appropriate and as enhancements to your coding abilities...not the foundation for them.

Behavior in Your Presentation

I've spent some time lately playing around with the WebKit Nightly Build. In addition to having advanced CSS support, the nightly build also introduces a few new proprietary CSS properties (though the plan is to eventually get W3C to implement them in the CSS specification). There are some really cool features being implemented, including CSS gradients, masks and transforms. One new feature, CSS transitions, has me a little on the fence though.

CSS transitions are definitely a cool idea. Using one simple line of CSS, we can specify how we want a particular style to change. For example, a very common thing to do with CSS is change a link's color when hovered over. To do so, you just use the :hover pseudo-class like so:

a{
color: blue;
}
a:hover{
color: red;
}

Browsers make the color change immediately when a user hovers over the link. Using WebKit's transition property, we can tell the browser to instead make a smooth transition. For example, to make the color slowly change from blue to red over the course of two seconds, we could do the following:

a{
color: blue;
-webkit-transition: color 2s linear;
}
a:hover{
color: red;
}

We tell the browser (line 3) what style we want to animate (color), for how long (2s) and what kind of transition we want to use (linear). If you have the WebKit nightly build, I set up an example using the CSS above. It works great, and the transition is super smooth. Better yet, the other browsers just disregard it and perform the color change as usual. Simple and cool right?

Mixing Things Up a Bit

The problem I have with it is that it I think it starts to put CSS in our behavior layer, which is not so cool. Remember, one of the major benefits to proper use of web standards is being able to separate our content, presentation and behavior onto their own separate layers. By using CSS to make these changes, we make it difficult to interact with these properties using Javascript. Will we have access to information regarding how far into the animation we are? Will the transition fire some sort of onFinish method? Javascript would be needed to add this level of flexibility...not CSS.

While looking around for more information, I was happy to run across a post from late 2007 by Jonathan Snook that shares my opinion on the matter. One thing Jonathan suggested was that while browser animation is not a bad idea perhaps it should have been an extension to the DOM instead. That would offer more robustness and flexibility, and seems to preserve the separation of concerns a bit better.

Don't get me wrong...I'm very excited about most of the new features on display in the nightly build. I can also see how the line between behavior and presentation is a bit blurred already. After all, isn't :hover a bit of a behavioral style? I just think that given the potential interactivity here, I have to agree with Jonathan and say that adding a method to the DOM would make more sense in this case.

Elsewhere on the Web

line-height: abnormal

Eric Meyer has a great write-up about how diverse the rendering of line-height: normal is across browsers. Complete with a test page that allows you to see what happens to the value of line-height normal as different fonts and font-sizes are selected.

What's Next in jQuery and JavaScript

John Resig of jQuery fame posted a nice 11 minute video where he talks about what is coming up for jQuery, Javascript, and some changes that are being made in browsers. Nice overview of what we have to look forward to on all counts.

Initial Impressions of Silverback

A nice review of Silverback, the new user testing development tool created by the geniuses over at Clearleft. Personally, I haven't had a chance to play with it yet, as it is only available for Macs and I am still laboring away on a PC. From everything I've heard though, looks like a fantastic tool.

Content Inventory

Just a bit more Clearleft love here. Andy Budd continues his series of posts looking at design artifacts with a look at the value and importance of performing a content audit.

UserVoice

Finally, though I'm a bit late on mentioning it, I'd be remiss if I didn't say something about the release of UserVoice, home grown here in Wisconsin. UserVoice allows you to provide a way for users of a site, application, anything really, to discuss and vote on changes and features. In addition to being useful right out of the box, there are some cool additions to the product being looked at like OpenId support and perhaps an API.

Not As Clear As It Seems: CSS3 Opacity and RGBA

One of the many things CSS lets us control is the opacity of elements, starting in CSS3. The opacity property is in fact one of the earliest and most widely implemented CSS3 properties. It has its problems though, but CSS3 also defines a more powerful way to control an element's transparency: RGBA values.

The Opacity Property

To change the opacity of an element using the opacity property, you simply give it a value between 0 and 1 to determine the elements' opacity. For example, if I want a div to be 50% transparent, I would give it the following style:

div {
opacity: .5;
color: #fff;
background-color: #000;
}

This works fine in Safari, Opera, and Firefox. Internet Explorer, however, doesn't yet support the opacity property. Instead, we have to use their proprietary property Alpha Filter. It's really not any more difficult than the opacity selector. One key thing to note hear though is that the Alpha Filter requires you specify the opacity on a scale of 0 to 100. There's even a catch to that though...the element is that you are applying the opacity filter to has to have a hasLayout value of true. While there are many ways of making an element have layout, some of the most common are to set a width, or give the element a zoom value of 1. So now our declaration is as follows:

div{
background: #000;
opacity: .5;
filter: alpha(opacity='50');
zoom: 1;
}

Simple enough...but with one catch that may or may not present a problem, depending on your situation. When you use the opacity property, the opacity is set for that element, and any children of that element. This can cause problems in readability and general appearance. If you do have problems in this situation, you may not have to resort to a PNG just yet.

More Power

CSS3 also allows for an extended version of the RGB color model that includes a fourth value that is used to specify opacity. Again, like the opacity property, the alpha value in the RGBA model accepts a value between 0 and 1. We can use an RGBA value anywhere that colors values are accepted in CSS: borders, background, font colors, etc. This already offers a higher level of control than the opacity selector.

Even better yet, while the opacity property defines the opacity for an element and all of its children, using the RGBA value only applies that transparency to the given property of an element that we specify. For example:

div{
background-color: rgba(0,0,0,.5);
color: #fff;
}
<div>
<p>Some white text.</p>
</div>

Using the background-color property and assigning an RGBA value to it, we are able to define the transparency for the divs' background color. The transparency of any text or elements inside of the div is unchanged. In contrast, using the opacity property, the paragraph above would inherit the 50% transparency defined on the div.

Unfortunately, as is often the issue, browser support for RGBA is limited. Both Safari and Firefox 3 offer support for the RGBA color value system, but so far Opera and IE do not. The good news though, is that we can use the RGBA value without worrying about it breaking our design by also defining a fallback color.

div{
background-color: rgb(0,0,0);
background-color: rgba(0,0,0,.5);
color: #fff;
}

In most browsers that do not recognize RGBA values, that declaration is simply ignored, as it should be. In IE though (I know, surprise, suprise), it appears that RGBA values cause IE to not display the background at all. A way to get around this would be to use conditional comments to reset the background to a solid color for IE. So we can just define a solid color for browsers that do not accept RGBA values and leave the transparency for those that can support it...a prime example of progressive enhancement.

I have set up a working comparison of RGBA versus using the opacity property for you to view in each browser. Remember, to see the effects of RGBA, you will have to view the page in Safari or Firefox 3.

An Objective Look at Javascript 2.0: Strong Typing

In our first look at the new features of Javascript 2.0, we will focus on the new typing system. We are just going to highlight some of the major changes and potential uses. For a more detailed look, take a look at the ECMAScript 4.0 Language Overview.

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

var a = 42; // Number declaration
var b = "forty-two"; // String declaration

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:

var a:int = 42; //variable a has a type of int
var b:String = "forty-two"; //variable b has a type of String
function (a:int, b:string)//the function accepts two parameters, one of type int, one of type string
function(...):int //the function returns a value with a type of int

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:

"42" == 42
42 == "42"

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:

int("42") == 42
string(42) == "42"

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:

function testing(this:myObject, a:int, b:string):boolean

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:

type AnyString = (string, String)
type AnyBoolean = (boolean, Boolean)
type AnyNumber = (byte, int, uint, decimal, double, Number)
type FloatNumber = (double, decimal)

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

type MySpecialProperty = (byte, int, boolean, string)

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.

Phantom CSS

At the heart of CSS, of course, are its selectors. They are after all what allow us to apply styles to a given element in our (X)HTML. Sometimes though, there is a desire to apply a style based on an elements state. That is where pseudo-classes come into play. You've probably all used them at some point...but there may be more there than you realize. Their value makes it worth taking a closer look.

Static Pseudo-Classes

Pseudo-classes allow us to apply an invisible, or "phantom", class to an element in order to style it. For example, let's look at the element most often styled using pseudo-classes: the anchor tag (<a>). Some anchor tags point to locations a user has already viewed, and some point to locations the user has not yet visited. Looking at the document structure, we can't tell this. No matter if the link is viewed or not, it looks the same in (X)HTML. However, behind the scenes, a "phantom" class is applied to the link to differentiate between the two. We can access this "phantom" class with pseudo-class selectors, like :link and :visited. (Pseudo-classes are always prefixed by a colon.)

The :link pseudo-class selector refers to any anchor tag that is a link...that is any anchor tag that has a href attribute. The :visited pseudo-class selector does exactly what it sounds like...it refers to any link that has been visited. Using these pseudo-classes allows us to apply different effects to links on the page according to the visited state.

a {color:blue;}
a:link {color: red;}
a:visited {color: orange;}

The above styles for example, will make any anchor tag that does not have a href attribute to be colored blue (line 1). Any link that has a href attribute, but has not been visited will be red (line 2). Finally, if a link is visited (line 3), then it is an orange color.

Another static pseudo-class is :first-child (The :first-child pseudo-class is not supported by IE6). The :first-child selector is used to select elements that are first children of other elements. This can be easily misunderstood. A lot of times, people will try to use it to select the first-child of an element. For example:

<div>
<p>Here is some text</p>
</div>

Say we want to apply a style to the paragraph element. It is not uncommon to see people try to do this using the following style:

div:first-child {font-weight: bold;}

However, this is not how the pseudo-class works. If we think back to the concept of pseudo-classes essentially being "phantom" classes, then what we just did was apply a phantom class to the div like so:

<div class="first-child">
<p>Here is some text</p>
</div>

Obviously that is not what we want. The :first-child selector doesn't grab the first child of an element; it just grabs any of the specified element that is a first-child. The correct way to style that would be with the following line:

p:first-child {font-weight: bold;}

That's probably as clear as mud, so it may help to take another look at the "phantom" class:

<div>
<p class="first-child">Here is some text</p>
</div>

Watch Your Language

Corny headings aside, we can select elements based on the language using the :lang( ) pseudo-class. For example, we can italicize anything in French using the following style:

*:lang(fr) {font-style: italic;}

Where does the language get defined? According to the CSS 2.1 specification, the language can be defined in one of many ways:

In HTML, the language is determined by a combination of the lang attribute, the META element, and possibly by information from the protocol (such as HTTP headers). XML uses an attribute called xml:lang, and there may be other document language-specific methods for determining the language.

Dynamic Pseudo-Classes

So far, what we have discussed are static pseudo-classes. That is, once the document is loaded, these pseudo-classes don't change until the page is reloaded. The CSS 2.1 specification also defines three dynamic pseudo-classes. These pseudo-classes can change a document's appearance based on user behavior. They are:

:focus - any element that has input focus
:hover - any element that the mouse pointer is placed over
:active - any element that is activated by user input (ex: a link while being clicked)

Usually, these pseudo-classes are applied only to links. However, they can be used on other elements as well. For example, you could use the following style to apply a yellow background to any input field in a form when it has the focus.

input:focus {background: yellow;}

The main reason this is not done a lot is because of a lack of support. IE6 does not allow any dynamic pseudo-classes to be applied to anything besides links. IE7 allows the :hover pseudo-class to be applied to all elements, but doesn't let the :focus pseudo-class be applied to form elements.

Complex Pseudo-Classes

CSS offers us the ability to apply multiple pseudo-classes so long as they aren't mutually exclusive. For example, we can chain a :first-child and :hover pseudo-class, but not a :link and :visited.

p:first-child:hover {font-weight: bold;} //works
a:link:visited {font-weight: bold;} //link and visited are mutually exclusive

Again, there is a compliance issue here with IE6. The IE6 browser will only recognize the final pseudo-class mentioned. So in the case of our first style above, IE6 will ignore the :first-child pseudo-class selector and just apply the style to the :hover pseudo-class.

Looking Forward to CSS3

In addition to the pseudo-classes laid down in CSS 2.1, CSS 3 provides sixteen new pseudo-classes to allow for even more detailed styling capabilities. The new pseudo-classes are:

:nth-child(N)
:nth-last-child(N)
:nth-of-type(N)
:nth-last-of-type(N)
:last-child
:first-of-type
:last-of-type
:only-child
:only-of-type
:root
:empty
:target
:enabled
:disabled
:checked
:not(S)

For more information about the new pseudo-class selectors laid down in CSS3, take a look at the CSS3 selectors working draft, or the excellent write-up by Roger Johansson. Currently, very few have decent cross-browser support, but as Johansson says, they can still be used for progressive enhancement...and in such a quickly changing field, when we can stay ahead of the curve, we should take advantage of it.