Why Limit Media

15 Surefire Ways to Break Your CSS

The life of a CSS devel­oper isn’t all about attend­ing glam­orous cham­pagne par­ties, jet-​​setting around the world and hang­ing out with super­mod­els. In fact, when your CSS doesn’t behave the way it should, the job can be down­right tedious. I’ve spent untold hours of my life debug­ging my code — and I’m guess­ing I’m not alone here.

But as silly as it may seem, some of the biggest CSS blun­ders stem from the sim­plest of errors. Know­ing what some of those errors are and remem­ber­ing to look for them can save you hours of wasted labor. Here are fif­teen ways I’ve found to break my CSS for sure — and fif­teen things I always look for when­ever I have a prob­lem in my code.

Miss­ing a Semicolon

CSS rules are com­prised of property-​​value pairs (dec­la­ra­tions) fol­lowed by a semi­colon. Accordng to the CSS spec­i­fi­ca­tion, the last dec­la­ra­tion doesn’t need a semi­colon — because the clos­ing brace effec­tively ends the dec­la­ra­tion just as well. That means some­thing like this is per­fectly acceptable:

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

The only prob­lem is, as soon as you decide to add another dec­la­ra­tion to your pre­vi­ous rule, you’ve now made it all too easy to for­get to add the semi­colon 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 semi­colon in a rule, no mat­ter what.

Miss­ing a Colon

I’ve seen this par­tic­u­lar prob­lem crop up fre­quently while teach­ing classes on CSS. Peo­ple get excited when CSS starts to make sense, and their typ­ing speed increases. The down­side: this makes errors of omis­sion much more likely. And a miss­ing colon is par­tic­u­larly tough to see, since it sits right in the mid­dle of a dec­la­ra­tion. Con­sider the fol­low­ing 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 over­looked in the jum­ble of braces, hyphens, semi­colons and cryp­tic words. As a rule of thumb, if you only have one dec­la­ra­tion not behav­ing itself, this is a good place to start looking.

Miss­ing a Brace

{Braces} around a CSS rule are like the cir­cle of life: reg­u­lar, nat­ural, and expected. And if you ever miss a brace (gen­er­ally a clos­ing brace for what­ever rea­son) — just like if you have a zomb­i­fied corpse that refuses to die — you sud­denly have all sorts of may­hem on your hands.

When an unsus­pect­ing 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 open­ing braces before a clos­ing brace is right out: every­thing from your #wrap rule (in this exam­ple) on would be ignored.

How­ever, this does make debug­ging eas­ier. 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 num­ber of braces hang­ing out in the vicinity.

Mis­spelled Properties

I con­sider the fol­low­ing few errors the bane of dyslexic devel­op­ers every­where. Gen­er­ally speak­ing, I’m a good speller. But when I’m “in the zone” and typ­ing as fast as my fin­gers can carry me, I tend to trans­pose a few let­ters here and there. In writ­ing, this isn’t such a big deal: peo­ple can gen­er­ally fig­ure out what I mean. Com­put­ers, 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 try­ing to refer to the lower edge of an ele­ment. I’m lucky in that I have a decent eye for edit­ing and often catch these mis­takes as I make them. If you’re not so for­tu­nate, using a pro­gram with code col­or­ing like Notepad++ or Adobe Dreamweaver (my per­sonal favorite) can make the job a lot eas­ier: if a prop­erty isn’t col­ored like the other prop­er­ties, than it’s prob­a­bly not much of a prop­erty at all.

Mis­spelled Values

Mis­spellings aren’t lim­ited to just prop­er­ties. And some­times a mis­spelled value can be even more dif­fi­cult to notice:

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

Unfor­tu­nately for the rule above, I’m fairly sure only Snoop Dogg and I have ever tried to mea­sure ele­ments in piz­zles. Instead of the gen­er­ous padding you’d expect this rule to gen­er­ate, this one mis­spelled unit ren­ders the entire dec­la­ra­tion invalid.

Mis­spelled Classes and IDs

No mat­ter how often I cre­ate a div with an ID of “nav­i­ga­tion,” I still find myself writ­ing rules that look more like this:

#navigaiton { float: left; } 

This can be a frus­trat­ing error to track down, because color-​​coded edi­tors won’t help you out here: you could just as eas­ily pur­pose­fully name an ele­ment “nav­i­gaiton” if you really wanted. But I’d rec­om­mend against it.

Improp­erly Ordered Values

Some CSS prop­er­ties have a built-​​in short­hand, which is a great way to save your­self a few lines of code. Unfor­tu­nately, most of the short­hand prop­er­ties are very picky about the order of the property’s val­ues. 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 gain­ing a spe­cific type­face and size. The sec­ond rule will result in a debug­ging ses­sion — while it’s okay to leave some val­ues out of the font dec­la­ra­tion, chang­ing up the order of the val­ues will result in problems.

Mea­sure­ment Val­ues With­out Units

CSS New­bie reader Justin reminded me of this prob­lem the last time I wrote about CSS faux pas. With only a few lim­ited excep­tions, all mea­sure­ment val­ues in CSS need a unit of mea­sure­ment asso­ci­ated with it. Take the fol­low­ing rule for example:

#wrap { margin: 3; }

Three what? Ems? Inches? Piz­zles? The flex­i­bil­ity of CSS that allows us to pick from sev­eral units of mea­sure­ment also means spec­i­fy­ing a unit is fairly important.

Bonus — Two unit-​​agnostic measurements:

1. Val­ues of zero don’t need a unit of mea­sure­ment. Turns out, zero pix­els and zero miles are exactly the same length.
2. Line heights needn’t have a spe­cific unit. A line height of “1.5″, for exam­ple, will sim­ply assume you meant “1.5 times my font size.” For more on this phe­nom­e­non, visit Eric Meyer’s arti­cle on Unit­less Line Heights.

Com­pet­ing Iden­ti­cal Rules

Once a stylesheet gets to be a cer­tain length, it can be dif­fi­cult to remem­ber which rules you’ve already writ­ten unless your CSS is very well orga­nized. And two iden­ti­cal rules at dif­fer­ent spots in your CSS file can wreak havoc on your design and san­ity alike.

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

In this sce­nario, the lat­ter rule would win out over the for­mer, thus remov­ing the mar­gin and apply­ing padding instead. But if you’ve for­got­ten about this duplic­ity, you might go back into your CSS later and try edit­ing the first rule only, and remain per­plexed as to why, no mat­ter how you tweak your mar­gin, you can’t seem to make any difference.

Unin­ten­tion­ally Com­pet­ing Rules

A sim­i­lar prob­lem could force your CSS to com­pete with itself in ways you didn’t expect. For exam­ple, if you had the fol­low­ing code in your XHTML:

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

You could refer to this ele­ment by either its class or its ID. The prob­lem arises when you do both, and for­get that you’ve done so:

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

This code would result in a fixed-​​width nav­i­ga­tion bar, even though the first rule would sug­gest a more flex­i­ble width. Again, hav­ing a well orga­nized stylesheet is the eas­i­est way to avoid this problem.

Call­ing a Class an ID (or vice-​​versa)

I fall into this par­tic­u­lar trap all the time. I’ll write a rule like this:

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

And noth­ing will hap­pen! It often takes me a minute or two to real­ize that the real prob­lem is that I’d given my nav­i­ga­tion bar an ID, not a class. My best advice here is to pick a nam­ing sys­tem that works well for you and be con­sis­tent. If you always call your top nav­i­ga­tion bar “#top­nav”, for exam­ple, you’re far less likely to mis­re­mem­ber your ele­ment names.

Using a Nonex­is­tent Property

Not all CSS prop­er­ties are named the most intu­itively. For exam­ple, this might look like a per­fectly accept­able rule to some­one new to CSS:

body { text-size: 3em; }

The prob­lem is, while there are cer­tainly sev­eral text-​​riffic prop­er­ties, text-​​size isn’t one of them. Instead, we use font-​​size. Which means that the rule above wouldn’t do much of any­thing. Intel­li­gent code-​​coloring edi­tors like Dreamweaver usu­ally make this sort of debug­ging much eas­ier: if it’s not a real CSS prop­erty, it won’t be the same color as the sur­round­ing prop­er­ties. That’s usu­ally my first clue I’ve done some­thing wrong.

Using a Nonex­is­tent Value

This is a sis­ter stum­bling block to the one above. Some val­ues just seem to make sense, but will fail you nonetheless:

td { vertical-align: center; }

You would assume that this rule would ver­ti­cally cen­ter your table text, right? Unfor­tu­nately, while “cen­ter” is indeed an accept­able value for text-​​align, vertical-​​align uses the per­haps less intu­itive “mid­dle” instead. And you’d have to ask a bet­ter edu­cated rhetori­cian than me to fig­ure out the dif­fer­ence between mid­dle and cen­ter in this con­text, because I’m at a loss.

Improp­erly Match­ing Prop­er­ties and Values

Cer­tain CSS dec­la­ra­tions can look cor­rect even to the trained eye, unless that eye is pay­ing par­tic­u­larly close atten­tion. For example:

a { text-transform: italic; }

While this might look like a per­fectly rea­son­able rule, you won’t end up with ital­i­cized text. That’s because “italic” belongs to the font-​​style prop­erty, not the text-​​transform prop­erty. But even most advanced edi­tors won’t catch that bug, as you’ve used a per­fectly rea­son­able prop­erty and value — you’ve just used them in an inap­pro­pri­ate combination.

Not Clos­ing Comments

The gen­tle per­sons at BlogTh­e­meMa­chine tipped me off to this com­mon CSS prob­lem. Can you spot the major dif­fer­ence 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 dif­fer­ence is that the sec­ond rule has an improp­erly closed com­ment tag: /​* ver­sus */​. That seem­ingly insignif­i­cant dif­fer­ence can result in entire swaths of your CSS sud­denly not work­ing. In fact, this tiny blun­der will negate all your CSS from the start of your com­ment until you suc­cess­fully close a sec­ond com­ment. Which if you’re using com­ments to orga­nize your CSS means an entire sec­tion of your site will lose its styling.

These fif­teen tiny blun­ders are sure to give you hours upon hours of CSS frus­tra­tion… 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!