I’m all about efficiency when I’m writing web code. Any time I find myself writing the same functionality more than once or twice, I try to consider whether my repeated code could be wrapped into a function of some sort.

Navigation is often one of those areas where I try to improve my efficiency. I like my navigation elements to pull double duty. I want them to:

1. Show the user where they can go, and
2. Show the user where they currently are.

In other words, I want some sort of visual indication in my navigation that shows my user which section of my site they’re in. You can see this on the CSS Newbie site: if you click on the TOC (Table of Contents) link in the bar at the top of the page, you’ll see that link gets special styling when the table of content loads.

Now, I could manually set this on every page using a CSS class. But that’s inefficient — depending on the size of my site, I could end up writing dozens or hundreds of lines of one-off code. And why go to all that work, when you could just wrap it all up into a nice JavaScript function?

First, I’ll explain the logic behind my functions — because they won’t work equally well for every site. Then I’ll walk you through a few examples of the code that makes it all happen.

The Logic

All of my functions assume a very clean, straightforward directory structure. For example, if you have an About section, a Blog section, and a Contact section on your site, a logical directory structure might be:

/
/about/
/blog/
/contact/

And if you had several blog entries inside your blog directory, your structure might grow like this:

/
/about/
/blog/
/blog/post-one/
/blog/post-two/
/blog/post-three/
/contact/

And therefore, a function could logically assume that anything inside the blog directory should be considered a part of the blog section of your site, and mark the blog link as active for those pages. This makes our job a lot easier. And luckily, most CMS platforms make this sort of directory structure pretty easy to create.

The functions also assume that you have either a fairly shallow directory structure, or that you’re not linking to too many similarly nested directories. What I mean by this is, if you have this sort of a structure:

/
/contact/
/contact/me/
/contact/me/here/

And you wanted to link to both /contact/ and /contact/me/here/ in your navigation bar, you might run into problems distinguishing between the two. There are ways to increase precision, but they come at the cost of flexibility.

But enough of that. Let’s get to the good stuff!

A JavaScript Solution

I’ve written about this method before, when I previously talked about building intelligent navigation bars. This technique is nice because it doesn’t rely on any JS frameworks, so you can add it to older sites without needing jQuery or the like. The basic function looks like this:

function setActive() {
  aObj = document.getElementById('nav').getElementsByTagName('a');
  for(i=0;i<aObj.length;i++) {
    if(document.location.href.indexOf(aObj[i].href)>=0) {
      aObj[i].className='active';
    }
  }
}

This function looks for an element with an id of “nav” (presumably your navigation bar), then looks at each of the anchor tags inside it. It then compares the anchor tag’s href tag with the page’s URL. If the href tag is contained within the URL anywhere, it gives that link a class of “active,” which I can then style specially in my CSS.

As an example of what I mean by all that, if I had an anchor tag in my navigation bar that linked to “/blog/” and the page I was on was “/blog/this-is-a-post.html”, my blog link would be styled as active, because “/blog/” is contained within “/blog/this-is-a-post.html”.

As a final note, you wouldn’t want to call this function until the page was finished loading: if you call it too soon, your links won’t exist yet! So you can either call it at the very end of your document, or dynamically call it when your page is done loading, with something like this:

window.onload = setActive;

A jQuery Solution

If you are already loading a framework like jQuery (like I do on almost every site I work on these days), this sort of functionality could be written even more succinctly. And like I said earlier, I’m a sucker for efficiency. Here’s a jQuery solution that does essentially the same thing in a much smaller space:

$(document).ready(function() {
	$('#nav a[href^="/' + location.pathname.split("/")[1] + '"]').addClass('active');
});

This function is making use of both native JavaScript and jQuery tricks to reach a whole new level of brevity. First, the whole thing is wrapped in a “document ready” function, which means it won’t fire until the page is loaded and our links are in place. Next, we’re looking for anchor tags inside our “nav” ID. And really, we’re looking for a very specific anchor tag: one whose href starts with (^=) a slash, followed by a part of our page’s location (location.pathname). Specifically, we’re looking for the first directory in our page’s URL.

We’re doing this by making use of the JavaScript split() method, which lets us take any string (for example, “/blog/this-is-a-post.html”) and break it into an array based on a substring (in our case, the forward slash). If you’re familiar with PHP, it’s similar to the explode() function. In our example, we’d end up with a three-part array that looked like this:

["","blog","this-is-a-post.html"]

Which means that if we look at the second value of our array (arrays start counting at zero, so [1] is the second value), that should give our first-level directory (”blog”, in our example). This lets us match any subsequent child directories with our parent in the navigation bar.

Tweaking for Home Links

Our jQuery function works great in most scenarios, but it fails if you have a “home” link where you’re just pointing to the root directory, like this:

<a href="/">Home</a>

And because I tend to have a link like that, I needed a workaround. Here’s a way to get around that with just a little more code to account for our special case:

$(document).ready(function() {
	if(location.pathname != "/") {
		$('#nav a[href^="/' + location.pathname.split("/")[1] + '"]').addClass('active');
	} else $('#nav a:eq(0)').addClass('active');
});

Here, we’re checking to see if we’re in the root directory. If so, we’re skipping the loop through our anchor tags and just making a specific anchor tag active. In this case, I’m giving the active class to the first anchor in our list (which is the most common location for a home link).

And that’s that. If you know of even more efficient or fool-proof ways to accomplish this task, I’d love to hear about them in the comments section. Or if you’re skilled in a framework other than jQuery, feel free to share the equivalent code!

Note: I apologize for the long gap between articles. I had some problems while rebuilding my PC (DOA motherboard) and was without my computer for several weeks.

But it occurs to me that I have a lot of smart, savvy readers here on CSS Newbie — and maybe, just maybe, you’ll be able to help me find the perfect shopping cart. Below, I’ll explain specifically what I’m looking for (and a bit about what I’m not looking for, too). If you know of a cart that meets my needs — or even just some of them — please do not hesitate to let me know! I’m hoping that the comments on this article will prove as plentiful as Starbucks on the open prairie. And twice as useful.

I Want a Simple, User-Friendly Cart that Stays Out of My Way.

That about sums it up, really. But for more detail, here’s what I want/need in a cart:

• A self-hosted solution. If it weren’t for this requirement, I think Foxycart would be my #1 contender. Consider that a hint — if you know of something Foxycart-eque, but is self-hosted instead, please let me know!
• Supports everything PayPal has to offer. Specifically, I want something that can support Website Payments Pro and the Payflow Pro gateway. This way I can handle payments on my site, but still take advantage of PayPal’s expertise, PCI compliance, and competitive pricing.
• Flexible, straightforward templating. I am a front-end developer. Any cart solution that tries to stand between me and my code or that makes templating a holy hell isn’t a good solution. I want simple, straightforward flexibility. For example, I’ve been working with Magento a lot recently, and while it has a lot of great features, it’s a huge pain to deviate too far from the standard build. Every small change requires updates in multiple disparate files and hours of time for a five-minute job. My ideal solution would let me build my pages however I wanted, and just drop in the “cart” functionality wherever I cared to do so.
• Good support of downloadable products. The stores I’m building will have both hard and soft goods, so I need the cart to work equally smoothly with both.
• Built for LAMP servers. The ideal solution would run on PHP/MySQL, but I would consider other LAMP-friendly options. Sorry, but ASP/.NET solutions aren’t a possibility for me.
• A single product database. This solution will be running multiple stores, but several of the stores will share some products. In the interest of avoiding redundant data, I’d like to have a single product database that all my stores can draw from.
• Access to the source. I don’t want to have to wait for a team halfway around the world or a community of volunteer developers to get around to building the functionality I need if I think I could tackle the project myself. If I can’t have access to the source itself, an exceptional plugin system would be a good alternative.
• A flexible discounting system. I want to be able to offer (as a fake example) 20% off orders of $50 or more on certain products. I want to discount items if people buy two or more of the same product. I want sales that run for three weeks, and expire automatically. Or at least some of those things.

That’s the basics of what I need, folks. That isn’t too much to ask, is it?

To summarize, I’m looking for a simple, straightforward shopping cart that makes templating a breeze, runs on PHP/MySQL, supports PayPal gateways, allows virtual goods and discounts, and is something I can install locally and modify. I do not need a solution that tries to be everything at once — it doesn’t have to contain a CMS, a catalog, or an inventory system. It doesn’t have to provide a newsletter, it needn’t compare items, and it shouldn’t try to walk my dog on Thursdays. I don’t want a jack-of-all-trades: I want a master of one (or two).

I also want to clarify: this does not have to be a free solution. If you know of a commercial option that does all this, I would be very excited to hear about it.

So! Let me know what you know in the comments below. Even if you know of a cart that fulfills some of these needs, I would be excited to hear about it — there’s always the chance I can customize it to do what I need from there.

There are lots of reasons you might want to offer your users more than one CSS file for your website:

• You want to offer a “stylish” low-contrast and an easy-to-read high-contrast version of your site.
• You have many low-vision readers and want to give them easy access to a customized stylesheet with a larger typeface.
• Your site is schizophrenic and you want to be able to change the look quickly.

Whatever the reason, it’s amazingly easy to create a function that swaps between multiple stylesheets using jQuery.

The first step of course is to build several different CSS files, which we’ll then swap between. Once that is done, we can dive into the XHTML and jQuery that makes the magic happen.

The XHTML

First, we need to create a set of links that will allow the user to swap between CSS files. You can make this as simple or as fancy as you’d like. For the sake of brevity, my links are simple:

<ul id="nav">
	<li><a href="#" rel="/path/to/style1.css">Default CSS</a></li>
	<li><a href="#" rel="/path/to/style2.css">Larger Text</a></li>
	<li><a href="#" rel="/path/to/style3.css">Something Different</a></li>
</ul>

Here I have three links, each with a “rel” attribute indicating which CSS file the link will load. Technically, I could have just as easily put this information in the “href” attribute, but I didn’t want to for one specific reason: if the user has JavaScript disabled and the CSS file is listed in the href, then clicking the link will send the user to the CSS file directly (not loading it like we intended). But our way, if JS is disabled, the user gets nothing at all: which is certainly preferable to the less savory alternative.

The jQuery

Like I promised, the jQuery is really simple:

$(document).ready(function() {
	$("#nav li a").click(function() {
		$("link").attr("href",$(this).attr('rel'));
		return false;
	});
});

This function waits until the document is loaded (generally an important step when interacting with the DOM), then attaches a click function to each of our nav anchors. The function basically says, “when someone clicks on this link, replace the link (stylesheet) tag’s href attribute with the contents of this link’s rel attribute.” The “return false” at the end just stops the browser from trying to follow the link.

Of course, you might have to get more detailed if you have more than one link tag, for example, but that’s easily done by giving the link tag a class (”changeme,” for argument’s sake), and writing something like this:

$("link.changeme").attr("href",$(this).attr('rel'));

And while this stylesheet switcher is already complete, we might want to give it some memory: after all, your users might get annoyed if they have to switch their styles back to their preferences every time they visit your site. For that, we’ll need to set a cookie. And to make that easier, I’ll use the jQuery cookie plugin (which I’ve talked about previously when building a popout ad).

With the plugin loaded, we can modify our jQuery thusly:

$(document).ready(function() {
	if($.cookie("css")) {
		$("link").attr("href",$.cookie("css"));
	}
	$("#nav li a").click(function() {
		$("link").attr("href",$(this).attr('rel'));
		$.cookie("css",$(this).attr('rel'), {expires: 365, path: '/'});
		return false;
	});
});

Now we have two statements. The first one checks as soon as the page is done loading to see if a cookie called “css” has been set. If so, it sets the stylesheet to be the one indicated in that cookie. Otherwise, it does nothing.

Our click function is much the same, except after we set the stylesheet, we also set a cookie. This cookie doesn’t expire for an entire year (and each time the user changes their stylesheet preferences, it would reset this timer), giving them a good 365 of CSS bliss.

Fine Tuning

There is one minor annoyance with this stylesheet switcher: there’s generally a flash of the “default” CSS when the user loads the page. That’s because the script waits until the document is “ready” before switching the link’s href. There is a way around this: moving the first “if” statement outside of the document ready function, like so:

if($.cookie("css")) {
	$("link").attr("href",$.cookie("css"));
}
$(document).ready(function() {
	$("#nav li a").click(function() {
		$("link").attr("href",$(this).attr('rel'));
		$.cookie("css",$(this).attr('rel'), {expires: 365, path: '/'});
		return false;
	});
});

Generally speaking, you don’t want to run any jQuery until your document is ready. However, so long as your jQuery comes after your link tag in your document structure, like shown below, this shouldn’t be a major concern:

<link rel="stylesheet" type="text/css" href="style1.css" />
<script type="text/javascript" language="javascript" src="jquery.js"></script>
<script type="text/javascript" language="javascript" src="jquery.cookie.js"></script>
<script>... your jQuery goes here...</script>

This means your jQuery will run before the document is done loading, and thus your link tag’s href will be swapped before your CSS has been applied. As I said before, it’s generally a bad idea to manipulate the DOM before document ready, but because we know the exact tag we want to manipulate and can place our jQuery below it in the DOM, we should be safe in this one specific instance.

Here’s an example if you would like to see this technique in action.

The life of a CSS developer isn’t all about attending glamorous champagne parties, jet-setting around the world and hanging out with supermodels. In fact, when your CSS doesn’t behave the way it should, the job can be downright tedious. I’ve spent untold hours of my life debugging my code — and I’m guessing I’m not alone here.

But as silly as it may seem, some of the biggest CSS blunders stem from the simplest of errors. Knowing what some of those errors are and remembering to look for them can save you hours of wasted labor. Here are fifteen ways I’ve found to break my CSS for sure — and fifteen things I always look for whenever I have a problem in my code.

Missing a Semicolon

CSS rules are comprised of property-value pairs (declarations) followed by a semicolon. Accordng to the CSS specification, the last declaration doesn’t need a semicolon — because the closing brace effectively ends the declaration just as well. That means something like this is perfectly acceptable:

body {
	background-color: #444;
	color: #eee }

The only problem is, as soon as you decide to add another declaration to your previous rule, you’ve now made it all too easy to forget to add the semicolon to your once-last rule:

body {
	background-color: #444;
	color: #eee
font-family: Helvetica, Arial, sans-serif }

The result? Your font-family rule never gets applied, because the parser reads “font-family” as part of the color value. Which is why I make a habit of adding the final semicolon in a rule, no matter what.

Missing a Colon

I’ve seen this particular problem crop up frequently while teaching classes on CSS. People get excited when CSS starts to make sense, and their typing speed increases. The downside: this makes errors of omission much more likely. And a missing colon is particularly tough to see, since it sits right in the middle of a declaration. Consider the following two lines:

body { font-family Helvetica, Arial, sans-serif; }
body { font-family: Helvetica, Arial, sans-serif; }

It’s easy to see how the colon could get overlooked in the jumble of braces, hyphens, semicolons and cryptic words. As a rule of thumb, if you only have one declaration not behaving itself, this is a good place to start looking.

Missing a Brace

{Braces} around a CSS rule are like the circle of life: regular, natural, and expected. And if you ever miss a brace (generally a closing brace for whatever reason) — just like if you have a zombified corpse that refuses to die — you suddenly have all sorts of mayhem on your hands.

When an unsuspecting browser comes across a pair of rules like this:

body {
	font-family: Helvetica, Arial, sans-serif;
#wrap {
	width: 960px; }

The browser is going to choke. Two opening braces before a closing brace is right out: everything from your #wrap rule (in this example) on would be ignored.

However, this does make debugging easier. Do you have a whole chunk of CSS being ignored? Which is the first rule that is being neglected? There’s a good chance you have an uneven number of braces hanging out in the vicinity.

Misspelled Properties

I consider the following few errors the bane of dyslexic developers everywhere. Generally speaking, I’m a good speller. But when I’m “in the zone” and typing as fast as my fingers can carry me, I tend to transpose a few letters here and there. In writing, this isn’t such a big deal: people can generally figure out what I mean. Computers, sadly, are less discerning.

div { border-bototm: 5px; }

Now, I have no idea what a “bototm” is, but I do know I write the word at least one time in five when I’m trying to refer to the lower edge of an element. I’m lucky in that I have a decent eye for editing and often catch these mistakes as I make them. If you’re not so fortunate, using a program with code coloring like Notepad++ or Adobe Dreamweaver (my personal favorite) can make the job a lot easier: if a property isn’t colored like the other properties, than it’s probably not much of a property at all.

Misspelled Values

Misspellings aren’t limited to just properties. And sometimes a misspelled value can be even more difficult to notice:

#wrap { padding: 10px 20pz 25px 20px; }

Unfortunately for the rule above, I’m fairly sure only Snoop Dogg and I have ever tried to measure elements in pizzles. Instead of the generous padding you’d expect this rule to generate, this one misspelled unit renders the entire declaration invalid.

Misspelled Classes and IDs

No matter how often I create a div with an ID of “navigation,” I still find myself writing rules that look more like this:

#navigaiton { float: left; } 

This can be a frustrating error to track down, because color-coded editors won’t help you out here: you could just as easily purposefully name an element “navigaiton” if you really wanted. But I’d recommend against it.

Improperly Ordered Values

Some CSS properties have a built-in shorthand, which is a great way to save yourself a few lines of code. Unfortunately, most of the shorthand properties are very picky about the order of the property’s values. For example:

div { font: 2em Helvetica, Arial, sans-serif; }
a { font: "Times New Roman", serif 1.5em; }

The first rule will result in all divs gaining a specific typeface and size. The second rule will result in a debugging session — while it’s okay to leave some values out of the font declaration, changing up the order of the values will result in problems.

Measurement Values Without Units

CSS Newbie reader Justin reminded me of this problem the last time I wrote about CSS faux pas. With only a few limited exceptions, all measurement values in CSS need a unit of measurement associated with it. Take the following rule for example:

#wrap { margin: 3; }

Three what? Ems? Inches? Pizzles? The flexibility of CSS that allows us to pick from several units of measurement also means specifying a unit is fairly important.

Bonus — Two unit-agnostic measurements:

1. Values of zero don’t need a unit of measurement. Turns out, zero pixels and zero miles are exactly the same length.
2. Line heights needn’t have a specific unit. A line height of “1.5″, for example, will simply assume you meant “1.5 times my font size.” For more on this phenomenon, visit Eric Meyer’s article on Unitless Line Heights.

Competing Identical Rules

Once a stylesheet gets to be a certain length, it can be difficult to remember which rules you’ve already written unless your CSS is very well organized. And two identical rules at different spots in your CSS file can wreak havoc on your design and sanity alike.

ul li { margin: 0 2em; }
... 300 lines later ...
ul li { margin: 0; padding: 10px; }

In this scenario, the latter rule would win out over the former, thus removing the margin and applying padding instead. But if you’ve forgotten about this duplicity, you might go back into your CSS later and try editing the first rule only, and remain perplexed as to why, no matter how you tweak your margin, you can’t seem to make any difference.

Unintentionally Competing Rules

A similar problem could force your CSS to compete with itself in ways you didn’t expect. For example, if you had the following code in your XHTML:

<div id="navigation" class="nav">...</div>

You could refer to this element by either its class or its ID. The problem arises when you do both, and forget that you’ve done so:

.nav { width: 50%; }
... later in the code ...
#navigation { width: 500px; }

This code would result in a fixed-width navigation bar, even though the first rule would suggest a more flexible width. Again, having a well organized stylesheet is the easiest way to avoid this problem.

Calling a Class an ID (or vice-versa)

I fall into this particular trap all the time. I’ll write a rule like this:

.navigation {
	float: left;
	width: 100%;
	height: 4em; }

And nothing will happen! It often takes me a minute or two to realize that the real problem is that I’d given my navigation bar an ID, not a class. My best advice here is to pick a naming system that works well for you and be consistent. If you always call your top navigation bar “#topnav”, for example, you’re far less likely to misremember your element names.

Using a Nonexistent Property

Not all CSS properties are named the most intuitively. For example, this might look like a perfectly acceptable rule to someone new to CSS:

body { text-size: 3em; }

The problem is, while there are certainly several text-riffic properties, text-size isn’t one of them. Instead, we use font-size. Which means that the rule above wouldn’t do much of anything. Intelligent code-coloring editors like Dreamweaver usually make this sort of debugging much easier: if it’s not a real CSS property, it won’t be the same color as the surrounding properties. That’s usually my first clue I’ve done something wrong.

Using a Nonexistent Value

This is a sister stumbling block to the one above. Some values just seem to make sense, but will fail you nonetheless:

td { vertical-align: center; }

You would assume that this rule would vertically center your table text, right? Unfortunately, while “center” is indeed an acceptable value for text-align, vertical-align uses the perhaps less intuitive “middle” instead. And you’d have to ask a better educated rhetorician than me to figure out the difference between middle and center in this context, because I’m at a loss.

Improperly Matching Properties and Values

Certain CSS declarations can look correct even to the trained eye, unless that eye is paying particularly close attention. For example:

a { text-transform: italic; }

While this might look like a perfectly reasonable rule, you won’t end up with italicized text. That’s because “italic” belongs to the font-style property, not the text-transform property. But even most advanced editors won’t catch that bug, as you’ve used a perfectly reasonable property and value — you’ve just used them in an inappropriate combination.

Not Closing Comments

The gentle persons at BlogThemeMachine tipped me off to this common CSS problem. Can you spot the major difference between these two sets of rules?

/* Navigation goes here. */
#nav {
	float: left;
	width: 100%;
	height: 3em; }

/* Navigation goes here. /*
#nav {
	float: left;
	width: 100%;
	height: 3em; }

The only difference is that the second rule has an improperly closed comment tag: /* versus */. That seemingly insignificant difference can result in entire swaths of your CSS suddenly not working. In fact, this tiny blunder will negate all your CSS from the start of your comment until you successfully close a second comment. Which if you’re using comments to organize your CSS means an entire section of your site will lose its styling.

These fifteen tiny blunders are sure to give you hours upon hours of CSS frustration… unless you know to watch for them. What are some other self-introduced bugs you often find in your code? I’d love to hear about them in the comments!

This is a chance for me to get to know you, my audience, a little bit better. It will also help me do my darnedest to produce the sort of content that you would find most useful. So! Are you a true CSS newbie, already a big deal in the CSS world, or somewhere in between? Let me know in the poll below!

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Also, here are the results from the last poll, which asked, “what do you want to see on CSS Newbie in 2009?”:

• 59% of the voters wanted more long, tutorial-style articles.
• 43.4% wanted more short, quick tip articles.
• 33.7% requested more entry-level, CSS-specific articles.
• 31.3% wanted more advanced and non-CSS articles.
• 24.1% wanted to see video tutorials and tips.
• 19.3% were looking for a forum to help find solutions.
• 12% wanted an email newsletter to stay in touch.

(note: these add up to more than 100% because people could choose more than one option)

So obviously, the overwhelming answer is: more articles! Long, short, entry-level, and advanced… it seems there’s an audience for all four. And since I try to offer a combination of all four currently, that is a very encouraging result to see. And the other three — video tutorials, forums, and an email newsletter — were all desired by more than 10% of the respondents. Obviously I have a lot of planning to do!

So thanks everyone for participating in the last poll, and please take a second to give me your responses on this one!

Generally speaking, I consider full-fledged CSS frameworks to be overkill on all but the most absolutely complex projects or, on the other end of the spectrum, rapid proof-of-concept prototyping. Most people only use a few of the classes that any one CSS framework provides, but then still require their users to download the entire, and largely unused, stylesheet.

However, I still think that the foundation on which CSS frameworks are built — the concept of using classes to simplify layout and standardize design across similar elements — is very much worth investigation. But instead of relying on a one-size-fits-all (snuggie-esque?) solution, I’d encourage you to take a few minutes and build a custom, simplified framework that does exactly what you need it to do.

The Back Story

I recently built a website based on a fairly regular, consistent grid. The content area was 780px wide and would contain six “columns” of content with 12-pixel gutters between each of the columns, though various elements could span one or more of those columns.

Because of the general flexibility of the content combined with the rigidity of the columnar structure, my mind immediately jumped to frameworks as a way to get this design pushed out in a hurry. But in the end, I just couldn’t justify all that overhead, even to create a flexible six-column design. So instead, I decided to write my own mini-framework to do only what I needed.

The Custom Framework

Here’s the basic CSS I ended up writing:

.col {
	float: left; }
.gutter {
	margin-right: 12px; }
.span1 {
	width: 120px; }
.span2 {
	width: 252px; }
.span3 {
	width: 384px; }
.span4 {
	width: 516px; }
.span5 {
	width: 648px; }
.span6 {
	width: 780px; }
.clear {
	clear: left; }

Pretty simple stuff, right? All it contains is nine classes that I can arbitrarily assign to my structural divs to determine how the page will lay out. The first class, “col”, gets assigned to any div I want to behave like a column.

Then each column is given one of the “span” classes (using the benefit of multiple CSS classes to great effect) to determine its width — or as I thought of it at the time, the number of columns the div would span… just like using “colspan” in old-school table layouts.

Next up we have the “gutter” class, which I add to any column that should have a gutter along its right edge (which would be true for all columns except those along the very right edge of my content area). And finally, there’s a “clear” class, just to ensure that my divs behave themselves even if I didn’t entirely fill up the previous “row” of divs.

The XHTML Structure

There’s not much to the XHMTL structure for my custom framework. Essentially, it’s a bunch of divs given two or more of my nine classes to determine its behavior. For example, to create the 4-2/2-1-3 structure I highlighted in the image above, this would be the structure:

<div class="col span4 gutter">Four columns</div>
<div class="col span2">Two columns here</div>
<div class="col span2 gutter">Two cols and a gutter</div>
<div class="col span1 gutter">Only 120px!</div>
<div class="col span3">Three columns.</div>

If you’d like to see this sort of custom framework in action, it’s running on the website for the Woodsmith Shop TV show.

One Size Doesn’t Fit All

Now, I’m not saying my framework is the end-all CSS framework and that you should just copy it wholesale into your own project and expect it to work perfectly. The idea here is to take this concept and come up with a custom framework that works perfectly for your needs.

The real take-away lesson here is that for most projects, you don’t need dozens of classes and hundreds of lines of CSS just to create a flexible grid structure. I created mine with just nine CSS classes and it was sufficient to power my six-column grid. I’d be interested to see what other people (namely, you) have come up with along these same lines. Share a link in the comments!

Today’s article is probably not the most practical tutorial I’ve ever written, but it was definitely one of the most fun to create. It also shows that, while CSS is often treated as a straightforward web development workhorse (and it’s a great workhorse, at that), it can also have a lighthearted, eccentric side as well. Today’s tutorial is about how to use CSS to create art.

Now, as I’ve mentioned numerous times, I am not an artist. If true CSS artists were likened to Salvador Dali or someone similar, I’d be more akin to the guy watching Bob Ross on public television and following along at home, creating wobbly little smudges and pretending they’re happy little trees. But! What my example above (and you can skip ahead and see the final version) shows is that it doesn’t take very many CSS rules to create some pretty cool CSS art.

And the best part about tackling CSS art is you’re likely to learn a lot about CSS along the way. Sure, this art form is probably only a step or two above the ASCII art generated in the nineties – but playing around with ASCII art taught me a decent bit about letter forms, line lengths and the rest. Likewise, practicing CSS art will teach you an awful lot about sizing, positioning and the use of color to create an effect.

To warn: my example flower makes extensive use of the border-radius property (which I’ve covered more in-depth here), which doesn’t work in Internet Explorer. The net result is that the IE version of my flower looks a bit Atari-esque… but the rest of the code still works fine.

So let’s get to the code!

The XHTML

I’ve attempted to keep my code as simple as possible, while still keeping each of my flower’s segments separated for easy adjustment. Here’s what my code looks like:

<div id="background">
	<div id="flower">
		<div id="topleft" class="petal"></div>
		<div id="topright" class="petal"></div>
		<div id="center"></div>
		<div id="bottomleft" class="petal"></div>
		<div id="bottomright" class="petal"></div>
		<div id="leftleaf" class="leaf"></div>
		<div id="stem"></div>
		<div id="rightleaf" class="leaf"></div>
	</div>
</div>

The “background” div creates the blue sky and green grass, while the “flower” div contains the rest of my work. Each petal and leaf gets its own ID, while each group shares a class to reduce the number of rules I have to write. The stem and center circle are unique, and thus don’t have a class assigned.

I’ve written my code in the same order that it is to appear on the screen (assuming I move top to bottom, left to right). However, if you were willing to make more extensive use of positioning than I have, you could conceivably place the individual divs in any order you so chose.

The CSS

And now for the fun part! I’ll break my CSS into several parts so you can see how it all comes together. First, we’ll set up the background and the main flower div:

#background {
	position: relative;
	background-color: #9cf;
	width: 600px;
	height: 476px;
	border-bottom: 10px solid #090;
	margin: 0 auto; }
#flower {
	position: absolute;
	top: 20px;
	left: 172px;
	width: 256px; }

The background has been relatively positioned so that I can absolutely position my flower inside it, using the relative-absolute positioning trick. I’ve also given it a width and height, to provide my image’s frame. Then I’ve used a background color to simulate the blue sky and a border to provide the ground. My flower is absolutely positioned (which also means it becomes the containing div for any positioned divs nested inside), and is placed on top of the background.

Then we have the flower petals:

.petal {
	background-color: #f33;
	float: left;
	margin: 1px 1px 0 0;
	width: 125px;
	height: 125px;
	-moz-border-radius: 20px;
	-webkit-border-radius: 20px; }
#topleft {
	-moz-border-radius-bottomright: 0;
	-webkit-border-bottom-right-radius: 0;
	border-bottom: 2px solid #c33;
	border-right: 2px solid #c33; }
#topright {
	-moz-border-radius-bottomleft: 0;
	-webkit-border-bottom-left-radius: 0;
	border-bottom: 2px solid #c33;
	border-left: 2px solid #c33;  }
#bottomleft {
	-moz-border-radius-topright: 0;
	-webkit-border-top-right-radius: 0;
	border-top: 2px solid #c33;
	border-right: 2px solid #c33; }
#bottomright {
	-moz-border-radius-topleft: 0;
	-webkit-border-top-left-radius: 0;
	border-top: 2px solid #c33;
	border-left: 2px solid #c33; }

This is the largest chunk of CSS (because each petal is slightly different), but it’s fairly repetitive in nature (because each petal is fundamentally the same). The “petal” class sets our basic rules: our petals are dark red, floated left, have a tiny bit of space on their top and left sides, are 125 pixels wide and tall, and have rounded corners.

The following four sets of rules simply specialize each of the petals to make them unique. I’m doing two things. First, I’m removing the curved border on the innermost corner; technically the center circle covers almost the entire inner corner, but it looks cleaner without the curve, and it also allows me to resize the center area without worrying about whether the curved border will show through. Then I’m adding a 2-pixel wide darker red border to the inner two sides of the flower petals, which adds a sense of depth and a bit of visual interest.

Next we have the center circle and the stem:

#center {
		position: absolute;
		left: 112px;
		top: 112px;
		background-color: #ff3;
		width: 30px;
		height: 30px;
		-moz-border-radius: 15px;
		-webkit-border-radius: 15px; }
	#stem {
		float: left;
		width: 12px;
		height: 200px;
		margin: 0 1px;
		background-color: #093; }

Although the center area looks like a circle, like all XHTML elements, it is technically a rectangle. This particular rectangle is a square, 30 pixels wide and tall. And then all I’ve done is given each side a 15 pixel border radius, resulting in a perfect circle. Once the circle was made, I used absolute positioning to center the circle over the intersection of the four flower petals.

The stem was the most straightforward of my elements. It’s a true unrounded rectangle, given a green background color, a width, height, and margin, then floated left so I could place my leaves directly against it without having to resort to absolute positioning.

And speaking of the leaves, here’s how they were created:

.leaf {
	float: left;
	margin-top: 80px;
	background-color: #093;
	width: 60px;
	height: 30px; }
#leftleaf {
	clear: left;
	margin-left: 10px;
	-moz-border-radius-bottomleft: 30px;
	-webkit-border-bottom-left-radius: 30px;
	-moz-border-radius-topright: 30px;
	-webkit-border-top-right-radius: 30px; }
#rightleaf {
	-moz-border-radius-bottomright: 30px;
	-webkit-border-bottom-right-radius: 30px;
	-moz-border-radius-topleft: 30px;
	-webkit-border-top-left-radius: 30px; }

I was particularly proud of how the leaves turned out, even though they’re fairly simple in design. The leaf class sets some defaults: they’re floated left, given a top margin to push them down the stem, the background color matches the stem color, and the width and height give them a long, slender (if blocky) appearance.

The individual leaf IDs are what make them look so nice. Each leaf has two rounded corners on opposite sides. The rounded corners continue for exactly half the width of the box. The result is a very visually appealing curve. The left leaf also received two additional treatments: it gets a clear to ensure it doesn’t show up to the right of the petals, and has a left margin to push the stem exactly where I wanted it.

And that’s all there is to this flower! Even though it may seem complex, I’ve really only used a dozen or so CSS properties in a variety of different ways. As I said, this is a great exercise to tackle in order to gain a greater understanding of how positioning elements works (and it’s a lot of fun for the border-radius property as well).

Additional Challenges

So that’s what I was able to accomplish in less than 100 lines of code. So what can you do? I encourage you to show me up and share links to your masterpieces in the comments below. Here are some suggestions for challenges:

• Recreate my flower using proportional units instead of pixels. That would allow you to resize the flower and still keep it looking pretty!
• With a bit of absolute positioning and more rounded corners, try adding clouds to the otherwise bland background.
• My flower’s leaves remind me of cat eyes. Try creating a cat or similar beast using pure CSS.

And no matter what: have fun!

Every once in a while, a deal comes around that is sort of a no-brainer. This is one of those deals, so I suggest you read, act, and enjoy (in that order)!

SitePoint is a well-respected online media company that, among other things, publishes some very well written books. I received a copy of Jason Beaird’s The Principles of Beautiful Web Design for Christmas, and I couldn’t put it down until I finished it – despite the fact that I also had a shiny new copy of Mario Kart Wii vying for my attention. That’s a good web book, people.

SitePoint’s home offices are based in Melbourne, Australia – which is in the Victoria state in the southeast corner of the continent, for those of you who (like me) aren’t the best at geography. As you’ve probably seen in the news, Victoria is currently battling the worst bushfires in Australian history.

So where does the whole books/cause thing figure in?

In order to raise money for the Australian Red Cross, SitePoint is having a 5-for-1 sale on PDF versions of their books. You can purchase and download high-quality PDF versions of five of their books for just $29.95 (normally $149.75 total!). And best of all, 100% of your purchase will go to the Australian Red Cross and will help victims of the bushfires.

This offer ends on this Friday (February 13th), so be sure to act fast. I’ll be getting my five books momentarily – as soon as I can narrow down my list to my top five picks! Which five books are you picking up? Let me know in the comments.

I ran into (yet another) Feed Count + Feedburner problem recently, shortly after writing my last article on accounting for Feedburner’s subscriber count mistakes. And since I heard from a few people who are also using the Feed Count plugin, I thought I should share this info.

The Backstory

As I’m sure all you Feedburner users out there are well aware, Google purchased Feedburner quite some time ago. But until recently, that didn’t mean much: the same people were working on the code, your information was stored in the same place and was represented the same way, and so on.

But recently Google has begun bringing Feedburner more fully into the fold. As a result, all Feedburner users are being required to convert their Feedburner accounts into Google accounts. That created quite a few headaches for lots of people (including myself) right off the bat, as it took a good week for Google to nail down my subscriber numbers with any accuracy – one day I would have thousands of subscribers, the next I might have zero, and the day following only a few hundred.

A New Problem

However, even once Google started reporting my Feedburner numbers correctly, I still had a problem: my Feed Count plugin no longer grabbed my subscription statistics. Now, this wasn’t as huge a problem as it could have been, because I had my jQuery Feeburner fix in place… but I still wanted my real subscriber stats back at some point.

After a bit of digging, I found the problem: as part of their conversion from Feedburner to “Google” Feedburner, Google changed the location of their API. Thus, any plugins that used the old Feedburner API ceased functioning once that user’s account was successfully ported to Google.

The Solution

Long-term, the best solution would be for the plugin developers to update and release new versions of their plugins. But as of now, the Feed Count plugin has not been updated – and since it hasn’t seen an update since last July, I’m not going to hold my breath on a new version. So I decided to take matters into my own hands and edit my copy of the Feed Count plugin.

Note: this solution is specific to the Feed Count plugin, but any brave souls out there could probably modify and use this information to update other plugins as well.

I opened up my copy of the Feed Count plugin file (feedcount.php) and found this function:

function mapelli_fc_get_defaults() {
	return array(
			'map_fc_feedurl' => '',
		  'map_fc_queryurl' =>'http://api.feedburner.com/awareness/1.0/GetFeedData?uri=',
			'map_fc_lastcount' => 'N/A',
			'map_fc_lastupdate' => 0,
			'map_fc_updateinterval' => 60, // 1 h
	    'map_fc_error_updateinterval' => 5, // 5 min
		  );
}

This function mostly sets all the plugin defaults, but it also sets the “queryurl” – the website that the plugin hits to find your subscriber count information. This URL is not customizable anywhere inside Wordpress, and since this URL has now changed, we’re forced to edit the plugin itself.

All I had to do was change the “map_fc_queryurl” line to read this instead:

'map_fc_queryurl' =>'https://feedburner.google.com/api/awareness/1.0/GetFeedData?uri=',

Then I saved the plugin, uploaded it to my server, and my stats started showing up again! However, it’d still recommend putting something like this JavaScript fix in place for those random times when Feedburner drops the ball (and your subscriber count).

Note: Your stats probably won’t start showing up again instantly. You’ll have to wait for the duration of your “update interval,” which can be configured in WordPress under Settings -> Feed Count:

If you’re using a different plugin and have run into this same problem, please give this solution a try and let people know in the comments if it worked. Thanks!

Last week’s article covered how to build a tabbed box interface, starting with Photoshop, and moving through XHTML and CSS to our basic jQuery functionality. If you missed it, I would highly recommend starting your reading there. This article will show you how to use jQuery to make your tabbed interface more attractive and interactive. Specifically, I’ll show you how to:

• Make your tabs all the same height
• Automatically rotate through your tabbed content
• Stop the rotation when the user is interacting with the content

Equal Height Tabs

The tabbed interface we built last week was fully functional, but one nicety I’d like to add is the option to have all your tabs be the same height – a height that is determined by the content within the tabs, not any number I arbitrarily determine in advance.

While there are several ways to calculate and apply height in jQuery, the fastest and easiest means to our end would be to use the equalHeights jQuery plugin I developed and wrote about recently. By using that plugin, we’d only have to make a single addition to the “document ready” portion of our jQuery:

$(".tabbed-content").equalHeights();

This will cycle through all of our tabbed content divs and equalize their heights based on the height of the tallest div. The benefit of this is the content around our tabbed box won’t shift up or down each time the user switches tabs, resulting in a more pleasant visual experience.

Rotate Through Tabbed Content

While tabbed boxes like the one we’ve built are a great way to fit a large amount of content in a small space, they do have one drawback: many users never click through the tabs to see what all is offered, meaning they only ever see the content on the first tab. My proposed solution to this problem is to automatically rotate through the tabs.

This solution has two benefits: first, the movement is more likely to catch the users’ eyes, increasing the chances they’ll notice the tabbed box in the first place. Second, it allows your users to see all the content your box contains instead of just the first tab.

Making this adjustment to our jQuery requires edits in several areas, so I’ll show you the new code in its entirety before explaining what it all does:

var currentTab = 0;
var rotateSpeed = 5000;
var numTabs;.
var autoRotate;

function openTab(clickedTab) {
	var thisTab = $(".tabbed-box .tabs a").index(clickedTab);
	$(".tabbed-box .tabs li a").removeClass("active");
	$(".tabbed-box .tabs li a:eq("+thisTab+")").addClass("active");
	$(".tabbed-box .tabbed-content").hide();
	$(".tabbed-box .tabbed-content:eq("+thisTab+")").show();
	currentTab = thisTab;
}

function rotateTabs() {
	var nextTab = (currentTab == (numTabs - 1)) ? 0 : currentTab + 1;
	openTab($(".tabbed-box .tabs li a:eq("+nextTab+")"));
}

$(document).ready(function() {
	$(".tabbed-content").equalHeights();
	numTabs = $(".tabbed-box .tabs li a").length;

	$(".tabbed-box .tabs li a").click(function() {
		openTab($(this)); return false;
	});

	autoRotate = setInterval("rotateTabs()", rotateSpeed);
	$(".tabbed-box .tabs li a:eq("+currentTab+")").click()
});

The first variable, currentTab, is unchanged from our first iteration. But then we’ve added three new variables:

• rotateSpeed is the number of milliseconds to wait before switching tabs.
• numTabs is a variable that will contain the total number of tabs in our box. We’re initializing it at the beginning so we can use it in all our functions.
• autoRotate is a variable we’ll use later.

Our openTab function hasn’t changed. If you’d like to understand how it works, please refer to the first article.

Next we’ve written a new function called rotateTabs. This function will handle the math required to determine which tab should be opened next. First we set a new variable, nextTab. What we set nextTab to depends on which tab we’re on currently. The function looks at currentTab: if currentTab is our last tab in the list, it starts back over at the beginning (the tab with an index of 0). Otherwise, nextTab is simply the next tab in the list. Once we’ve determined our next tab, we call the openTab function, which prevents us from having to duplicate all that heavy lifting.

We’ve added two lines to our document ready function. The first sets the numTabs variable to be the number of tabs in our box. We don’t populate this variable until the document is ready, because otherwise it will try to count the tabs before our tabs have loaded and will return a length of -1 (aka, none found).

The second bit we added is towards the end, where we set autoRotate. In autoRotate we’re calling the JavasScript setInterval function, which executes a piece of JavaScript on a regular interval. As we’ve written it, we will be calling our autoRotate function every “rotateSpeed” milliseconds. This means that when our document loads, it will wait that many milliseconds, then switch to the next tab, then pause again, then switch again infinitely.

Pretty neat, huh? You can see this functionality in action here.

Stopping the Rotation

Now, automatically rotating your tabs is a pretty awesome effect, but at some point you’re probably going to want that rotation to stop. Specifically, you don’t want your tabs switching when your users are interacting with them.

I tested several scenarios on when and how to stop the tabs from rotating before deciding on how I’m doing it here. It only requires editing a couple of lines from our document ready function:

$(document).ready(function() {
	$(".tabbed-content").equalHeights();
	numTabs = $(".tabbed-box .tabs li a").length;
	$(".tabbed-box .tabs li a").click(function() {
		openTab($(this)); return false;
	});
	$(".tabbed-box").mouseover(function(){clearInterval(autoRotate)})
	.mouseout(function(){autoRotate = setInterval("rotateTabs()", rotateSpeed)});

	$(".tabbed-box .tabs li a:eq("+currentTab+")").click()
	$(".tabbed-box").mouseout();

});

Here we’ve replaced our setInterval function with something a little more complex. We’re now using both setInterval and clearInterval (which stops setInterval), and we’re applying them when the user’s mouse interacts with our tabbed box.

Specifically, we’re letting the box auto-rotate whenever the mouse is nowhere near the box, and stopping the box from rotating whenever the mouse is over the box. This means that as long as the user has the mouse over the box, as if they were reading, or clicking through the tabs, or clicking on something inside one of our tabs, the tabs wouldn’t switch on them. But as soon as they’re done interacting with the box, it’ll switch back to its regular rotation.

This does require one extra line at the end of the script, to force a “mouseout” event on the tabbed box, which gets things rotating by default.

You can see our fully functional tabbed interface here. Give it a try: watch it rotate through, and then try interacting with the box a bit. You’ll see that the tabs don’t automatically move, as long as you’re actively engaged with the box.

And that’s that! I hope you’ve found this mini-series helpful, and I’d love to see how you’ve implemented this idea on your own websites. Drop me a line in the comments below if you do.