I’ve been seeing on the web lately that a lot of people are still having a hard time “getting” CSS. It’s not really code, in that it doesn’t execute, so it doesn’t really look right to programmers. Yet, it a kind of language, in that it has a syntax and a grammar, that is very terse, and not exactly straightforward – tough on the graphic design folks I know.

However, CSS has distinct advantages over the classic ways of styling and laying out HTML. It’s biggest advantage is write-once / style-anywhere: change a line of CSS in your stylesheet file, and every page that uses that stylesheet has the new style applied. This is a double-edged sword: it saves a lot of time once your style is put together, because any style changes do not have to be applied across every page (remember the <font> tag? Ick!). But, change the wrong line, and every linked page suffers! With great power, comes great responsibility.

Really, though, there’s a few simple rules to CSS, and a few caveats to learn. To try and help, I thought I’d lend a hand and share what I know. This is all from my experience building web pages. I’ve not found a teacher yet that really tries to teach CSS; often given the tools we currently have, it’s easier to use tables and tags for layout and style, respectively.

Here’s the basics:

1. A line or block of CSS is called a rule. The rule has two parts: the “Selector”, and the style block. The style block contains one or more style statements, with an attribute, and value specified for that attribute.
2. Styles apply to elements in HTML. The CSS Selector determines to which elements the style applies.
3. Styles apply in order. This means that if more than one rule applies to an element, the later one, either later in the same stylesheet, or in a stylesheet that is loaded after a previous sheet, override the earlier.
4. More specific selectors get preference – even if the more specific rule is before the more generic rule.
5. The !important also gets preference.
6. Extra white space is ignored.
7. In the style block, style attribute/value pairs should be separated with a ‘:’ and end with a ‘;’.

Building Selectors

Tag Selectors

You can specify all <p> tags very easily. The selector? Just p.

p { text-align: left; }


With that rule applied, all paragraphs specified by a p tag in the HTML will have text aligned left. More examples:

h1 {
font-weight: bold;
text-align: right;
font-size: 18pt;
}
div {
display: block;
}


It’s should be easy enough to interpret that h1 rule: the text will be bold, aligned right, and 18pt. The div – diplay: block – is a layout thing. In HTML, there are block elements and inline elements – headers (h1-h6) and paragraphs are block by default, but <em> or <strong> tags are rendered inline.

What does that mean? A block element renders on it’s own line. There will be a line break before and after a block element. Essentially, it “blocks off” it’s own part of the page. An inline element displays exactly so: in-line. A <strong> tag is intended to bold text within a paragraph or heading, for example. Of course, using CSS, you can change this behavior. You could make the strong tag render as a block, and make it italicize the text rather than bold it, if you wanted to. CSS styles always override the browser’s default styling (this will be useful later!).

Tag based selectors are fantastic – you can re-purpose HTML to display exactly as you like it, and it will do your bidding. Any time you can use an existing tag to mark up your data or content in a way that makes sense, you should do it – this is called semantic HTML. The best semantic tags are the basic ones:

• Headers (h1-h6)
• Paragraphs (p)
• Numberd Lists (ol and li)
• Bullet lists (ul and li)
• Abbreviations (abbr and the title attribute – look at the word CSS in the first paragraph of this article)

Class Selectors

Sometimes, you need to specialize a tag so that it has a specific style. You want to re-use the tag and style, but not in absolutely every instance of the tag. This is where classes come into play.

<div class="note">
This is a special note.
</div>


Above we have a <div> tag, and we’d like to make it look like a “note” or a notation of some kind. It should get set apart from our content in some way, and styled appropriately. However, we don’t want every <div> block to look like a note. So, we’ve added “note” to the class attribute of the <div> tag. That way, we can craft a CSS selector that doesn’t target the tag, it targets the class. That CSS selector will look like this:

.note {
background-color: yellow;
margin: 5px;
}


Now the <div> tag shown above will have a yellow background, and a 5 pixel margin surrounding the block. div’s are rendered as blocks by default; the <span> tag is the inline equivalent.

Don’t be too hasty to mark up your code with a bunch of classes. There are times when they make sense – you have a class of block elements that need to be styled a specific way. However, if there’s an HTML tag that already makes sense for that purpose, use it instead. That makes your code more semantic, which means it is easier to maintain and read. It also keeps the code shorter if you can use a tag rather than a tag + class combo.

ID selectors

OK, so let’s say you have a specific element on a page that you need to target. Say it’s the logo, and you want to make sure it appears in the top-left corner of your page. You can give that element an ID, and then build a selector to style it. Like so:

<img id="logo" src="/img/logo.jpg">


Now that you’ve got the id in your HTML, you can style it like so:

#logo {
position: absolute;
top: 0px;
left: 0px;
}

That bit of CSS will grab the logo image and put it in the top, left corner of the page. (It also pulls it out of the document flow – that’s a whole other article, though!)

Specificity

So now that you’ve got an idea of how these selectors get built, you can start to get a feel for specificity. Here’s the rules on that:

• Tag selectors are the most general.
• Class selectors are more specific than tags. Given a tag rule and a class rule, the browser will apply override styles in the tag rule with those from the class rule.
• ID selectors are the most specific. Given a tag, class, and id rule, the browser will over ride tag and class style with those of the id rule.

So, given this CSS:

#logo {
border: none;
position: absolute;
top: 0px;
left: 0px;
}
img {
display: block;
border: 1px solid black;
}
.special {
border: 2px solid red;
margin: 3px;
}


The <img> with id=”logo” will have no border, and it will be positioned in the upper left corner. This is because the id rule is considered the most specific rule, even though it’s an img tag.

All images in the document will have a black border of 1px width. An image with a class=”special”, however, will drop the 1px black border, and have a 2px red border, as well as a 3px margin on all sides. The class rule is more specific than the tag rule.

Note that in this case, the order of these rules doesn’t matter; they have clear specificity distinctions. Order only matters when the specificity is equal: if you are styling the img tag in one stylesheet, and then re-styling it in a second stylesheet, whichever sheet loads second in the HTML will be the overriding rule.

Conclusion

There’s a lot more that you can do with stylesheets beyond this. Look out for the next post, which will be about combining selectors (using tags, ids, and classes in the same rule), and give you some more style attributes.

Tags Covered:

• div
• em
• h1-h6
• li
• ol
• p
• span
• strong
• ul

Style Attributes Covered:

• background-color
• border
• display
• font-size
• font-weight
• left
• margin
• position
• text-align
• top

My plan was to make a special category of links in Wordpress. Call it something special (how’s about “Playlist”) and add a bunch of links to .mp3 files posted out on the ol’ internet.

Couldn’t find a plugin to do exactly what I wanted, but I knew the Podcasting Plugin basically extended the RSS functionality of Wordpress to add special tags to the feed. Looking at the source of WP, as well as the Podcasting plugin, it became almost trivial to write a plugin to create a special “feed” format (xspf). From there, I created a template XSPF file, and pulled the links with the get_bookmarks command. (Note that I use the word “feed” in quotes, as XSPF is not really intended as a “feed” format to my knowledge.)

Wordpress’s documentation is excellent. Their coding standards are awesome – that’s what makes this quick synthesis and creation possible. I hope to do a little more work with this plugin, so I can push it to the Wordpress Plugins archive. I really love this piece of software, and if I can, I want to contribute when I extend it in a useful way.

Take a look over here if you’d like to use the XSPF plugin yourself.

We’ve all heard about Ruby on Rails. “It’s so great,” they say. “Ruby is so simple, and efficient,” I hear. “There’s a cool guide that has Foxes!” says some other guy from the back.

But I already know PHP. I like PHP. In fact, I really like PHP. It has that old-school C style syntax, and yet, it’s just frustratingly different enough from C to make it enjoyable to code in. (I use 4; 5’s good too, but I haven’t bothered to seriously update, because my hosts still use 4 on the majority of their boxes, including the one I’m on.)

So what great MVC package is there for PHP similar to Rails for Ruby? Well, there’s PHP on Trax. A plus is that it fairly closely follows Rails. But, it requires PHP 5. Hmm. Yeah. 5’s great, but no thanks right now.

There’s also TaniPHP, which supports PHP 4. But that’s not been updated in ages, and it looks like it won’t be.

And then there’s CakePHP. PHP 4 support, check. Inspired by Rails, check. Good documentation, check. Active community, check. Fantastic.

So here’s my adventure installing CakePHP on Mac OS X. You can follow along, if you like.

Step Zero:
Install PHP and MySQL for OS X. I did this a long time ago, but if you’re just getting started, you’ll probably like to do this. Otherwise, things are really not going to make sense later. There are great instructions for installing PHP & MySQL by hand on Apple’s Developer Connection, but I’m not setting up a production box, I’m setting up a development box. For that, I do things the easy way. I’ll optimize later.

So here’s the easy way: Marc Liyanage’s OS X Packages. Easy, helpful, just follow his instructions.

Step One:
Download and unzip Cake. Because I’m developing multiple Cake apps, I’m going to put the resulting directory in my /Library (that’s Root Library. Not the User or System Library.) On most Unix systems, a shared Cake install goes to /usr/lib.

The latest stable version at the time of this writing is 1.1.5.3148. Go ahead and download it from CakeForge. Once you’ve unzipped it, rename the resulting folder “Cake” and move Cake to /Library. Now you’ll have your Cake Libraries installed in /Library/Cake. Recursively delicious.

Step Two:
It’s likely you want to work on your Cake application somewhere other than /Library. And you probably don’t feel like modifying httpd.conf either. So good news – you can simply move the /Library/Cake/app folder wherever you feel like working – and name it whatever you like. You can also duplicate this folder and create multiple Cake apps. I simply put it in my home directory. Thus, I end up with /Users/myhomedir/app. If I want to start a blog application (like the tutorial app, for example) I’ll duplicate that folder and rename it ‘blog.’ I can duplicate this folder over and over to create my applications.

Step Three:
Now that you have your library and applications folders in place, you need to move Cake’s webroot directory into the place where you want to serve your files from. For example, when you activate Personal Web Sharing, the Apache serves files from /Library/WebServer/Documents. If I move /Users/myhomedir/app/webroot to /Library/WebServer/Documents/webroot, then my Cake application will be accessible at http://localhost/webroot/. If I copy the contents of app/webroot, to /Library/WebServer/Documents, then my Cake app will simply serve out of http://localhost.

I like working out of my home directory, though. Fortunately, Personal Web Sharing also enables the Sites folder of my home directory to serve files: http://localhost/~myhomedir/. Using the blog example, I’ll typically move the webroot folder (in /Users/myhomedir/app) to /Users/myhomedir/Sites, and then rename it ‘blog.’ Now, my Cake blog will be served from http://localhost/~myhomedir/blog/. Flexible, and handy.

Step Four:
Now all your files are in place. To give Cake a working install, though, you’ll need to tell it where your libraries and app files are!

Going back to the blog example, let’s review:
My Cake Libraries are in /Library/Cake.
My Application Folder is /Users/myhomedir/blog.
My Application Webroot is /Users/myhomedir/Sites/blog.

First, modify the index.php file in your webroot. Look for the comment box that talks about Cake being installed in a directory layout different from it’s distribution. Modify the code like so:

/**
* These defines should only be edited if you have cake installed in
* a directory layout other than the way it is distributed.
* Each define has a commented line of code that explains what you would change.
*
*/
if (!defined('ROOT')) {
  //define('ROOT', 'FULL PATH TO DIRECTORY WHERE APP DIRECTORY IS
               //LOCATED DO NOT ADD A TRAILING DIRECTORY SEPARATOR';
  //You should also use the DS define to seperate your directories
  //define('ROOT', dirname(dirname(dirname(__FILE__))));
  define('ROOT', DS . 'Users' . DS . 'myhomedir');
}
if (!defined('APP_DIR')) {
  //define('APP_DIR', 'DIRECTORY NAME OF APPLICATION';
  //define('APP_DIR', basename(dirname(dirname(__FILE__))));
  define('APP_DIR', 'blog');
}
/**
* This only needs to be changed if the cake installed libs are located
* outside of the distributed directory structure.
*/
if (!defined('CAKE_CORE_INCLUDE_PATH')) {
  //define ('CAKE_CORE_INCLUDE_PATH', FULL PATH TO DIRECTORY WHERE
        //CAKE CORE IS INSTALLED DO NOT ADD A TRAILING DIRECTORY SEPARATOR';
  //You should also use the DS define to seperate your directories
  //define('CAKE_CORE_INCLUDE_PATH', ROOT);
  define('CAKE_CORE_INCLUDE_PATH', DS . 'Library' . DS . 'Cake');
}

Now Cake knows where to find it’s library and application files.

All that’s left is to setup the database connection. Easy peasy: go to the application directory (/Users/myhomedir/blog). You’ll see a “config” folder. Within that folder, duplicate “database.php.default” and rename the copy database.php. Open up this file in your text editor of choice (I like jEdit as far as programming, by the way).

Cake is nice in that you can be simultaneously running a few databases in order to have a ‘testing’ environment and a ‘default’ environment. Since this is just a development box, I generally just modify the default array. For this setup, you need only change the “login”, “password,” and “database” values to their appropriate MySQL values. For example:

var $default = array('driver' => 'mysql',
      'connect' => 'mysql_connect',
      'host' => 'localhost',
      'login' => 'mymysqluser',
      'password' => 'foxessuckoknotreally',
      'database' => 'blog',
      'prefix' => '');

Step Five:
Start coding!

That’s all there is to it. You’re ready to code up the Blog tutorial, or start your own application. And a big plus is that for any major Cake changes, you can just install the new libraries into /Library/Cake, without having to change your application code!

Out.

Got a pet project I’m gonna lay on ‘ya. It’s a Google Search builder.

One of the fun things about Google is the interesting stuff you can find by just surfing and modifying your searches. But it’s such a hassle typing all the time. You gotta put your hand on the mouse to click links anyway, right?

So with this (very beta! so beta, it’s alpha!) page, you can drag-and-drop words. The green box is words you’re looking for, the red box is words you’re ignoring. The orange box is a shelf to save interesting results in. Yellow words are draggable. Give it a shot. Click the “Semi-Live” to get a new page of results every time you drag a word around.

One caveat: This does break the “back” button. It’s all AJAX-y and cool, but I haven’t given it any kind of memory yet. I’ll get to it.

Rock.

Soooo…. I’ve set up this blog, right. It’s right here. You’re reading it. Good on ya.

And Blogger makes it really easy to add Google Adsense to the blog. Real easy. ‘Cuz Google owns Blogger. Cool beans. It’s all good.

But, you’ve got one spot (according to the Blogger Template tools) that those ads can go. I’m a rebel, so I manually re-placed the adds over in the Sidebar where they don’t look like some crazy post where I when jumbo-doodle-cakes talkin’ ‘bout Pistons Collectible Gear in crazy link-type format. Fantastic.

Then I went to change the color scheme of the Adsense. That’s when it hit me. Boom. Jackhammer. You simply can’t move the Adsense. We want it up top. That’s it.

So I re-moved it down to the side bar and figured I’d fix the colors in the code. If you’re like me and you’ve moved your Adsense button, don’t ever touch the Adsense tab in Template editor, or you’ll find all your hard work undone.

So I go to edit the colors. I do so. The Adsense code is nice in that it gives you helpful javascript variables that you can set to the appropriate color as you see fit. I did so. I preview’ed. Everything is cool.

But when I go to re-publish my site, the colors won’t stick. The Adsense is right where it’s supposed to be. It looks OK. But it’s stuck color-wise. Which is really odd, because it works in the Blogger Preview. But not fo-real I guess. Not cool, guys.

Huh.

UPDATE: Well, the colors updated between runs of Firefox. Which is interesting, because the first thing I tried was a reload, followed by a reload-frame, followed by a clear of the cache. Another interesting quirk: when I went to update this post, Firefox would routinely crash. I am now updating in Safari. Freaky.

Huh again.