pig-monkey.com - css

Mark Two

2012-09-15T00:00:00-07:00

Hi there. It’s been a while.

I took a year off from blogging. That wasn’t intentional. I just didn’t have anything to say for a while. Then I did have something to say, but I was tired of how the website looked. If the design doesn’t excite me I tend not to want to blog. (Call me vain, but I want my words to look good.) And redesigning the website – well, that requires an entirely different set of motivations to tackle. It took me some time to get that motivation, and then before I knew it we were here: 10 days short of a year.

During the development process I referred to this design as “mark two”, as it was the second idea I tried out.

The website still runs on Django. The blog is still powered by Vellum, my personal blog application. I’ve been hacking in it for over a year now (even when this website was inactive) and it is much improved since the last time I mentioned it. In the past six months I’ve seen the light of CSS preprocessors. All of the styling for this design is written in SASS and uses the excellent Compass framework. The responsive layout is built with Susy.

If you’re interested in these technical details, you will also be interested to know that the entire website is now open-source. You can find it on GitHub. Fork it, hack it, or borrow some of my CSS for your website.

The other big news is that I have begun to categorize blog posts. Yeah, it’s 2012 and I’m a little late to the party on that one. You may recall that I only began to tag posts in 2008. As it stands right now, all posts are just placed in the great big ameba of a category called “General”. Eventually, they will all have more meaningful categories – I hope. But it will be a while.

Things ought to be more active around here for the foreseeable future.

A New Look

2010-05-07T00:00:00-07:00

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:

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:

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!

An Ubuntu VPS on Slicehost: Wordpress

2008-06-10T00:00:00-07:00

As mentioned previously, I’ve recently moved this domain over to Slicehost. What follows is Part Four of a guide, compiled from my notes, to setting up an Ubuntu Hardy VPS. See also Part One, Part Two, and Part Three.

I prefer to install Wordpress via Subversion, which makes updating easier. We’ll have to install Subversion on the server first:

1	`$ sudo aptitude install subversion`

After that, the Wordpress Codex has a guide to the rest of the install.

Nothing further is needed, unless you want fancy rewrites. In that case, we’ll have to make a change to your Nginx vhost config at /etc/nginx/sites-available/mydomain.com. Add the following to your server block under location / {:

# wordpress fancy rewrites
if (-f $request_filename) {
    break;
 }
 if (-d $request_filename) {
     break;
  }
  rewrite ^(.+)$ /index.php?q=$1 last;

While we’re here, I usually tell Nginx to cache static files by adding the following right above thelocation / { block:

# serve static files directly
location ~* ^.+\.(jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|css)$ {
    root  /home/user/public_html/mydomain.com/public;
    expires 7d;
    break;
}

That’ll go in the https server section, too. Now, enable rewrites in your Wordpress config. I use the following “custom” structure:

/%year%/%monthnum%/%day%/%postname%/

Then, restart Nginx:

1	`$ sudo /etc/init.d/nginx restart`

And there you have it! You know have a working, new web server and mail server.

(Previously, we did a basic setup, installed a web server, and installed a mail server.)

Beautifying

2008-06-10T00:00:00-07:00

Another redesign! This one only 6 months from the last. How remarkable is that?

The base template and heavy CSS of the last design made this change relatively simple. This time around, I’m using YUI Reset and YUI Fonts. I started using both of them a month or two ago on a couple other sites. It’s hard to imagine building a site without them now. They take a lot of headaches out of CSS.

This design is not using YUI Grids. I have used it before, but I don’t think it offers any benefit with this kind of design. It’s more suited toward a content intensive site with many nested divisions. Something like Yahoo’s front page.

You’ll also notice a Twitter feed on the top of the index page. I’ve been trying to figure out what the appeal of Twitter is, but so far, it’s escaped me. I figured embedding tweets on the site would provide extra encouragement for me to try it out. I think Twitter may lend itself to my summer on the road, too. So, we’ll see how long that lasts. It seems to be noticeably slow, so I might have to find another way to pull the data.

Another new feature is tags. I started tagging posts a while ago, but haven’t displayed them till now. The majority of posts are not tagged. Maybe someday I’ll go back and tag the 1,300 old posts – but I doubt it.

Some kinks of the design are still being worked out, but if you notice anything strange – whether it be from the redesign, server move, or mail move – let me know.

A Redesign

2007-12-08T00:00:00-08:00

So, things are looking a little different around here, no? I’ve had this design floating around in the grey-matter for a spell, but I didn’t think I’d start on it for a while yet.

Then I got bored.

I whipped it up last night and today. A lot quicker than I thought. There’s still a few tweaks I want to make, but it looks so much better than the last one, I decided to put it up before it was polished.

The design is very CSS heavy – though “heavy” might not be the right descriptor, as the whole thing is rather quite light in terms of size. CSS dependent. How’s that? The last few visions of this site have been CSS dependent, but in this one – inspired in large part by CSS Zen Garden – I’ve done my best to take out all styling from the pages and put it in the stylesheet. Of course, there’s probably a bit of legacy styling lurking here-and-there in various old blog posts. Let me know if you stumble on any.

The design has been tested in Firefox on both OS X and Ubuntu, as well as Safari in OS X. Let me know if you stumble upon any bugs, unless you’re using IE. Actually, if you’re using IE and want to send in a screenshot, I’d be curious to see how the site renders.

I’m sure someone will be curious about the stripes. I put them in there as a joke and placeholder till I figured out what I wanted to do with the background, but hell if they don’t look halfway decent. (It always ends up with me that some of the best design features start as jokes are bugs.) So, for now, they stay.

XI

2007-02-20T00:00:00-08:00

There’s nothing like a redesign to welcome Spring in (and it is Spring – I’ve seen Mosquito buzzing around and, just today, berries growing on Oregon Grape.) The inspiration hit me yesterday morning, and I whipped it up in a day. It’s a little more Web 2.0-ish, but I haven’t completely fallen to the darkside – no gradients or rounded corners.

A marked improvement from the previous design.

I twiddled my thumbs for a while, trying to think of a way to display everything that used to be in the sidebar, before I decided that it was overrated. So, you’ll now find the search box at the bottom of the page and a shiny new Archives page, brought to you by the Clean Archives Plug-in. It’s not exactly dial-up friendly, so I’ll probably fiddle with it a bit more in the future.

How do you like the “pig-monkey.com…” bit over to the right? That was totally a fluke. It wasn’t supposed to end-up there, but I thought it looked good.

As usual, I have no idea what version this is, so it’s been assigned the arbitrary number of 11. Let me know if you find any bugs. Unless you’re using Internet Explorer. I know the site looks funky in that pile of shit. (And I mean no offense to piles of shit. They’re productive members of our society.)