It’s been nearly two years since I last redesigned this site. Don’t let me go that long again! The web is supposed to be a dynamic place, you know. Anyway, here’s the new look.

It isn’t drastically different from the old one. I’m still keeping it clean and simple, and the base colors are the same.

You might notice the rounded corners on some things. Yeah, that’s right. Web 2.0, here I come! I think rounded corners are only acceptable if accomplished with simple CSS. CSS3 is slated to include the border-radius property to achieve rounded corners. The specifications are not yet finalized, but Mozilla browsers have implemented the property with -moz-border-radius and WebKit browsers with -webkit-border-radius. Those are the properties that I’m using. That means you’ll get rounded corners in browsers like Firefox and Safari. Opera seems to work too. Internet Explorer, not so much. (Come on, IE has a hard enough time complying with current standards. You can’t expect it to look to the future!)

If you notice any bugs or would like to suggest any changes, let me know. After all, the site is really for you, dear user.

(I did briefly look at everything on a Windows box running IE8. It seemed to work – other than the rounded corners, of course – but if you notice any bugs in that particular browser, you know the drill.)

Two of the things that really spurred this design are Readability and Clippable. For about a month now, I’ve been using these bookmarklets while reading longs articles online. They help a lot. But it’s really a problem with the design of some sites that I feel the need to use them. I decided that I wanted to redesign my site with typography in mind.

I’m also now integrating Twitter posts into the blog. We’ll see how that goes. They’re styled differently, so there is a visual distinction between a tweet and a normal post. The idea is that I’m now just using twitter as a back-end to create short posts. If I want to, I can switch to some other microblogging service and you, the user, need never know the difference. (I could even just use Wordpress to create short posts! But that might get me kicked off the interwebs…)

Tweets integrated into the blog means tweets in the RSS feed, as well. That makes my RSS mash-up a bit irrelevant. If you currently subscribe to that, I’d recommend changing your subscription back to the normal feed. For those who don’t want to change, I’ve removed the Twitter feed from the mash-up’s input. That way you won’t have to read each of my tweets twice. The mash-up feed will now only include the blog and Flickr stream.

Blueprint

This design is built upon the Blueprint CSS framework. I’ve used it a handful of times before, but never properly. My method was always to link to the three Blueprint CSS files (screen.css, print.css, and ie.css) in the header and then toss in a link to my own stylesheet underneath them. I never used the compressor.

The idea behind the compressor is pretty simple. It allows you to maintain one central instance of Blueprint and use that to generate the CSS needed for each individual project.

The author’s walk through outlines the general idea:

    <ul>
    <li>Keep a core Blueprint folder checked out with <a href="http://git-scm.com/">Git</a> on your computer</li>
        <li>Create a settings.yml file within the Blueprint folder with all the specifics of each project using Blueprint</li>
        <li>Use the command line to generate <span class="caps">CSS</span> for a project on command
    <ul>
    <li>Incorporating any site-specific attributes
    <ul>
    <li>Namespace on all Blueprint classes</li>
        <li>Custom grid template rather than the standard 24 columns / 30px column width / 10px gutter width</li>
    </ul>
    </li>
        <li>Compressing any custom <span class="caps">CSS</span> and appending to the end of the Blueprint stylesheets</li>
        <li>Appending custom semantic selectors to the end of the Blueprint stylesheets</li>
    </ul></li>
    </ul>

When I first head about this, I though that the compression bit was all well and good, but I’ve never been really adamant about optimizing CSS for speed in the first place. I’m more concerned about compliance with standards and readability. Maintaining a central Blueprint instance didn’t appeal to me much, either. What really stood out is the ability to have custom semantic selectors.

CSS frameworks are neat. I’ve used a handful. Like any other tool, they’re not always appropriate. When they are, they have certain advantages and disadvantages. One of the main things that I dislike about them is that they encourage you to clutter your code with framework-specific junk. If you’re using 960.gs you’re going to have elements with classes like “container_x”, “grid_x”, “omega”, and “suffix_x” all over the place. With Grids you’ll have “yui-g”, “yui-b”, “yui-main”, and the like. Readability of code is diminished and you’ll probably end up suffering from a case of div-itis. Not to mention, you can forget about a strict separation of markup and styling. Sure, you could copy the style definitions for the specific framework classes into the classes or IDs of your own elements, but how many folks actually take the time to do all that copying and pasting? I sure don’t! The appeal in a CSS framework is to save time, not make the process of building a site longer. Plus, there’s an appeal in having the framework-related styling separate from the normal site styling. Such a separation makes the framework easy to update.

This is where Blueprint’s semantic classes comes in. It allows you to tell Blueprint to take one of your classes (or IDs) and apply to it the properties of one of Blueprint’s classes. A-mazing.

As an example, the header of this page might look something like this if built on Blueprint without the compressor:

    

        
Blog
        
Who
        
What
        
Connections
    
    

        
    


pig-monkey.com
Blah blah blah...


    

    

    

    

    

Look at those framework-specific classes all over the place. Nasty. But in the Blueprint compressor settings file, I can define some semantic classes.

"#top, h1#title" : "span-24 last"
"#top #nav" : "span-18 prepend-1"
"#top form#search" : "span-5 last"
"#description" : "span-23 prepend-1 last"
"#flickr" : "span-20 append-2 prepend-1 last"

Now my markup looks like this:

    

        
Blog
        
Who
        
What
        
Connections
    
    

        
    


pig-monkey.com
Blah blah blah...


    

    

    

    

    

Clean as a whistle! No useless divs, all elements semantically named, and not dependent on any framework.

As great as the compressor is, I do have a couple problems with it. When using the compressor, Blueprint intends that you only have 3 final (compressed) stylesheets: screen.css, print.css, and ie.css. Wordpress, of course, requires a style.css file to define the template. That’s no problem. I just a create a style.css file that has the theme information in it and then toss in a @import url(‘blueprint/screen.css’). Then in the Wordpress header I can put a link to style.css, print.css, and ie.css. Everybody’s happy.

Styling a website basically boils down to making a small change to the stylesheet and refreshing the page to see how that looks. Running the compressor after each change to combine the custom stylesheet with the screen.css file is not productive. So for the development process I tossed a @import url(‘blueprint/custom.css’) into the main style.css file. That works fine.

Then I finish building the theme. I’m ready to compress the stylesheets, so I remove the call to the custom stylesheet in style.css. I tell the compressor where the custom stylesheet is and have it combine it with the screen.css file. I run the compressor, reload the site, and everything explodes.

Just when I thought I was done!

The problem is that in the stylesheet the compressor generates, it puts my custom styles above the semantic classes. Throughout the development process, I was calling the screen.css file (which includes the semantic classes) before the custom stylesheet. As you no doubt know, stylesheets cascade. You can’t just switch up the order of elements without breaking stuff.

Oh well, I thought. At this point I was tired working on the site and didn’t care enough to fight it. I just put the line to call the custom sheet back in style.css after Blueprint’s screen.css file. I still feel like the whole semantic classes bit is enough of a reason to use the compressor, even if I’m not actually compressing my main stylesheet!