CSSnewbie

7 Tips for Replacing the Font Tag

So let’s say – hypothetically – that you’ve decided to take the plunge and replace all of the font tags in your website with semantic code and CSS. Hypothetical congratulations! You’re one step closer to web nirvana. Or perhaps you’ve just inherited a website filled to the brim with hundreds of nested font tags forming some sort of primordial typographical soup. You have my (very real) condolences. Luckily, replacing font tags with semantic code and CSS isn’t as terribly difficult as it might seem at the outset. And to help you along your way, here are a few tips on how to tackle the project.

Font Usage Assessment

Start out with a complete assessment of your current font usage. How many typefaces are you using currently? How many sizes? Do you use some of them more than others (hopefully so!). In what context are the fonts used? Write out this information and see if you can’t discover some sort of a rational pattern in the usage. If you’re lucky, a good, distinct pattern will appear – article headings always appear in 20-pixel Arial, for example.

Replace Font Tags with Semantic Tags

If you’re lucky, and the font tags follow some sort of a rational pattern, you’re in a good spot. The easiest way to start down the road to font tag recovery is to replace as many font tags as you can with semantic, meaningful tags. For example, if all of the article headings look the same, why not replace those font tags with an actual heading tag (<h1> - <h6>)? And if all of your paragraphs contain identical font tags, then you can just eliminate those tags straight away. Then you can style these elements later on down the road with CSS.

Avoid Classitis

The last thing you want to do when eliminating all of those font tags is just to replace them with a slew of unique classes and IDs. Classitis (as this practice is commonly called) is nearly as bad a disease on the web as is font tag usage. Only use classes and IDs when absolutely necessary; if all of your <h3> tags have a class of “articleHeading,” what’s to stop you from just applying those styles to your <h3> instead? For more information on Classitis and how to prevent it, see this article on Combating Classitis.

Let Your Fonts Cascade

When it comes time to start writing your CSS, remember to let your font choices cascade. If you discover that you have one size and typeface used in 90% of your website (14px Arial, for example), there’s no reason to set this font information on every possible tag in your CSS. Just set your “default” (i.e., most common) typeface on your body tag instead. This will save you a ton of time and effort down the road.

Perform Unique-Case Triage

If you come across a single-use font tag in your website – a font style that is used in one and only one place in your website – this would be a good time to stop and consider whether to eliminate that unique case. Is that different typeface necessary? Was it even and intentional choice? With so many font tags scattered about, some differences in typography may be entirely accidental. If you decide that this specific instance is both deliberate and necessary (e.g., your error messages look different than the rest of the text), set an ID on the tag and style the element that way.

Use CSS Shorthand

You’ve probably found that, while you’ve managed to eliminate hundreds of font tags from your website, you’ve added dozens of lines of CSS to your site – and that can seem like an uneasy trade if you’re more comfortable with font tags than CSS. To help cut down on the length of your CSS file, it can help to use the font property shorthand (described here). By using the shorthand, you can turn six or so lines of CSS into a single, easily digestible rule.

Make an Editor Do the Work

HTML editors can sometimes cause just as many problems as they solve – they can be a great source for font tags, for example. But many editors (Dreamweaver, Notepad++< and many others) also have pretty powerful search-and-replace functionality. And this will come in handy when you finally get to the toughest part of transitioning away from font tag usage – deleting all of those font tags you don’t want anymore. At that point, and editor capable of doing a search/replace – and perhaps even better, one that understands regular expressions – can be worth its weight in gold. Otherwise, you could just always consider the time it takes you to go through all that code as some sort of penance. :)

These are seven suggestions to help make it easier to transition from font tags to semantic code and CSS. If you have any other suggestions you’d like to add, offer them up in the comments!

Why Doesn’t My CSS Work? Five Quick Fixes.

Imagine: You’ve been working on your brand new, beautifully cascading style sheet for most of the day. You save your work, load it into a browser, and… what the heck?! Nothing’s working right! You know you didn’t make any huge errors in your code, but something is obviously wrong.

We’ve all been there before. But instead of wasting endless hours debugging your code, here are a few very simple things you can check in your CSS before you start pulling out your hair.

Closing brackets are notoriously easy to miss, especially if you don’t put them on a line all by themselves (and I usually don’t). Missing a single closing bracket can throw off your entire website, because the browser quits loading your rules as soon as it encounters the malformed code.

.sidebar {
	width: 200px;
	background-color: #333;
.sidebar h3 {
	/* None of these rules are applied! */
	font-size: 1.4em;
	color: #fff; }

A missing semicolon can likewise cause your code to start behaving wonky. CSS specifications state that you don’t need a semicolon on your very last rule before your closing bracket, but in my experience that’s a great way to set yourself up for some heartbreak. As soon as you decide to add one more rule to that property, that missing semicolon is going to rear its ugly head.

.sidebar {
	width: 200px;
	background-color: #333
	/* The following rule won't render! */
	padding: 5px;
}

Is there any chance you have a misspelled class or ID? It may sound obvious, but I’ve spent far too much of my life trying to debug my CSS just because I misspelled something along the line. This, if anything, is a good reason to stick to whole words (or at least common abbreviations) when writing your CSS classes and IDs – it’s going to be easier to notice a misspelling in the “leftSidebar” class than it is the “ltSdbr” class.

.siedbar {
	/* Dunno what a siedbar is, but I'm
	   pretty sure it's not in my XHTML. */
	width: 200px;
}

Misspelled properties or values have also caused me more than their fair share of trouble. There are certain words I tend to misspell when I’m typing too quickly, and it just so happens that there are a lot of CSS properties with related names. I don’t care how much I’m “in the zone,” there’s still about a 50% chance I’m going to try to apply a “bakcground-color” somewhere along the line.

.sidebar {
	/* The following property does exactly
	   bupkis. Dyslexics Untie! */
	bakcground-color: #333;
}

Bad CSS values can be a bear to hunt down, particularly if you’re convinced that the value you’re using really exists. Some invalid values are more obvious than others – a background-color of “1px” would be relatively easy to spot, but what about a vertical-align of “center,” like I mentioned last week? We tend to think of things as being either aligned to the top, center, or bottom of a space… but CSS classifies that second option as the “middle,” not the center. An alignment of center won’t create nearly the presentation you’re expecting.

.sidebar img {
	/* This image isn't really going anywhere. */
	vertical-align: center;
}

If you start your CSS debugging by looking at these five common problem areas first, there’s a good chance you’ll save yourself a whole lot of time – and a massive headache to boot. If you have any other ideas for common areas of CSS misstep, offer them up in the comments!

Combating Classitis with Cascades and Sequential Selectors

There is a disease out there in the CSS world. It can afflict anything from the meanest weblog (or the nicest ones too, I suppose) to the greatest of corporate websites. It’s called Classitis, and I’ve encountered it far too often in my professional work. Perhaps you’ve seen it too. It looks a little something like this:

body {
	font-family: Arial; }
h1 {
	font-family: "Times New Roman"; }
h2 {
	font-family: "Times New Roman"; }
p {
	font-family: Arial; }
p.ArialRed {
	font-family: Arial;
	color: red; }
p.ArialRedBig {
	font-family: Arial;
	color: red;
	font-size: 150%; }
ul {
	font-family: Arial; }
ul.ArialRed {
	font-family: Arial;
	color: red; }
strong.redArial {
	font-family: Arial;
	color: red; }

This particular snippet of (completely fictional) horribly afflicted CSS suffers from multiple problems which could all probably be considered symptomatic of Classitis, even when they don’t directly involve classes. I’ll go through the five of the most glaring problems and how to remedy them below.

The Cascading ability of CSS is ignored. Notice how many times the “font-family: Arial;” rule is applied? This is a waste of space, and ignores the fantastic cascading ability of CSS (which I’ve covered elsewhere). Once the appropriate font family had been applied to the body tag (the first rule in our example), all of the additional “Arial” family declarations, because they were identical and were inherited from this first declaration, became redundant.

Simple and identical rules are repeated. Take a look at the rules for the <h1> and <h2> tags in the example above. They use a different font-family than the body tag, so it’s appropriate that they have a rule making that change. But why repeat the rule twice? With CSS, you’re allowed to list sequential selectors, separated by a comma. Instead of the rule above, we could’ve written this:

h1, h2 {
	font-family: "Times New Roman"; }

Different classes have an identical effect. Consider the rules “ArialRed” and “RedArial” above. They do exactly the same thing, but the designer was in such a hurry, they accidentally created two rules that mirror one another. Always stop and consider when you’re writing your CSS if there’s any way to consolidate your rules. If you have to write the same rules multiple times, the answer is probably “yes.”

Classes are applied to multiple elements. There are two instances of the “ArialRed” class in the example above. One is being applied to a paragraph tag, while the other is being applied to an unordered list. There’s no need for this redundancy. By eliminating the “p” and “ul” portions of the two selectors, those classes can be consolidated into a single instance.

Class names are super long. This is the classic symptom of Classitis from whence the name derives, much like how chicken pox is named after the chicken-shaped virus that causes it (no? Well, you figure it out then). Designers sometimes get in a hurry and start building classes for every possible design difference they encounter. This can most easily be combated by remembering two things:

First, as I’ve mentioned before, elements can have multiple classes. Instead of having a class of “RedBig,” why not break it into two classes? Then you can style elements that need both classes like this:

<p class="red big">
  This text is now red and big.
</p>

Second, classes should describe what an element does, not what it looks like. A class of “red” is great when you’re first building a site, but what happens three months down the road when you decide that you want your emphasized text to be blue? A class of “.highlight” or something similar to indicate the text should stand out in some way would have been more appropriate. Of course, even seasoned developers tend to break this rule every once in a while.

So, after we apply all of the advice offered above, what are we left with? Something that looks a little like this:

body {
	font-family: Arial; }
h1, h2 {
	font-family: "Times New Roman"; }
.highlight {
	color: red; }
.shout {
	font-size: 150%; }

Ahh… nice, healthy CSS, without all of the bloating Classitis inevitably causes.

Of course, these are just a few of the pitfalls of redundancy and excess that designers can fall into when developing their CSS. If you can think of others, share them in the comments.

5 Steps to a More Organized Style Sheet

One of the nice things about languages like CSS is that you don’t have to write them in any specific way. For example, you could place all the CSS rules for your entire website on a single line of text, and assuming you had some brackets and semicolons stuck in there at appropriate intervals, your website would render without a hitch.

Of course, finding a single, specific rule in that amalgam of CSS soup would be a bit difficult, and that starts to negate the benefits of using CSS in the first place. Luckily, we have the opportunity to use the flexibility inherent in writing CSS for good instead of evil (or at least preparedness instead of poor planning). Here are a few tips that can make your CSS much easier to read – and therefore edit – in the long run.

Pick a Formatting Style

When I’m writing example CSS for someone to follow, I tend to use a more traditional formatting for my rules, like so:

body {
	font-size: small;
	color: #333;
}
p {
	margin: 1em 0;
}

However, for all its ubiquity, I don’t really care for this style. My eye tends to get distracted by the closing bracket on a line all by itself, and I consider it a bit wasteful to spend an entire line to say, “Okay, I’m done now,” when CSS lets us put that bracket wherever we darn well please. So when I write CSS for my own projects, I write it like this:

body {
	font-size: small;
	color: #333;}
p {
	margin: 1em 0;}

The only real change here is that I’ve moved the closing brackets up to the preceding line, but it helps me a lot. Now my eye knows that anything in the far left is a selector, and anything indented is a property. I’ve also saved myself two lines of code. Now, I’m not saying this style is right for everyone, but the main idea here is to find a style that works well for you and stick with it. Once your eye gets used to seeing your CSS written in a specific way, scanning your code gets a lot easier.

Section Your Code

CSS has built-in comment tags, which look like this:

/* This is a comment! */
p {
	margin: 1em 0;}

Anything that appears before the opening comment tag and the closing tag, no matter how many lines it spans, is considered a comment. These little tags are great for putting up little notes to define sections of your code. I personally use comments as heading tags to define sections of my website. For example, I might have one section titled /* Sidebar */, where I put all of my sidebar-related styles, or one called /* Article */, where all my article-specific CSS resides.

You can get as general or as granular as you want or need with this technique, depending on the size and complexity of your stylesheet. If I’m the only one who’s ever likely to edit the CSS, I tend to get away with fewer comment tags than I would if I knew that other people would be trying to decipher my code.

Use a Table of Contents

If you end up creating a massively large and complex stylesheet, containing several hundred or even a couple thousand lines of code, simply breaking that code up into a dozen or so sections might not be enough. On my biggest projects, I tend to create a Table of Contents at the top of my CSS to help me remember how my CSS is organized, and help me (or someone else) find things later on down the line. A table of contents might look something like this:

/* Table of Contents:
	1. Reset Styles
	2. Baseline (Default) Styles
	3. Column Structure
	4. Main Column (articles, etc)
	5. Comments and Pingbacks
	6. Sidebar lists and Ads
	7. Footer
*/

Then you can just insert appropriately named comment headings along the way to help you or someone else make their way through your document. Scanning code gets a lot easier when you know you’re looking for section #5 and that there will be a comment tag to let you know when you’ve arrived.

Group Selectors with Common Values

Let’s say you have five levels of heading tags in your articles, h1 – h5. They are all rendered in Verdana, but at different sizes and colors. Obviously, you’re going to need more than once rule to style all these elements, but that isn’t to say you can’t group their common attributes together. For example, instead of writing this:

h1 {
	font-family: Verdana, sans-serif;
	font-size: 200%; }
h2 {
	font-family: Verdana, sans-serif;
	font-size: 175%;
	color: #333; }
h3 {
	font-family: Verdana, sans-serif;
	font-size: 150%;
	color: #f00; }
/* And so on… */

You could make everything a lot cleaner and easier to edit in the future by writing this instead:

h1, h2, h3, h4, h5, h6 {
	font-family: Verdana, sans-serif; }
h1 {
	font-size: 200%; }
h2 {
	font-size: 175%;
	color: #333; }
h3 {
	font-size: 150%;
	color: #f00; }
/* And so on… */

Group Default Styles

Mike Rundle of BusinessLogs recently argued that using default styles (for example, styling all your anchor tags at once) is counter-productive, because when an element isn’t behaving like you’d expect it to later on down the line, you can spend a lot of time trying to “fix” your code unnecessarily because you’ve forgotten about a default style you’d set previously.

I agree to a point: I would say that you shouldn’t overly style general elements. Don’t style your anchors as bright red with a dotted border unless 99% of your links are going to appear that way. However, if none of your links in your entire site are going to have an underline, I don’t see the harm in removing the underline from your anchor tags. Because here’s the important thing to remember: all browsers have a default style sheet. Even if you don’t apply a single style to your anchor tags, they’re going to have a style (blue, underlined) to begin with. Using default styles is a means of establishing a baseline more conducive to your overall site goals.

But you can make your life a little easier by grouping all of your default styles. I tend to put them all up at the top of my document, labeled with a comment-header. That way, if (to continue the example) my anchor tags aren’t behaving like I expected a few hundred lines of CSS later, I can just check really quick to make sure my default styles aren’t interfering in some unexpected way (but since they’re only baseline styles, that’s rarely the case).

These are just five tips that have helped me keep my CSS a bit more organized. Do you have any tips that have helped you streamline your CSS?

Use Comments to Organize Your CSS Design

It’s inevitable: the longer you work with CSS, the longer your CSS files will grow. And the longer your files get, the tougher it will be to find what you’re looking for when you go back to edit your website’s styles later on down the road. This is where CSS comments can really come in handy.

The syntax is amazingly simple: You start a CSS comment with /* and end them with */ – like so:

/* This is a CSS Comment. */
body {
	font-size: 80%;
}

A single CSS comment can also span multiple lines, like this:

/* This CSS was written by Rob.
   He thinks of it as his own child, so
   you'd be best off asking permission
   to use it. ;)
*/
body {
	font-size: 80%;
}

So what are CSS comments good for? Well, in addition to identifying the creator of a CSS file (as shown above), you can also use your comments to keep your CSS more organized. For example, I use comments to organize my CSS into sections, like this:

/* Top navigational elements. */
ul#topnav {
	property: value;
}

/* Main content area. */
#content {
	property: value;
}

This makes it much easier to come back though and add or remove values from a stylesheet later on.

I also use comments to identify any “hacking” I’ve been forced to do.

.column {
	height: 1%; /* Makes IE behave itself. */
}

That way, if the hack ever becomes unnecessary or causes a different problem down the line, it’s that much easier to find it.

What else do you use CSS comments for?