1. CSS font shorthand rule

When styling fonts with CSS you may be doing this:

There’s no need though as you can use this CSS shorthand property:

font: 1em/1.5em bold italic small-caps verdana,serifMuch better! Just a couple of words of warning: This CSS shorthand version will only work if you’re specifying both the font-size and the font-family. Also, if you don’t specify the font-weight, font-style, or font-varient then these values will automatically default to a value of normal, so do bear this in mind too.

2. Two classes together

Usually attributes are assigned just one class, but this doesn’t mean that that’s all you’re allowed. In reality, you can assign as many classes as you like! For example:

<p>...</p>Using these two classes together (separated by a space, not with a comma) means that the paragraph calls up the rules assigned to both text and side. If any rules overlap between the two classes then the class which is below the other in the CSS document will take precedence.

3. CSS border default value

When writing a border rule you’ll usually specify the colour, width and style (in any order). For example, border: 3px solid #000 will give you a black solid border, 3px thick. However the only required value here is the border style.

If you were to write just border: solid then the defaults for that border will be used. But what defaults? Well, the default width for a border is medium (equivalent to about 3 to 4px) and the default colour is that of the text colour within that border. If either of these are what you want for the border then you can leave them out of the CSS rule!

4. !important ignored by IE

Normally in CSS whichever rule is specified last takes precedence. However if you use !important after a command then this CSS command will take precedence regardless of what appears after it. This is true for all browsers except IE. An example of this would be:

margin-top: 3.5em !important; margin-top: 2emSo, the top margin will be set to 3.5em for all browsers except IE, which will have a top margin of 2em. This can sometimes come in useful, especially when using relative margins (such as in this example) as these can display slightly differently between IE and other browsers.

(Many of you may also be aware of the CSS child selector, the contents of which IE ignores.)

5. Image replacement technique

It’s always advisable to use regular HTML markup to display text, as opposed to an image. Doing so allows for a faster download speed and has accessibility benefits. However, if you’ve absolutely got your heart set on using a certain font and your site visitors are unlikely to have that font on their computers, then really you’ve got no choice but to use an image.

Say for example, you wanted the top heading of each page to be ‘Buy widgets’, as you’re a widget seller and you’d like to be found for this phrase in the search engines. You’re pretty set on it being an obscure font so you need to use an image:

<h1><img src="widget-image.gif" alt="Buy widgets" /></h1>This is OK but there’s strong evidence to suggest that search engines don’t assign as much importance to alt text as they do real text (because so many webmasters use the alt text to cram in keywords). So, an alternative would be:

<h1><span>Buy widgets</span></h1>Now, this obviously won’t use your obscure font. To fix this problem place these commands in your CSS document:

The image, with your fancy font, will now display and the regular text will be safely out of the way, positioned 2000px to the left of the screen thanks to our CSS rule.

6. CSS box model hack alternative

The box model hack is used to fix a rendering problem in pre-IE 6 browsers, where by the border and padding are included in the width of an element, as opposed to added on. For example, when specifying the dimensions of a container you might use the following CSS rule:

This CSS rule would be applied to:

<div id=&quot;box&quot;>...</div>This means that the total width of the box is 150px (100px width + two 5px borders + two 20px paddings) in all browsers except pre-IE 6 versions. In these browsers the total width would be just 100px, with the padding and border widths being incorporated into this width. The box model hack can be used to fix this, but this can get really messy.

A simple alternative is to use this CSS:

And the new HTML would be:

<div id=&quot;box&quot;><strong><div></strong>...<strong></div></strong></div>

Perfect! Now the box width will always be 150px, regardless of the browser!

7. Centre aligning a block element

Say you wanted to have a fixed width layout website, and the content floated in the middle of the screen. You can use the following CSS command:

You would then enclose <div id=&quot;content&quot;> around every item in the body of the HTML document and it’ll be given an automatic margin on both its left and right, ensuring that it’s always placed in the centre of the screen. Simple… well not quite – we’ve still got the pre-IE 6 versions to worry about, as these browsers won’t centre align the element with this CSS command. You’ll have to change the CSS rules:

This will then centre align the main content, but it’ll also centre align the text! To offset the second, probably undesired, effect we inserted text-align: left into the content div.

8. Vertically aligning with CSS

Vertically aligning with tables was a doddle. To make cell content line up in the middle of a cell you would use vertical-align: middle. This doesn’t really work with a CSS layout. Say you have a navigation menu item whose height is assigned 2em and you insert this vertical align command into the CSS rule. It basically won’t make a difference and the text will be pushed to the top of the box.

Hmmm… not the desired effect. The solution? Specify the line height to be the same as the height of the box itself in the CSS. In this instance, the box is 2em high, so we would insert line-height: 2em into the CSS rule and the text now floats in the middle of the box – perfect!

9. CSS positioning within a container

One of the best things about CSS is that you can position an object absolutely anywhere you want in the document. It’s also possible (and often desirable) to position objects within a container. It’s simple to do too. Simply assign the following CSS rule to the container:

Now any element within this container will be positioned relative to it. Say you had this HTML structure:

<div id=&quot;container&quot;><div id=&quot;navigation&quot;>...</div></div>

To position the navigation exactly 30px from the left and 5px from the top of the container box, you could use these CSS commands:

Perfect! In this particular example, you could of course also use margin: 5px 0 0 30px, but there are some cases where it’s preferable to use positioning.

10. Background colour running to the screen bottom

One of the disadvantages of CSS is its inability to be controlled vertically, causing one particular problem which a table layout doesn’t suffer from. Say you have a column running down the left side of the page, which contains site navigation. The page has a white background, but you want this left column to have a blue background. Simple, you assign it the appropriate CSS rule:

Just one problem though: Because the navigation items don’t continue all the way to the bottom of the screen, neither does the background colour. The blue background colour is being cut off half way down the page, ruining your great design. What can you do!?

Unfortunately the only solution to this is to cheat, and assign the body a background image of exactly the same colour and width as the left column. You would use this CSS command:

This image that you place in the background should be exactly 150px wide and the same blue colour as the background of the left column. The disadvantage of using this method is that you can’t express the left column in terms of em, as if the user resizes text and the column expands, it’s background colour won’t.

At the time of writing though, this is the only solution to this particular problem so the left column will have to be expressed in px if you want it to have a different background colour to the rest of the page.

<section>
   <p>Little</p>
   <p>Piggy</p>    <!-- Want this one -->
</section>

These will do the exact same thing:

p:nth-child(2) { color: red; }

p:nth-of-type(2) { color: red; }

There is a difference though of course.

Our :nth-child selector, in “Plain English,” means select an element if:

1. It is a paragraph element
2. It is the second child of a parent

Our :nth-of-type selector, in “Plain English,” means:

1. Select the second paragraph child of a parent

:nth-of-type is… what’s a good way to say it… less conditional.

Let’s say our markup changed to this:

<section>
   <h1>Words</h1>
   <p>Little</p>
   <p>Piggy</p>    <!-- Want this one -->
</section>

This breaks:

p:nth-child(2) { color: red; } /* Now incorrect */

This still works:

p:nth-of-type(2) { color: red; } /* Still works */

By “breaks”, I mean that the :nth-child selector above is now selecting the word “Little” instead of “Piggy” because that element fulfills both 1) it’s the second child and 2) it’s a paragraph element. By “still works,” I mean that “Piggy” is still being selected because it’s the second paragraph under that parent element.

If we were to add an <h2> after that <h1>, the :nth-child selector wouldn’t select anything at all, because now the second child is no longer a paragraph so that selector finds nothing. The :nth-of-type again still works.

I feel like :nth-of-type is less fragile and more useful in general, despite :nth-child being more common (in my eyes). How often do you think “I want to select the second child of a parent if it just happens to be a paragraph.” Possibly sometimes, but more likely you want to “select the second paragraph” or “select every third table row,” which are cases where :nth-of-type is (again, in my eyes) a stronger choice.

I find most of my “crap, why isn’t this :nth-child selector working?!” moments are because it turns out I’ve tag-qualified the selector and that number child isn’t really that tag. So when using :nth-child, I find it’s generally best to specify the parent and leave :nth-child un-tag-qualified.

dl :nth-child(2) {  } /* is better than */
dd:nth-child(2) {  } /* this */

But, of course it all depends on the exact situation.

Browser support for :nth-of-type is fairly decent… Firefox 3.5+, Opera 9.5+, Chrome 2+, Safari 3.1+, IE 9+. I’d say if you need deeper support, jQuery would have your back (use the selector there, apply a class, and style with that class), but in fact jQuery dropped support for :nth-of-type.

Every web browser uses a base stylesheet. It ensures HTML is rendered reasonably well when you don’t provide custom CSS. You know the kind of thing: blue for unvisited links, purple for visited links, bold for strong tags, larger text for h1 titles etc. Unfortunately, vendors love making our lives complicated and each browser uses a different base. So how can you ensure your custom CSS is not affected by a default style implemented on a specific device?

Enter CSS resets. These strip most styles so elements are rendered consistently across browsers. Typically, all fonts and line heights revert to 100%, margins and padding are set to 0px, borders are removed, and ordered/unordered lists become unstyled.

Eric Meyer’s CSS Reset was one of the first and is the most well known and used. The HTML5 Reset Stylesheet from HTML5 doctor can also help style newer elements. There are several others — CSSReset.com provides a great selection and documentation.

Do you use a CSS reset? Should you?

I’ve looked at a random collection of 30 websites and the majority used a CSS reset. The advantages are clear:

They provide a blank canvas; any styles applied are (almost) certain to be your own.
Development can be more logical: you’re adding styles rather than removing or modifying them.
Browser compatibility issues can be minimized.
Despite these advantages, I don’t use CSS resets. Actually, that’s not quite true — I often use the basic margin and padding reset because the default values are rarely useful:

view plainprint?
* { padding: 0; margin: 0; }
This affects every tag and some developers will tell you it causes havoc or slower CSS processing. I’m yet to encounter a situation where it’s become problematical.

My main issues with CSS resets are:

Additional page weight
Most CSS resets add around 2Kb of code (uncompressed). That may not sound much but it’s a large overhead when the majority of my CSS files rarely exceed 10Kb.

Additional effort
A CSS reset requires you to re-style all your elements — which adds further weight to your file. Sometimes though, I’m happy with the browser’s defaults. Font weights, line heights, link outlines, bullet discs and other styles are often fine. If they’re not, I’ll change them accordingly.

Different browsers render pages differently
No two browsers are the same yet some people expect pixel-perfect rendering across all devices. CSS resets often give the impression that this goal is achievable. It’s not.

Personally, I don’t mind if titles in Firefox are 2px larger than IE or Opera’s idea of ‘bold’ is slightly heavier than Chrome’s. A CSS reset will never resolve those issues for you.

They don’t negate the need for browser testing
I’m not convinced CSS resets aid browser consistency. You must test your site or application in as many devices as possible so you can address errors and bugs caused by your code or the browser.

They don’t fit with my workflow
I’m not a fan of CSS frameworks. I rarely encounter situations where a generic CSS approach applies to the site being built. I may copy a few code snippets from elsewhere but, in general, I prefer to start with an empty file. It remains my code and I know exactly where to go when bugs arise.

Although it’s not as complex, a CSS reset is a framework which can introduce unexpected results.

They don’t save time
Has a CSS reset ever saved you hours of development time?

Before I’m attacked by an angry mob of CSS reset fans, I’m not saying you should never use them. They may they work for you and that’s fine. I suspect they’re also useful to those who are new to web development. However, are you adding a CSS reset because it’s genuinely useful or has it become a development habit?

As a test, try removing the reset styles from your website to see if it makes a significant difference.

Do you use CSS resets? Have you recently adopted or dropped the practice? Do they help?