Even if you’re an absolute beginner, making changes to an existing CSS style sheet is not complicated. Yes, there are things you need to learn, and computer code is often unforgiving, but as I hope I explained in the previous post the basics are easy to grasp. Fuel your own initiative with a reference site like W3Schools, where you can pick up tips and information as needed, or even try out techniques before implementing them, and the only thing standing between you and success will be the bitter realization that an innocent misstep may lead to hours of hysteria because you don’t know how to protect yourself from your own ignorance. So let’s solve that problem.
Whatever goals you have for learning or even just tinkering with CSS, the first thing you need to do is see those goals in context. Yes, finding the exact right shade of green for your hyperlinks is important, but so is ensuring the stability and functionality of your site. There’s nothing inherently dangerous about making changes or even making mistakes when you’re working with computer code as long as you know how to protect yourself from inevitable errors. That protection begins with making sure you can always get back to the most recent stable build, even after you’ve made (and forgotten about) multiple changes.
1. CTRL-Z IS YOUR FRIEND. CTRL-Y IS YOUR OTHER FRIEND.
If you’ve been using a computer for any length of time you probably know that pressing and holding the Control (Ctrl) key, then simultaneously pressing the Z key will undo the most recent action in many applications. Most word-processing and image-editing software uses this convention, and the same holds true for many of the applications used to edit CSS style sheets.
If you make a change to the CSS in your style sheet, then upload the change and get results you’re not expecting, you can usually press Ctrl-Z to undo your mistake. Since mistakes are quite often unintentional you may not even be sure what you did to cause the problem, so Ctrl-Z can be a real lifesaver. Even better, many applications allow for multiple undos, so you can go back through five, twenty or even fifty edits. (Check the documentation to determine the exact number.) Since some mistakes become apparent only after multiple changes, Ctrl-Z may be the only way to step back through the sequence that triggered the problem.
What many people don’t know is that holding the Control key down and pressing the Y key will often redo an action, meaning between Ctrl-Z and Ctrl-Y it’s possible to go backwards and forwards through your most recent changes. For example, maybe you made a change but forgot what the original value was and suddenly realize it’s important. With Ctrl-Z and Ctrl-Y you can cycle back and read the value, write it down on a piece of paper or copy it to a separate document for reference, then cycle back to where you were. (What you must not do is cycle backwards with Ctrl-Z and make a change unless you’re sure you won’t need to press Ctrl-Y again. Any change you make when you go backwards with Ctrl-Z necessarily starts a new Ctrl-Y sequence in the application’s memory at that point.)
2. LEARN HOW TO COMMENT YOUR CODE AND DO IT TO EXCESS.
Adding comments to code is not only important, it’s easy. In fact, it’s so easy you can learn how to do it right now. Open this link and you’ll see a page on the W3Schools’ site that shows how to create a horizontal menu. On the left is a panel bursting with CSS and HTML, and on the right you can see how your browser displays that code.
In the left-hand panel, toward the top, locate these five lines of code:
Each of those lines tells your browser to do something to the HTML that follows so it will display as intended. If you change some of the values or accidentally delete a character here or there you’ll affect the way the code displays, but you may not always notice such changes. Many computer languages often balk when something isn’t exactly right, but with CSS there’s a fair amount of wiggle room, and quite often that wiggle room itself causes problems.
We’ll come back to that conundrum in a moment, but right now I want you to type a few words after the semi-colon on one of those five lines, as follows:
/* (your blather here) */
The key is to make sure you type /* first and */ last. When you’re done, press the Submit Code button at the top of the screen and you should see absolutely nothing change in the panel on the right, even though you have added information to the CSS rule set that controls how the page displays. As you might imagine the utility of this invisible text is almost boundless, which is why you should take advantage of it constantly. For example, any time I change an original value in a line of CSS code I add this comment on the same line:
/* was ____ */
In place of the blank I put whatever the original value was, like 30px or float:left or whatever, because after the fact I routinely find these little notes indispensable. Yes, I could look at the original style sheet, a copy of which I always keep on hand in case things go completely south, but why open another document when I can make sure all the information I need is always in the most recent version I’m working on?
Since you can now add comments to a single line of CSS you may be wondering if you can do the same to multiple lines as well, and the answer is yes: with /* and */ you can span as many lines as you like. To see for yourself, go back to the W3Schools page and comment out the entire first CSS rule beginning with UL at the top and the closing curly bracket } at the bottom. When you’re done, click Submit Code again to see what happens.
The change you see in the right panel takes place because your browser is no longer reading the block of CSS code you commented out. While that’s marginally interesting in itself for diagnostic purposes, the real value in doing this is that you’ve just created an in-line copy of that block of code. If you now copy and paste the commented code (without the comments) back into the panel on the left you’ll have a fully functional style sheet that you can work on, but you’ll also have a backup of the rule you’re messing with that you can instantly reintroduce if things go wrong.
Learning how to comment CSS with /* and */ has additional advantages, chief among them the fact that you can also comment PHP files the same way. You may be thinking you don’t know what a PHP file is or that you’re never going to need to comment one, but you’d probably be wrong in that assumption. CSS is a gateway computer language, and often leads to the hard stuff.
3. USE A DEDICATED TEXT (OR CSS) EDITOR.
Editing CSS may seem self-evident: you locate a style sheet, open it up and hack away. What you probably don’t know is that the application you use can have a big impact on how successful you are when editing any computer code. Word-processing applications like Microsoft Word should never, ever be used because they can introduce formatting characters into your document, and that would be a very bad thing. At a bare minimum you should use a text editor like Notepad or whatever Apple’s equivalent is to make sure the text you’re working on is the exact same text and nothing but the text that will be read by the browsers displaying your pages.
If the style sheet you’re working on is well-formatted (and it should be) then even a simple tool like Notepad will show you the basic structure of the CSS code at a glance. For example, here’s a CSS rule from the style sheet for my this site, as viewed in Notepad:
As you can see, the structure of the rule is clear: the selectors are flush-left at the top, the declaration block is indented between the curly brackets, which in turn occupy lines by themselves to make their importance clear. Once you get used to that formatting — and it won’t take long — you can often tell at a glance if something’s missing, even if your site otherwise seems to be working just fine.
The problem with an application like Notepad is that it’s not designed to give you all the information that’s available in that CSS rule. Here’s what the same nine lines of code look like in EditPlus, the text editor I’ve been using for over a decade:
The first thing you’ll notice are the colors, but the first thing I want you to pay attention to are the line numbers on the left. You don’t get line numbers in Notepad and other generic text editors, and when you’re working on a small file that may not matter. But in a large CSS style sheet there may be multiple places where the same selector is declared, and if you don’t have some way of noting the relative position of the one you’re working on you may end up making changes in the wrong location — or making changes twice, or assuming you forgot to make changes that you have in fact already saved. Line numbers not only give you a useful reference, in some editors they may even be specifically referenced if your code fails or triggers an error.
As to the colors, although the text in the above image is exactly the same as in the previous image, my dedicated editor is clearly showing me additional useful information. Selectors and numeric values are still in black, as they were in Notepad, but because the other text is now displayed in color the black text gains significance. In the declaration block each valid property now appears in blue, while text values appear in red. Finally, any comments I’ve added appear in green, including CSS declarations that I’ve commented out, as on the third line.
The fact that my text editor recognizes such things also means that when I mistype something it will not be recognized and displayed in the color I’ve come to expect. I know all of the properties in my style sheet should appear blue, so if I see one that’s black I know my editor has failed to recognize it, which means I’ve written it wrong. Likewise, if I fail to properly close a comment with */ then everything in the file after the initial /* turns green until the proper closing characters are encountered down the line, if they are at all. That sea of green instantly alerts me to a problem I would almost certainly overlook in an application like Notepad.
Because working with code can be tedious and finicky, people have been making dedicated applications for doing so since computer code was invented. Today there are a dizzying array of easy-to-use applications to choose from, including editors specifically dedicated to CSS that will not only help you spot mistakes, but show you the effect of your edits in real time. If you’re not sure which one to use, ask around, do a few web searches and grab a demo of anything that catches your eye. You’ll know fairly quickly if what you’re using is useful, confusing or complete overkill.
4. CSS IS A LANGUAGE. EDITING CSS IS A PROCESS.
Take it from me: you may think what you want are immediate results, but what you really want is to avoid feeling utterly helpless in the aftermath of your own foolhardy ignorance. So before you do even a single edit, take a moment — and it only takes a moment — to create a dedicated virtual space in which to work. (No, your desktop is not a dedicated space. Yes, a folder on your desktop is fine.)
In your workspace you should create another folder (or folders) to hold original backups of your theme and any other files you will need to work on, many of which may be added later. You should also create a folder for downloads from your site whether it’s active yet or not. Controlling where files land is part of making sure you don’t open or overwrite the wrong file by accident. (At some point you may end up with multiple files named style.css, but the folders they’re in should tell you which one is current.) Under no circumstances should you ever edit backed up files directly. If and when you need to make a change, copy the file you intend to work on into your working folder and make the changes there.
Why is this kind of file management important? Because as I mentioned before the fact that you can make mistakes in CSS that will not break a style sheet means mistakes can get past you and go live. To see what I mean, go back to the left-hand panel of the W3Schools page you opened earlier and either use Ctrl-Z to undo all of your changes or click on the end of the URL and press the Enter key to force the page to reload. (Pressing the reload button will not clear your changes.)
Now, find the line of CSS in the left panel that reads float:left; and add a single uncommented word after the semi-colon on that line. You can add a space first if you want, or not — it doesn’t matter. Just type in a single word, then press the Submit Code button and see if you notice a change. If you’re not sure, make the cursor active in the left panel again and press Ctrl-Z, then press Submit Code again to undo the change you just made. Do you see anything change in the text displayed on the right? Clearly the browser hasn’t crashed and the page is displaying mostly as intended, but does that mean absolutely nothing changed when you tossed a stray word into that CSS rule?
In my browser, when I have the window fully expanded to fit my monitor, I see absolutely no change when I add a stray, uncommented word following that float declaration. However, if I double-click the top of the browser window so the window becomes movable, then expand the browser to its full width (which is just a smidge more), the word “In” at the beginning of the text suddenly wraps to the end of the last button on the right. I can confirm this by undoing the change and pressing Submit Code again, at which point the text jumps back and maintains its original formatting regardless of the width of the browser window.
Would you have spotted that change before uploading your style sheet? Unfortunately, for the most part you will have to rely on your eyes to tell you if the changes you make are working or not, which means little mistakes like that are going to get through. Which is why having current backups is always important.
5. LEARN HOW TO COMPARE TWO FILES TO EACH OTHER.
Having backups is critical when you realize something is wrong, but it doesn’t necessarily mean you’ll be able to figure out what the problem is. Yes, a stray word that doesn’t belong may be relatively easy to spot if you scan each line, but what happens if the problem you’ve discovered is caused by an otherwise valid value? If you changed 30px to 20px somewhere and it threw your theme off, it’s not going to matter how careful you are in scanning your style sheet because the mistake is going to be considered valid by your text editor.
The solution is of course to compare your current style sheet to a backup the predates the problem, or even the original version if you aren’t even sure when the problem started. But how do you do that? If your style sheet is a thousand lines long, and what you’re looking for might be a colon passing itself off as a semi-colon, are you going to find that discrepancy? The odds are long against it, and fall to zero if what you’re looking for is an otherwise valid value. Fortunately, because this problem happens a lot there are a number of programs you can use to quickly accomplish your goal.
I’ve used WinMerge for as long as I can remember because it’s intuitive (to me) and I’m familiar with it, but there are other programs that do the same thing. When I’m not sure if or how a file differs from another I load both into WinMerge and it shows me line-by-line where any differences are — and because it’s a computer scanning all those tiny characters I know it won’t overlook a single discrepancy. Care must be taken when comparing two files with the same name — as often happens with versions of style.css in different locations — but good file-management habits minimize the risk because WinMerge shows the full path in each window. (If you’re still concerned you can simply rename one of the files before you open it to make the distinction clear.)
— Mark Barrett