One of the trickiest things about getting started with Web Sockets is getting a server set up. Because you’re not using HTTP, you can’t just use your regular web server. Two implementations of Web Socket severs are socket.io and Jetty, but the set up for these is not obvious, particularly if you’re a client-side person and don’t have much experience with the server-side of things.

socket.io

Socket.io is a Node.js implementation of the Web Socket protocol. That means to use it, you also need Node.js. Fortunately, Node.js is a lot easier to install than it was just a short while ago. You’ll also need npm (Node Package Manager), which makes installing extensions to node.js, like socket.io, much easier. You’ll use npm to install socket.io. Here are the steps and downloads you’ll need:

1. Download and install node.js. This one-click install should work on most platforms.
2. Next, get and install npm. The npm web page has a “one line install” that works; except you need to be running as root/administrator to do it. (Mac users: You can also try using sudo on both the curl and sh commands, but that didn’t work for me). If you’re on a Mac, to login as root, you’ll first need to create a root user and then login as root to do the install. Follow these instructions (apple.com) to enable and login as root. Once you’re logged in as root, you can run the “one line” at npm to do the npm install. Logout of root, back in as your normal user and you can then use npm to install socket.io, in the next step. If you’re on Windows, you’ll have to do your own digging as I’m not up to date on admin stuff on Windows.
3. To install socket.io, you’ll need to download it from github. Look for the ZIP link on that page. Unzip to a folder in the directory where you’re going to run everything, and use npm to install it (from the level above the unzipped folder). To install, type: npm install socket.io. You’ll see a new folder, node_modules created in the directory, containing socket.io in a configuration that node.js can find it with a require.

Now that you’ve got everything installed, you’re ready to give it a try. You’ll need to create two files: the server file, that you’ll run with node.js, and a client HTML file that you’ll load in the browser. One tricky thing about socket.io (that took me a while to figure out!) is that the HTML file must be served using the Web Socket server to use the socket.io client library. I tried writing basic HTML5 Web Socket code, but I kept running into a bug, and apparently it’s a known and common bug, so the recommendation is that you use the socket.io client library to connect to the server. Unfortunately this hides the HTML5 Web Socket communications code, which is what you really want to learn, but that’s the current state of things with socket.io (from my understanding, anyway, and certainly my experience was that I ran into the bug).

Server code

Create a new file, ss.js and add the server code:

var app = require('http').createServer(handler)
  , io = require('socket.io').listen(app)
  , fs = require('fs')

app.listen(8080);

function handler (req, res) {
  fs.readFile(__dirname + '/index.html',
  function (err, data) {
    if (err) {
      res.writeHead(500);
      return res.end('Error loading index.html');
    }

    res.writeHead(200);
    res.end(data);
  });
}

io.sockets.on('connection', function (socket) {
  socket.emit('news', { hello: 'world' });
  socket.on('my other event', function (data) {
    console.log(data);
  });
});

This code is copied directly from the socket.io web site (first example), although I did change the port to 8080, as I already have an HTTP server running on port 80. First, we create an HTTP server. The callback function for the server (that is, the function that gets called when a connection is requested) is the handler function. This serves an index.html file, which is where you’ll put the client code. This is just a very basic http file server, so if you want a more fully functional web server, you’ll need to use Express, and there are instructions on how to use that on the socket.io web site. I’m not going to go into that in this article.

After setting up the http server, we then set up the Web Socket handler. The Web Socket connections will come in on the same port as the HTTP requests, 8080, but use a different protocol (ws rather than http). When a ws connection is received, a socket is created, and we send a message to the client over that socket. The message consists of the event type and an object with one property, hello.

We also set up a message handler for the socket. When a message is received from the client, we just log it to the console. Due to lack of documentation at socket.io, I’m a little unclear on the first argument to socket.emit and socket.on but I believe it’s the event type. You can use built-in event types, like “connection”, or create custom event types, like “my other event”.

Client code

Now for the client. Create a file, index.html (remember our basic server is only going to serve index.html! Feel free to rename the file but you’ll need to change the name in the server code too). Here’s my code (slightly modified from the code in the example on socket.io):

<!doctype html>
<html>
<head>
<title>web sockets</title>
<meta charset="utf-8">
<script src="/socket.io/socket.io.js"></script>
<script>
var socket = io.connect('http://localhost:8080');
socket.on('news', function (data) {
    console.log(data);
    writeMessage(data);
    socket.emit('my other event', { my: 'data' });
});

function writeMessage(msg) {
    var msgArea = document.getElementById("msgArea");
    if (typeof msg == "object") {
        msgArea.innerHTML = msg.hello;
    }
    else {
        msgArea.innerHTML = msg;
    }
}
</script>
</head>
<body>
<div id="msgArea">
</div>
</body>
</html>

Notice that we’re using the same port as we are listening on in the server, 8080. These two must match! Also notice that we’re including the socket.io JavaScript from the path: /socket.io/socket.io.js. The / at the beginning means “root”. The server is running in the directory where you’re putting these files, and that’s considered the “root”. The socket.io library is installed in this same directory for node.js, so this path will be found when you request this file using localhost:8080, which points to your node server. The node server does some magic that allows all the code in the socket.io.js file to be understood by the browser. If you try to load this file without socket.io and node, it will fail miserably. This was a tricky bit for me to understand so make sure you’ve got everything in the right place!

So, to try this, you first need to run the node server, and then load up your index.html file in the browser:

1. To run the node server, type node ss.js. You should see:

   info  - socket.io started
   

2. Now, use your browser to load http://localhost:8080. If all goes well, it will connect to the server and you’ll see “world” in your page, and in the console, where you’re running the server, you’ll see:

      debug - served static content /socket.io.js
      debug - client authorized
      info  - handshake authorized 1292119758764894899
      debug - setting request GET
              /socket.io/1/websocket/1292119758764894899
      debug - set heartbeat interval for client
              1292119758764894899
      debug - client authorized for
      debug - websocket writing 1::
      debug - websocket writing 5:::
              {"name":"news","args":[{"hello":"world"}]}
      debug - websocket received data packet 5:::
              {"name":"my other event","args":[{"my":"data"}]}
              { my: 'data' }
   

And voila, you have just used Web Sockets to send and receive a message from a server! Whew!

Jetty

Another option, and one that allows you to write HTML5 Web Socket code on the client, rather than using a framework, is to use a Jetty Web Socket server. Jetty is a Java HTTP server and servlet container, and has an implementation of Web Sockets, and a Web Socket test server. I’ll explain how to get the Jetty Web Socket test server up and running, and then how to create a client that uses HTML5 Web Sockets to send and receive messages.

First, you’ll need to download Jetty. You can download the entire Jetty folder here: http://download.eclipse.org/jetty/. This includes all the jar files you’ll need except one; also download the jetty-all jar file, which includes everything; this makes it simpler to compile and run:

where $JETTY_VERSION corresponds to the version of jetty you downloaded previously. The version I downloaded was: 8.1.0.v20120127, so my url for downloading the jetty-all file was:

On the Mac, you can use curl to get this file easily:

curl http://repo1.maven.org/maven2/org/eclipse/jetty/aggregate/\
jetty-all/8.1.0.v20120127/jetty-all-8.1.0.v20120127.jar \
> jetty-all-8.1.0.v20120127.jar


Create a folder, and place jetty-all-8.1.0.v20120127.jar as well as servlet-api-3.0.jar (you’ll find that in the full Jetty distribution you downloaded previously) in that folder.

The server

On the Jetty Web Sockets page, the documentation says you can run the test server directly. I wasn’t able to do this (I get an error). So I copied the server code and built it myself. The code seems to be missing the following import:

import org.eclipse.jetty.websocket.*;

so I added that before compiling. You’ll need to compile with the jetty-all-8.1.0.v20120127.jar and servlet-api-3.0.jar. I did this using Eclipse, so to run the Test Server, I exported a jar file, and placed it in the same directory with jetty-all-8.1.0.v20120127.jar and servlet-api-3.0.jar. If you want to do it from the command line, you can do this:


javac -cp jetty-all-8.1.0.v20120127.jar:servlet-api-3.0.jar \
TestServer.java
jar -cf TestServer.jar *.class


Once you’ve got the Test Server built, you can run it like this:


java -cp .:TestServer.jar:servlet-api-3.0.jar:\
jetty-all-8.1.0.v20120127.jar TestServer \
--port 8080 --docroot . --verbose


You’ve now got a Web Socket server running at port 8080.

If you take a look at the code, you’ll notice that there are several different “protocols” supported. The protocol is actually a sub-protocol of the Web Socket protocol and allows the server to further refine the types of connections it will accept.

The Jetty Web Socket server supports several different sub-protocols, and the one I found most useful when testing is the “org.ietf.websocket.test-echo-assemble” sub-protocol. This one tells the Jetty server to send a message back, echoing the data you sent from the client. This is a good way to test to make sure your code is working. You can specify which sub-protocol to use in the client code, when you connect.

The client

Now that you have a server running, it’s time to create the client. I based my code on code in this NetTut tutorial, but changed it a bit to suit my needs and make it a bit clearer.

Here’s the code:

<!doctype html>
<html>
<head>
<title>Node Test</title>
<meta charset="utf-8">
<script>
window.onload = init;

function message(message) {
  var msg = document.getElementById("msg");
  msg.innerHTML += message;
}

function init() {
  var socket;
  if (!("WebSocket" in window)){
    message("Sorry, no web sockets");
  }
  else {
    //The user has WebSockets
    setUpHandlers();
    connect();  

    function connect(){
      var host = "ws://localhost:8080/";
      var protocol = "org.ietf.websocket.test-echo-assemble"; 

      try {
          socket = new WebSocket(host, protocol);
          message('<p class="event">Socket Status: '
                   +socket.readyState + "</p>");
          socket.onopen = function() {
             message('<p class="event">Socket Status: '
                     +socket.readyState+' (open)</p>');
          }
          socket.onmessage = function(msg) {
             message('<p class="message">Received: '
                     + msg.data + "</p>");
          }
          socket.onclose = function() {
             message('<p class="event">Socket Status: '+
                      socket.readyState+' (Closed)</p>');
          }
       } catch(exception) {
          message('<p>Error'+exception + "</p>");
       }
    }//End connect  

    function send() {
      var text = document.getElementById("text").value;
      if (text=="") {
        message('<p class="warning">Please enter a message</p>');
        return ;
      }
      try {
        socket.send(text);
        message('<p class="event">Sent: '+text+"</p>");
      } catch(exception) {
        message('<p class="warning">' + exception.text + "</p>");
      }
    }//End send

    function setUpHandlers() {
      var sendButton = document.getElementById("send");
      sendButton.onclick = function() {
        send();
      };
      var disconnectButton = document.getElementById("disconnect");
      disconnectButton.onclick = function() {
        socket.close();
      };
    }//End setUpHandlers
  }//End else
} //End init
</script>
</head>
<body>
  <div id="msg">
  </div>
  <form>
    <input id="text" size="40">
    <input type="button" id="send" value="Send">
    <input type="button" id="disconnect" value="Disconnect">
  </form>
</body>
</html>

In this code, we use a form to get a message from the user to send to the server, which the server will echo back.

We set up the connection to the server with the line:


socket = new WebSocket(host, protocol);


Note that the host points to the local Jetty server which is running on port 8080. The protocol is “org.ietf.websocket.test-echo-assemble”, which tells the server to echo back the message you send to it.

We set up handlers for various socket events and states. We use onopen to set up a callback when the socket is opened successfully, and onclose to set up a callback when the socket is closed. If a message is received, we handle it with the callback set up for onmessage.

Try typing a word or two in the form, and click Send. This calls the send() function, which sends a message to the server using socket.send(). The server echoes that message back to the client, so you should see the words you typed appear in the page. You can keep sending messages to (and receiving messages from) the server (all on the same socket connection), until you click Disconnect, which terminates that socket connection.

Web Sockets are not for the faint of heart, for sure! In this post, we’ve looked at how to get a Web Socket server up and running and create a very basic client to connect to the server, send messages to the server, and receive messages from the server. In a future post, we’ll do something more fun with Web Sockets.

When troubleshooting CSS issues, how can I determine the source of a style that is applied to an element?

My favorite way to figure out how an element is getting its style is to use the Element inspector in the Safari or Chrome browser. Let’s use the web page at Starbuzz Coffee as an example. Load the page in one of these browsers, and then open up the inspector. In Safari, use the Develop > Show Web Inspector menu, and in Chrome, right click on any part of the page and choose Inspect Element.

Once you have the inspector open, make sure the Elements tab is selected. It should look like this:

Here, I’ve selected the “header” <div> element in the main window on the left, and on the right, I’ve opened up the Computed Style and Styles inspectors. These are incredibly useful tools for figuring out where the style of an element is coming from, which is helpful especially if you’ve got a lot of CSS!

Notice, that in the case of the “header” <div>, the matched rules (ie, the rules I specifically wrote for #header) show the background-color, margin and height properties. Also note that my user agent (that is, the default CSS in the browser) is setting the <div> to block display. The font-family and font-size are being inherited from the body element, which I’m also setting in my CSS.

Now, to see all the CSS that the browser has computed for the “header” <div> at the time the page is inspected, look in the Computed Styles section. Notice that you can find out the values of properties you’re not setting directly, like the current width and height of an element, using Computed Style.

You can usually find any discrepancies between what you think the style of an element should be and what it actually is by comparing the Computed Style with the styles you (and your user agent) are setting on the element.

I hope this answers your question Michael! Good luck finding your CSS bug.

  count = count + 1;

a statement that often appears in a while loop, and

  i++;

a statement that often appears in a for loop, like this:

  for (var i = 0; i < 10; i++) {
    ...
  }

While this question is about JavaScript, these lines of code could appear identically (or almost identically) in many languages! In Head First HTML5 Programming, we speed through these language basics pretty quickly, so it's understandable that someone new to programming might be a bit confused on this point. Plus, and I hate to admit this, I think we completely forgot to explain what operators ++ and -- actually do! (We'll fix that on the next printing!)

The trick to understanding the first one is to remember that when you use =, you are assigning a value to a variable. You're not comparing two values; you do that with the comparison operator, which is ==.

So, when you write

  count = count + 1;

you are saying: "Take the current value of the variable count, add 1 to it, and then change the value of count to that new value."

So if count is equal to 4, and you run this line of code, after you run the code, the value of count will be 5.

Adding 1 to the value of a variable is something we do so often in programming that language designers have added shortcuts to make it even easier to add 1 to a variable with a number value. One shortcut used in many languages is the ++ operator. Writing

  i++;

is the same as writing

  i = i + 1;

It's just a shortcut to do the same thing. So, when you see a for loop like this:

  for (var i = 0; i < 10; i++) {
    ...
  }

there are three things happening in that for loop: the first part, var i = 0;, declares and initializes the the variable i to the value 0. Then the conditional expression is run: i < 10. This says, is i less than 10? Well, if we just started the loop it is less than 10, in fact it's 0. In that case, all the statements in the body of the for loop are run (that is, everything between the { and the }). Finally, the value of i is incremented with i++, making the new value of i equal to 1. Then you start over, except you skip the initialization bit. So you go right to the conditional expression: is i still less than 10? Yes, it's 1. So run all the statements in the body of the for loop again. And so on. When i is incremented to 10, then the for loop stops because the conditional expression is no longer true.

An analogous operator to ++ is -- which subtracts 1 from the value of a variable. In other words, writing

  i--;

is the same as writing

  i = i - 1;

I hope that helps clear up that reader question. Keeping send me your questions if you run into any problems. Thank you!

Although the CSS seems to render OK, my IDE doesn’t seem to like a lot of it. I’m using Intellij IDEA (Java IDE) which is HTML and JavaScript capable. I’m also using the current versions of Firefox and Safari (Mac OS/X, Lion 10.7.2). Of course, I’m only on chapter 3 so have no idea what the -webkit or -moz are. Do I need to include something else in my project?

What’s happening here is that Jack’s IDE, Intellij, doesn’t recognize the new CSS3 property border-radius, or the browser specific versions of this property. Here’s an example of the CSS we use in that example:

ul#playlist {
    border: 1px solid #a9a9a9;
    -webkit-border-radius: 5px;
    -moz-border-radius: 5px;
    border-radius: 5px;
    margin-top: 10px;
    padding: 0px;
    list-style-type: none;
}

We actually never get into explaining -webkit- and -moz- (and the other browser-specific CSS properties) in Head First HTML5 Programming, as we focus almost entirely on the JavaScript APIs, and will be going back to update our Head First HTML & CSS book to address updates in CSS.

Some of the new CSS3 properties haven’t yet been finalized (CSS3 is still very much in development) and many of the browsers implemented early versions of these new ideas, and use the -name- prefix (like -webkit-, -moz-, -o-, and -ms-) as a way to say, “This is Mozilla’s or Webkit’s idea of what the property should be, but it’s not written in stone yet.” So, to get your CSS to work in multiple browsers, you have to supply all the browser specific versions, plus the version that we think will eventually be the one that gets finalized in the standard!

Whew.

So, a new property like border-radius has a Webkit version, -webkit-border-radius, and a Mozilla version, -moz-border-radius, and so on. Webkit is the browser engine used by Chrome and Safari; Mozilla is the engine used by Firefox. -ms is for IE and -o is for Opera. The trick is to put the browser-specific versions above (what we think will be) the actual property name (in the ordering in the CSS rule) so that the browser will use the last one it recognizes, and so will override an older browser-specific implementation with the new, final implementation when it’s complete.

Not all properties have implementations in all the browsers yet, and some “final” (or close to final) versions have been implemented in some browsers (for instance, for border-radius, you can use border-radius instead of -webkit-border-radius, and it will work in the most recent version of Safari and in Chrome).

Anyway, as you can see, it’s a bit of a mess right now, but should get cleared up as time goes on. Jack’s IDE simply doesn’t know about these browser-specific properties (or, perhaps, the new CSS property at all) and so is highlighting these properties as potential problems. The key is to test in the browsers, and also check sites like caniuse.com. For example, if you search for “border-radius” on caniuse.com, you’ll see that current versions of Safari, Firefox, Chrome, and Opera all support the border-radius property now, but slightly older versions of IE and Safari either don’t support it at all or require the browser-specific property name.

In general, with CSS, if you want to use a “new” CSS3 property that may not be supported by all browsers (particularly if you think your users are still using old versions of browsers), you’ll want to make sure you either test to see if that user’s browser supports it (using Modernizr) and supply an alternative stylesheet if it doesn’t, or test to make sure that the page looks fine without that particular stylistic feature. For instance, if you are using CSS to do a complex layout then you’ll want to make sure the browser supports the layout properties you’re using and offer an alternative stylesheet with an older style layout if it doesn’t. For something like border-radius, generally, the page will look fine if your elements don’t have rounded corners so it doesn’t matter as much.

Thanks for the great question Jack!

1. HTML5 Markup isn’t such a big deal.

To understand this statement you need to first understand what HTML5 is. Is it just an incremental update to HTML4.01? Or is it something new and completely different (you might think so with all the hype around it)? The answer is really a bit of both. HTML5 does include many simplifications and additions to HTML markup, and so it is fair to call markup an incremental update (although it does have a few big additions like <video> and <canvas>). But, HTML5 also can be thought of as a family of technologies that include a whole set of new JavaScript APIs that interoperate with HTML5 markup. Let’s also not forget CSS3, which brings some powerful new styling and animation techniques to HTML5.

Check out the presentation to see some of the new markup included in HTML5. If you’re already up to speed on the markup in HTML4, most of the new markup will be fairly easy for you to get under your belt.

2. The power of HTML5 is JavaScript.

While we’ve all been hearing “HTML5 HTML5 HTML5″, the real unsung hero of HTML5 is JavaScript and the new set of HTML5 compatible APIs. With these APIs you can now incorporate geolocation, a drawable canvas, custom video experiences, drag and drop, large amounts of local storage and even multithreaded JavaScript into your web pages (more like apps these days), and that’s just naming a few of the APIs.

JavaScript has developed a bit of a bad rap as a scripting language over the years, when in fact it’s a sophisticated and powerful language. Today, it’s also a fast language, having seen 100x speed improvement over the last decade (with more coming). Sure, it has a few warts here and there, but these are easy to work around if you know about them. And, JavaScript is an easy language to get started with. We devote four chapters of our new book Head First HTML5 Programming to getting you up to speed on JavaScript.

So, If you want to make the most out of HTML5, you’ll need to learn JavaScript.

3. It’s not which standards document an API comes from that is important.

As we wrote Head First HTML5 Programming we commonly heard things like “Oh, geolocation is not part of the official HTML5 spec!” True enough. But it is an official spec of the W3C, and you know what, it doesn’t matter. Here is what matters: does every modern browser implement and support geolocation? That’s what we care about.

Sure, there is a time and place to be precise about specification relationships, but when we’re writing code, the important thing is “Will it be there for my users?”

4. How to know if you should embrace HTML5 now.

Check out the presentation for a simple flow chart to guide you. But for now it goes like this: If your users are using mobile devices, you should be thinking about using HTML5 today, as HTML5 browsers are common and heavily used on today’s smartphones and tablets.

If your audience is desktop based and uses largely modern browsers, you’re also good to go and should be looking into HTML5. However if your audience uses older versions of IE, you’ll need to be cautious.

In any case you always want to make sure you’re using feature detection (see below) and are up to date on which browsers support which features. Fortunately, there are a number of great resources for getting information about browser support for HTML5. A few of our favorites include:

• http://caniuse.com/.
• http://www.findmebyip.com/.
• http://html5test.com/.
• Wikipedia’s Comparison of Web Browsers page and Comparison of Layout Engines page.
• WHATWG’s Implementations in Web Browsers wiki page.

And of course, you should always test your web pages and applications in every browser you can!

5. Make it easy on yourself: graceful degradation and feature detection.

There are many ways to detect the features of HTML5 using JavaScript, from attempting to create an object to see if it’s supported, to checking to see if various window properties exist, to using custom methods like the <video> element API’s canPlayType method.

Needless to say, it’s important to check for new features so you can offer a fallback experience for users whose browsers don’t support that feature (e.g. an image or flash video instead of HTML5 video, an image or embedded Flash object instead of canvas, or even just a message indicating why the user might not be seeing what they expect and why). But with so many different ways of checking support for different features, you might be wondering if there isn’t a better way?

There is. The Modernizr JavaScript library is a popular open-source library that you can use to make it much easier to check for HTML5 and CSS3 features and load appropriate resources, such as different JavaScript files, CSS files, images, and so on, depending on support.

Check out the presentation for more concrete examples.

6. The <video> tag is the easy part; what about encodings?

If you’ve heard one thing about HTML5, it’s probably that it has a <video> element. And it’s true, by adding a <video&gt element to your HTML you can easily play video in your page without a plug-in. This is made possible by the folks writing the browsers, because they all agree on what the <video> element looks like. But when it comes to video formats, unfortunately, there is little agreement. Today, there are three different container formats, WebM, MP4 and Ogg, and which one you need depends on which browsers your users are using. If you’re delivering content to a narrow audience, say, users of the iPad, then your job is easy: you need only to deliver one format, MP4. If you want to support all popular browsers, then you need all three formats.

How? You’ll have to arrange to have the encodings done, and in the markup you can use the <video> element with the <source> element and provide multiple video files. To have more flexibility in creating a fallback if none of these types is recognized, you need to use JavaScript.

So, while getting a video into your web page is easier than ever before, making sure you’ve got a video that your users can actually play is still a bit of a mess.

7. The <canvas> is for more than just drawing.

The <canvas> element adds a native 2D drawing area to HTML.  At first glance, you might think <canvas> is best for creating simple drawing programs using lines, arcs, and rectangles, but you’d be short-changing yourself if you stop there.

In fact, if you have a look at the canvas demos on the web, you’ll see that it’s being used for everything from basic drawings, to fully interactive drawing applications, creating graphs, making animations, building games, and even rendering 3D scenes.

One interesting use for <canvas> is video processing. You can take video frames from the video player, process the frame data, and then write the data into a canvas for display. For instance, you might take green screen capture video, and add a background in real-time using this technique.  Similarly, you can use a canvas for double buffering image in games.

So, don’t overlook the <canvas>; it’s a powerful new feature of HTML5 that can be used for all kinds of graphics-related applications, and the JavaScript engines in modern browsers are now fast enough to handle the load that graphics and video processing require.

8. Some of the common JavaScript-based idoms for animation and effects are now supported by CSS3.

CSS has come along way from the early days, and with CSS3, we now have powerful features that you can use to create effects in your web pages that you once could do only with JavaScript.

For instance, used to be if you wanted an element to fade in and out on a mouse hover, you’d have to write some fairly complex JavaScript code or use a UI library like jQuery or scriptaculous. These libraries have by no means been replaced by CSS3, but there are a few things you can do now with no code at all.

The transition and transform properties are two new properties in CSS3 that let you create interesting effects and animations. For instance, you can create a fading effect by transitioning the opacity of an element. You can manipulate elements with transform functions like rotate and scale, and when you combine a transform with a transition, create some pretty cool animations.

In the presentation, we show two simple examples of using transition and transform.

9. JSON is the new king of content formats.

In 2004 XML was going to rule the world, however things didn’t quite work out that way.
These days, many developers are using JSON instead of XML. JSON, or “JavaScript Object Notation”, allows you to use the same format for your code and your serialized objects. You also get fast parsing for free from the browser when you retrieve remote JSON data. Every browser has a built-in JSON object with two methods: stringify, used to create a JSON string from a JavaScript object, and parse, used to create a JavaScript object from a JSON string.

Today JSON is widely supported across web service APIs, like Twitter and Facebook. And, because of the cross-domain restrictions with XHR, many web services are implementing JSONP, or JSON with Padding. While “JSON with Padding” isn’t the most insightful name, JSONP is a convention for implementing a callback into your own JavaScript code. It’s a simple concept but a little hard to get your head around. Check out Head First HTML5 Programming where we break it all down for you.

10. XHTML is dead, long live XHTML.

XHTML long ago lost its front-runner status  as the language of the web, with the death of XHTML2 and the rise of HTML5, but  despite rumors that doesn’t mean you can’t use XHTML; in fact we call it XHMTL5.

Remember that the difference between HTML and XHTML is that XHTML is proper XML. That means when you write XHTML you use strict XML syntax, and when you serve XHTML you have to use the XML mime type. The benefit of XHTML is that it is extensible (because it is XML) while HTML is not. The downside is that XHTML is strict, doesn’t play as well with other languages (like CSS and JavaScript) and wasn’t designed for building web applications.

So, to write XHTML5 today, add a namespace and use proper XML syntax (see the presentation for an example).

without needing a plug in. I recently had to implement a similar type of graphic in canvas for a project I’m working on, so I thought I’d turn it into a tutorial on how to make a pie chart.

Rather than just hardcoding the functions to make a specific pie chart, let’s write it so you can easily change the data. That way, you can reuse the code any time you need to display a pie chart. So, we’ll first create an array of data, an array of labels, and an array of colors:

var data = [120, 100, 140];
var labels = ["120%", "100%", "140%"];
var colors = ["#FFDAB9", "#E6E6FA", "#E0FFFF"];

Data contains numbers that add up to 360 (so we can make a complete circle). Each number corresponds to a segment of the pie chart. Labels contains strings that will be used to label the segments of the pie chart, and colors contains colors that will be used to color the segments.

Next we can write a function, drawSegment that will draw one segment, specified with the parameter i, using these values:

function drawSegment(canvas, context, i) {
    context.save();
    var centerX = Math.floor(canvas.width / 2);
    var centerY = Math.floor(canvas.height / 2);
    radius = Math.floor(canvas.width / 2);

    var startingAngle = degreesToRadians(sumTo(data, i));
    var arcSize = degreesToRadians(data[i]);
    var endingAngle = startingAngle + arcSize;

    context.beginPath();
    context.moveTo(centerX, centerY);
    context.arc(centerX, centerY, radius,
                startingAngle, endingAngle, false);
    context.closePath();

    context.fillStyle = colors[i]:
    context.fill();

    context.restore();

    drawSegmentLabel(canvas, context, i);
}

In this code, we first save the context so we can restore it later (that way, it’s safe to use with other canvas code). Remember, when you save/restore the context, you’re basically putting the context back into the state it was in you saved it.

Next, we find the center of the canvas, to use as the center of the pie chart, and compute the radius of the circle.

The starting angle is the sum of all the data so far (since each data point corresponds to a segment of the circle), so I wrote a helper function to sum up the first i segments of the array (see below). For example, if we’re drawing the third segment, i will be 2, and we’ll add 120 and 100, for a starting angle of 220. One of the trickiest things about learning canvas is understanding the starting and ending angles and the direction you’re drawing the arc, so review Chapter 7 in Head First HTML5 Programming if you get confused about this (I know I do even though I’d done it lots of times now!).

The ending angle is just the starting angle plus the arcSize, which is just the number in the data array corresponding to the segment we’re drawing. Note that I’m converting everything from degrees to radians, using another helper function (see below), since that’s what the context method to draw the arc expects.

Now we’re ready to draw the arc. We move the canvas “pen” to the starting point, which is the center of the circle, draw the arc, and then close the path, so we get a pie wedge shape. Remember that the last argument to the context.arc method is the direction we’re drawing the arc; in this case, false means we’re drawing in a clockwise direction around the circle. The starting angle starts from the east side of the x axis, and goes around clockwise when we use positive angle measurements, so that’s why we draw the arcs in a clockwise direction.

Finally, we need to fill the arc, so we pick the color from the array, and fill the path we’ve just drawn. We restore the context, and we’re done drawing that segment. The last thing we do in the function is call another function, drawSegmentLabel, to draw the label.

Before we get to drawSegmentLabel, here are the helper functions, degreesToRadians and sumTo:

function degreesToRadians {
    return (degrees * Math.PI)/180;
}
function sumTo(a, i) {
    var sum = 0;
    for (var j = 0; j < i; j++) {
      sum += a[j];
    }
    return sum;
}

The function drawSegmentLabel adds the labels to the pie chart. You might wonder: how are we going to get the text rotated to match the segments? The trick to rotating the text for the labels is to rotate the context - it's like you're picking up the canvas, moving it and rotating it, and drawing the text as as normal. By saving and restoring the context each time the function is called, we make sure that the context goes back to its normal position after each time we call the function.

function drawSegmentLabel(canvas, context, i) {
   context.save();
   var x = Math.floor(canvas.width / 2);
   var y = Math.floor(canvas.height / 2);
   var angle = degreesToRadians(sumTo(data, i));

   context.translate(x, y);
   context.rotate(angle);
   var dx = Math.floor(canvas.width * 0.5) - 10;
   var dy = Math.floor(canvas.height * 0.05);

   context.textAlign = "right";
   var fontSize = Math.floor(canvas.height / 25);
   context.font = fontSize + "pt Helvetica";

   context.fillText(labels[i], dx, dy);

   context.restore();
}

After saving the context, we figure out the center of the circle, and then the angle to rotate the context so we can draw the text. The angle is the same as the starting angle we used for the segment in the drawSegment function (ie, the sum of all the data so far, converted to radians).

Once we have the angle, we translate, or move, the top left corner of the context to the center of the circle and then rotate it (clockwise) to the angle that matches the starting angle of the segment. Then we adjust the horizontal starting point of the text so it's at the edge of the pie chart (since the text is right aligned, we're setting the right side of the text box here). I subtracted 10 pixels to get it a bit of space on the right side. We also adjust the vertical position of the text so it has a little space above it, and fits just below the top of each segment.

Once we've got the position for the text figured out, we set the text alignment and font size. Notice that I'm computing the size of the font based on the size of the canvas (the pie chart is also sized to the canvas). Feel free to play with the number 25 to adjust the font size until you are happy with it (and try changing the canvas size in the HTML to make sure it works at a variety of sizes).

Finally, we fill the text with the label for the segment.

Now all we need is the code to get the canvas and the context and call the drawSegment function to draw all the segments. This code assumes you've got a canvas with the id of "piechart".

canvas = document.getElementById("piechart");
var context = canvas.getContext("2d");
for (var i = 0; i < data.length; i++) {
    drawSegment(canvas, context, i);
}

And here's the HTML you need (adjust the canvas size and you should see the pie chart change size too!):

<canvas id="piechart" width="400" height="400">
</canvas>

Enjoy, and let me know if you make any pie charts. I've posted the full code on github; it's a little different--it's set up to create a PieChart object, and drawSegment and drawSegmentLabel are methods of the PieChart object rather than functions, but it is basically the same idea.

Head First HTML5 Programming will take your skills to the next level, especially if you’ve just finished up Head First HTML.

Head First HTML5 Programming is your ultimate tour guide to creating web applications with HTML5 and JavaScript, and we give you everything you need to know to build them, including: how to add interactivity to your pages, how to communicate with the world of Web services, and how to use the great new APIs being developed for HTML5.

Here are just some of the things you’ll learn in Head First HTML5 Programming:

• Learn how to make your pages truly interactive by using the power of the DOM.
• Finally understand how JavaScript works and take yourself from novice to well-informed in just a few chapters.
• Learn how JavaScript APIs fit into the HTML5 ecosystem, and how to use any API in your web pages.
• Use the Geolocation API to know where your users are.
• Bring out your inner artist with Canvas, HTML5’s new 2D drawing surface.
• Go beyond just plugging a video into your pages, and create custom video experiences.
• Learn the secret to grabbing five megabytes of storage in every user’s browser.
• Improve your page’s responsiveness and performance with Web workers.
• And much more.

We’d love to get you started now, with a free copy of Chapter 1:
Download Chapter 1

In this post, I’ll show you how to create a falling snowflake winter scene using HTML5′s <canvas> element and the canvas API. This little web app will display a canvas that fills the browser window. When you click on the canvas, a snowflake image is added to the canvas, which then proceeds to fall to the bottom of the window. When it reaches the bottom, it reappears at the top of the window, and continues to fall.

You can learn everything you need to create this program in Head First HTML5 Programming.

Click on the image to run the example.

Let’s start by writing the HTML. We’ll keep it as simple as possible. All we need is a canvas, and links to the JavaScript and CSS.

<!doctype html>
<html>
<head>
  <title>Winter</title>
  <meta charset="utf-8">
  <link rel="stylesheet" href="winter.css">
  <script src="winter.js"></script>
</head>
<body>
  <canvas id="scene">
  </canvas>
</body>
</html>

Next, the CSS. We want the canvas to take up the entire browser window, so make sure we don’t have any padding or margins on the body, and set the canvas to display as a block element (by default, on some browsers, it displays as an inline element, which means you get a little extra white space on the edges).

html, body {
    width: 100%;
    height: 100%;
    margin: 0px;
    padding: 0px;
}
canvas#scene {
   display: block;
}

Now, we’re ready to write the JavaScript. All the code is inside an anonymous onload function, including the variables and functions we need, like variables for the canvas element object, and the context we get from the canvas. We’ve also got a variable for the snowflake image we’re using, and an array to keep track of all the snowflakes.

window.onload = function() {

  var canvas = null;
  var context = null;
  var snowflakeImage = null;
  var snowflakes = [];

Next, initialize the canvas and context variables:

  canvas = document.getElementById("scene");
  context = canvas.getContext("2d");

and then the snowflakeImage:

  var tmpImage = new Image();
  tmpImage.src = "snowflake.png";
  tmpImage.onload = function() {
    snowflakeImage = tmpImage;
  }

Notice that we only have to load the image once, but we can draw it on the canvas multiple times.

Now, let’s set up the canvas so whenever you click in the canvas, we create a new snowflake to the canvas. We want the snowflake to appear where you clicked, so we need to get the x and y position of the click in the canvas. We’ll pass the x, y position to the function addSnowflake(), which we’ll write shortly.

  canvas.onclick = function(e) {
    var x = e.clientX;
    var y = e.clientY;
    addSnowflake(x, y);
  };

We’re going to use a Flake object to hold all the information associated with a snowflake, including the image, the x and y position, and so on.

Let’s create the Flake constructor. We’ll pass in the initial x and y position of the flake (where the user clicked), and the image (by passing in the image, we can easily use Flake for multiple kinds of snowflakes). We’ll set the width and height to the width and height of the image. Finally, we’ll add a function to update the y position of the flake so it falls to the bottom of the screen. If it reaches the bottom of the screen, then we can start it over from the top by setting it to a y position of just off the screen at the top of the browser window. You could, of course, create a much more complicated update function to better simulate flakes falling, but we’re going to keep it simple for now.

  function Flake(x, y, image) {
    this.x = x;
    this.y = y;
    this.image = image;
    this.width = image.width;
    this.height = image.height;

    this.updateY = function(maxY) {
      this.y += 1;
      if (this.y > maxY) {
        this.y = -(this.width/2);
      }
    }
  }

Now that we have the Flake constructor, we can write addSnowflake(). All addSnowflake() has to do is create a flake, and add it to the snowflakes array:

  function addSnowflake(x, y) {
    var flake = new Flake(x, y, snowflakeImage);
    snowflakes.push(flake);
  }

We’ve got flakes; now we need to draw them, and make them fall. We’ll create a drawFlakes() function that will draw all the snowflakes and update them by calling their updateY() methods.

  function drawFlakes() {
    context.clearRect(0, 0,
                      canvas.width,
                      canvas.height);
    for (var i = 0; i < snowflakes.length; i++) {
      var flake = snowflakes[i];
      context.drawImage(flake.image,
                        flake.x, flake.y,
                        flake.width, flake.height);
      flake.updateY(canvas.height);
    }
  }

First, we clear the canvas (so we don’t see the snowflakes in their previous positions), and then loop through all the snowflakes in the snowflakes array. For each flake in the array, we use the context.drawImage() method to draw the snowflake image at its current x, y position. This method also takes the width and height of the image we’re drawing, so we can just pass in those values, which are also stored in the flake object. Then we just update the position of that flake by calling the flake’s updateY() method, and continue looping. We’re passing in the height of the canvas to udpateY to use for computing the max y position of the flake.

So we have drawFlakes(), but how do we start the whole thing going? We can use setInterval and call drawFlakes() every 10 milliseconds so the flakes fall at a reasonable speed. Because we’re updating the y position only 1 pixel each time, we need to call drawFlakes() fairly often to get a reasonable speed for the falling effect.

var started = setInterval(drawFlakes, 10);

Try playing with both the interval speed as well as with the size of the y increment in the Flake updateY() method to see which combinations of values you like the best.

One final thing we need to do is to make sure that if you resize the browser window, the canvas resizes with it so you don’t have to reload the page. To do this, we’ll add a resize handler for the window.

  function resizeWindow() {
    canvas.width = window.innerWidth;
    canvas.height = window.innerHeight;
  }
  window.onresize = resizeWindow;

  resizeWindow();
}

That’s it! (Don’t forget to add that final } to end the window onload function definition). The full listing of the JavaScript code is below (slightly reordered), and you can try it here. And if you’re new to JavaScript and/or want to learn more about canvas, you can get up to speed with Head First HTML5 Programming.

If you create any of your own winter wonderland scenes with HTML5 canvas, let me know!

window.onload = function() {

  var canvas = null;
  var context = null;
  var snowflakeImage = null;
  var snowflakes = [];

  window.onresize = resizeWindow;

  canvas = document.getElementById("scene");
  context = canvas.getContext("2d");
  resizeWindow();

  var tmpImage = new Image();
  tmpImage.src = "snowflake.png";
  tmpImage.onload = function() {
    snowflakeImage = tmpImage;
  }

  canvas.onclick = function(e) {
    var x = e.clientX;
    var y = e.clientY;
    addSnowflake(x, y);
  };

  var started = setInterval(drawFlakes, 10);

  function addSnowflake(x, y) {
    var flake = new Flake(x, y, snowflakeImage);
    snowflakes.push(flake);
  }

  function Flake(x, y, image) {
    this.width = 110;
    this.height = 110;
    this.x = x;
    this.y = y;
    this.image = image;

    this.updateY = function(maxY) {
      this.y += 1;
      if (this.y > maxY) {
        this.y = -(this.width/2);
      }
    }
  }

  function drawFlakes() {
    context.clearRect(0, 0,
                      canvas.width,
                      canvas.height);
    for (var i = 0; i < snowflakes.length; i++) {
      var flake = snowflakes[i];
      context.drawImage(flake.image,
                        flake.x, flake.y,
                        flake.width, flake.height);
      flake.updateY(canvas.height);
    }
  }

  function resizeWindow() {
    canvas.width = window.innerWidth;
    canvas.height = window.innerHeight;
  }
}

Elisabeth Robson: What makes a great team?

Scott Berkun: Trust. Talent without trust makes for a bunch of disappointed talented people, who underperform against teams with less talent, but higher collaboration, based on trust. Trust sounds obvious, but most teams, organizations and families have a shortage of it.

ER: How is leadership different from management?

SB: They’re hard to separate. An effective leader does some management. An effective manager does some leadership. If you have to divide them, leadership is making good decisions about where to go, management is executing a plan to get you there.

ER: How is technical leadership different from any other kind of leadership?

SB: It’s more similar than not. A good leader earns trust (there’s that word again). A good technical leader earns a reputation for making good decisions around how to build technology, or which technologies to use, to solve a problem.

ER: If a programmer wants to move into a leadership position, what’s the most important thing you’d recommend for that person?

SB: That transition depends seeing the value of non-coding tasks. Convincing another developer to approach a problem in a better way may take an hour, but the payoff will be higher than if they had spent that time writing the code themselves.

ER: What motivates programmers to do their best work?

SB: It depends on the programmer. Good leaders ask their teams what motivates them, or what kinds of work they like the most. To stereotype, I’d say programmers like two things: 1) solving challenging problems 2) seeing those solutions help people.

ER: How do you get programmers to give good estimates for how long a piece of code, or project, will take?

SB: It’s a habit people have to develop. It starts by documenting estimates before work starts, and reviewing estimates when the work is over. Having healthy discussions about why the estimates weren’t accurate, and what questions could have been asked to make them more accurate, makes the next round of estimates better. The habit of asking reviewing estimates and asking questions at the end of iterations or projects fuels better estimates.

ER: What new technologies do you have your eye on to keep WordPress on the cutting edge?

SB: I watch people. The cutting edge is always where people are frustrated or annoyed. Listening to people gripe about their apps or their phones reveals what the next big thing will be. Great design comes from when technology is applied to a real problem, rather than technology invented for its own sake.

ER: You recently gave a talk about feedback at Hive2011. What’s the one most important thing for programmers to know about giving valuable feedback to their peers?

SB: Don’t let your ego make you an asshole. Taking pleasure in making someone feel bad about their work serves no one. If you are smart and creative you can find ways to give feedback to people so they want to hear more from you, rather than less.

ER: WordPress is always working on new things; what is the coolest new thing coming from WordPress?

SB: All I can say is never underestimate the power of open source.

ER: You recently self-published a new book, Mindfire. What’s the most important thing you learned from that process?

SB: This is the greatest time in the history of the world to be a writer. The freedom anyone has to write has never been greater.

ER: What’s the most innovative idea you’ve heard of recently?

SB: That there are no innovative ideas, There are only problems to be solved.

Thank you Scott!

Scott Berkun is the author of three bestselling books, Making Things Happen, The Myths of Innovation, and Confessions of a Public Speaker. His most recent book is MindFire: Big Ideas for Curious Minds. He managed teams at Microsoft from 1994-2003 on projects including versions 1-5 (not 6) of Internet Explorer. He currently works as a team lead on WordPress.com. He works as a writer and speaker, and his work has appeared in The New York Times, Forbes, The Economist, The Washington Post, Wired, NPR, and other media. He contributes to Harvard Business Review and BusinessWeek and has appeared as an innovation expert on MSNBC and CNBC. He writes frequently on his popular blog, scottberkun.com, and tweets at @berkun.