<\/p>\n<\/p>\n
Imagine: You\u2019ve 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\u2026 what the heck?! Nothing\u2019s working right! You know you didn\u2019t make any huge errors in your code, but something is obviously wrong.<\/p>\n
We\u2019ve 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.<\/p>\n
Closing brackets<\/strong> are notoriously easy to miss, especially if you don\u2019t put them on a line all by themselves (and I usually don\u2019t). 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.<\/p>\n A missing semicolon<\/strong> can likewise cause your code to start behaving wonky. CSS specifications state that you don\u2019t need a semicolon on your very last rule before your closing bracket, but in my experience that\u2019s 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.<\/p>\n Is there any chance you have a misspelled class or ID<\/strong>? It may sound obvious, but I\u2019ve 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 \u2013 it\u2019s going to be easier to notice a misspelling in the \u201cleftSidebar\u201d class than it is the \u201cltSdbr\u201d class.<\/p>\n Misspelled properties or values<\/strong> have also caused me more than their fair share of trouble. There are certain words I tend to misspell when I\u2019m typing too quickly, and it just so happens that there are a lot of CSS properties with related names. I don\u2019t care how much I\u2019m \u201cin the zone,\u201d there\u2019s still about a 50% chance I\u2019m going to try to apply a \u201cbakcground-color\u201d somewhere along the line.<\/p>\n Bad CSS values<\/strong> can be a bear to hunt down, particularly if you\u2019re convinced that the value you\u2019re using really exists. Some invalid values are more obvious than others \u2013 a background-color of \u201c1px\u201d would be relatively easy to spot, but what about a vertical-align of \u201ccenter,\u201d like I mentioned last week?<\/a> 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 \u201cmiddle,\u201d not the center. An alignment of center won\u2019t create nearly the presentation you\u2019re expecting.<\/p>\n If you start your CSS debugging by looking at these five common problem areas first, there\u2019s a good chance you\u2019ll save yourself a whole lot of time \u2013 and a massive headache to boot. If you have any other ideas for common areas of CSS misstep, offer them up in the comments!<\/p>\n.sidebar {\n\twidth: 200px;\n\tbackground-color: #333;\n.sidebar h3 {\n\t\/* None of these rules are applied! *\/\n\tfont-size: 1.4em;\n\tcolor: #fff; }<\/pre>\n.sidebar {\n\twidth: 200px;\n\tbackground-color: #333\n\t\/* The following rule won't render! *\/\n\tpadding: 5px;\n}<\/pre>\n.siedbar {\n\t\/* Dunno what a siedbar is, but I'm\n\t pretty sure it's not in my XHTML. *\/\n\twidth: 200px;\n}<\/pre>\n.sidebar {\n\t\/* The following property does exactly \n\t bupkis. Dyslexics Untie! *\/\n\tbakcground-color: #333;\n}<\/pre>\n.sidebar img {\n\t\/* This image isn't really going anywhere. *\/\n\tvertical-align: center;\n}<\/pre>\n