I’ve put up a node test server running on port 1337 (it was already forwarded to my server for reasons forgotten by me) and I configured node-static to take care of all my static files.

If you want give it a go, head to http://www.lofjard.se:1337 (EDIT: not available anymore) and have a look at an exact copy of this site running on another web server.

Setting up node-static turned out to be pretty simple. Example stolen from node-static’s GitHub page:

var static = require('node-static');

//
// Create a node-static server instance to serve the './public' folder
//
var file = new(static.Server)('./public');

require('http').createServer(function (request, response) {
  request.addListener('end', function () {
    //
    // Serve files!
    //
    file.serve(request, response);
  });
}).listen(8080);

Since this blog is currently all static files there’s not really all that much to my node code but I wanted to get a feel for how it holds up.

I also installed supervisor so that the server gets restarted should it crash.

Supervisor also has the nifty ability to monitor changes to your files so that it can automatically restart node when updates are made to the server code. Very handy in the development phase.

I recently incorporated the SyntaxHighlighter by Alex Gorbatchev so that I can easily show code examples in a nice way.
The default configuration seems to have a few quirks when it comes to working on mobile devices. Not all of them are SyntaxHighlighters fault to be fair, but here’s some of the things I’ve had to deel with.

Broken font fallback stack

The default font fallback stack in SyntaxHighlighter looks like this:

font-family: "Consolas", "Bitstream Vera Sans Mono", "Courier New", Courier, monospace !important;

Consolas is the new pretty font used in Visual Studio 2010 and it is my personal favourite for displaying source code, but it only exists on Windows Vista+. Well that shouldn’t be a problem since there is a big fallback stack defined and it ends with “monospace” witch means “any monospace font on the device”.

However, Android 2.x has a broken implementation of the fallback mechanism causing it to try “Consolas”, fail (since it doesn’t exist on Android) and then, instead of trying the next font in line, it just automatically selects “sans-serif”. Now I don’t now about you but I feel that sans-serif fonts have no business beeing around source code (unless they are a monospace sans-serif).

On top of this it seemed that none of my font-size tags had any effect on this sans-serif so the line numbers and lines of code didn’t align properly.
The problem got even worse on the iPhone witch successfully falled back on a monospace font but made the code lines much larger than the line numbers causing the alignment to be of by a factor of approx. 1.4.

Web fonts to the rescue

Web fonts have been around for a long time, but like the <video> element in HTML5, all browsers support a different font format.

The folks over at Fontspring have done a tremendous job putting together a “bulletproof” syntax for the @font-face css attribute that works on all current (and a lot of older) browsers.

This made me think of just putting “Consolas” on my server and making all the browsers download it and then use it as my first font in the fallback stack for SyntaxHighlighter. But “Consolas” is a proprietary font and thus that would have been illegal.

There is however a beautiful, free alternative to “Consolas” called “Iconsolata” made by Raph Levien so I decided to use that.

Since I didn’t feel like I hade the time to mess around with all the neccesary MIME-types in my Apache-configuration I decided to use the Google Web Fonts API which as it turned out already hosted the “Inconsolata” font. Great!

An additional line of CSS included on my site…

<link rel="stylesheet" href="http://fonts.googleapis.com/css?family=Inconsolata" />

…and a quick add to the font fallback stack of SyntaxHighlighter…

font-family: "Inconsolata", "Consolas", "Bitstream Vera Sans Mono", "Courier New", Courier, monospace !important;

…and now it works! Or so I thought.

The iPhone problem

While this fixed the font problem on my Android phone, the lines are still missaligned on my iPhone. It’s was now only missaligned by a factor of approx. 1.1 but it is still enough for me to get disturbed by it.

-webkit-text-size-adjust: 100%;

I added the above rule to the SyntaxHighlighter CSS file and now it renders beautifully in all of my devices.
The iPhone and my Android tablet even manages to get the scrolling correct for the code examples but my Android phone doesn’t. Well I guess you can’t have everything.

Responsive web design is the new rage in HTML. As much as I dislike buzzwords, this one is actually something worth thinking about.
Scott Hanselman wrote a blog post on the subject a while back and James Fuller has it at #5 on his top 5 list of things you need to learn right now.

If you don’t have a smartphone of your own to try your site out on you can make use of Google’s GoMo project which can render what your site will look like on an Android phone.

As of this post I’ve done my share of responsive web design for this site so if you’re watching this on your phone or tablet thinking “wow, this works really nice” then you know why.

Here’s what I did:

@media all and (max-width: 720px) {
  body {
    padding: 0 10px 0 10px;
  }

  .postpic, .fotoholder {
    max-width: 200px;
  }
}

@media all and (max-width: 480px) {
  body {
    padding: 0 2px 0 2px;
  }
	
  .postpic, .fotoholder {
    max-width: 150px;
  }
	
  body > header aside.links, section.blogposts div.ads {
    display: none;
  }
}

When the screen size decreases I make my “padding” smaller and I also decrease the maximum width allowed for my pictures. In the smallest version (less than 480 pixels wide) I also hide the “link bubble” in the header, leaving just the title and my smug face, and also hide the ads since they are about 460 px wide.

I also added a meta tag that makes sure the site is always rendered at the correct resolution for the device that views it. Mobile browsers on smartphones and tablets by default render the content using a much greater width and then scales down the site for backward compatibility with non-mobile-optimized sites.

My recently added syntax highlighter does seem to have some problems when rendered on phones with lower resolution but that is a problem for another day.

<meta name="viewport" content="user-scalable=no, width=device-width" />