Better CSS Debugging with OSX

CSS has never been the easiest part of web design. Browser inconsistencies, holes in the specs and some things that we just haven’t figured out how to do can leave a designer a little frustrated (and thinking about slicing up an image in Fireworks and building on of those table things). But it’s getting easier. Some common sense, a few tricks and some very modern tools for OSX have made the job less of a horror and even let it border on a good time.

The following is a description of the way that I handle the process of CSS design and debugging, along with some tips collected from around the web. I will state up front that I cannot claim to have religiously put every one of these lessons into practice. I offer this to the community as a resource and look forward to comments and additions.

Learn From Others

There’s a pretty broad line between theft and inspiration in the creative world. Especially in a field as technical as web design. You have to be willing to learn how others accomplished their very cool designs and then figure out how those techniques are going to help you accomplish your own designs. Stealing a layout is a bad thing. Stealing an image is worse. Learning a technique from someone is, however, a good thing. My basic method is to find a site I really like, preferably one with semantic code and well organized style sheets, and pull it apart. You can do this with the view source option in your browser or you can use some tools that make things much, much easier.

I’m going to mention Xylescope first. It’s days may be numbered with the release of the latest version of Firebug (which I’ll get to in a second), but I’m still infatuated with its interface and certain aspects of its flexibility. Xylescope has a few specific areas in which it shines when learning from other’s code. First, it shows you the cascade and simultaneously allows you to view the (X)HTML and CSS behind any given element, which you can select in the integrated browser with a click of the mouse. You can also select items in the source code and have them highlighted in the browser. Once you’re viewing an element, you can see the full cascade of styles that affect it. And the cascade view includes thumbnails of the background images that are commonly used in CSS layouts to separate presentation from code, which makes it easy to tell how images were layered to produce different visual effects. All in a stylish interface, as I mentioned before. There are bookmarklets available to open any page in Xylescope from your browser. You can also experiment with styles by changing their properties and pressing enter to see their effect in the browser window. The browser is based on Safari.

Which, of course, brings us to Firebug. Firebug can do all of the aforementioned tricks, plus it can do it right from within Firefox, which is preferable to me for development. (One thing that Xylescope can do that Firebug can’t is integrate with a text editor and auto update). The interface isn’t as beautiful, but it has the added benefits of javascript and Ajax debugging, which are indispensable. Clicking the CSS tab and selecting “Inspect” in Firebeg allows you to hover and click elements in the current layout to see their (X)HTML and CSS. Like Xylescope, Firebug shows the whole cascade of styles affecting the element and crosses out overridden styles, also indicating inheritance. Hovering over properties with background images can pop up thumbnails, but it’s not as fluid as Xylescope. Still, Firebug is by far the greatest tool I have for exploring the DOM, layout and CSS. As well as all kinds of web related debugging, but I’ll get there.

CSSEdit, which I’ll cover in more detail later as well, also has a feature called X-Ray in its live preview window. When you turn on X-Ray and click an element in the layout, its cascade of selectors is shown in the bottom of the window. You can use the Extract and Override command to pull out and play with all of the stylesheets referenced in a site. If your looking to consolidate your analysis and editing into one tool, this one does a good job of covering both ends. CSSEdit also comes with browser integration bookmarklets.

A Solid Base

Writing valid, semantic XHTML isn’t for sissies. It takes planning and the guts to leave out extraneous containers and make proper use of elements. But it’s a basis for creating bug-free CSS code. If you want flexibility in your design and ground on which to stand when it comes time to find the quirks in your CSS, it really helps to start with XHTML that validates.

A quick definition for those who don’t already know: Semantic code means that your content is presented in the source code in a manner that makes sense to human readers, and using tags that make sense without any styling based on their implied meaning. Presentation is completely separated from the content, meaning no <font> tags, background images, colors, etc. An <h1> tag means that it’s a first level headline and of the most importance, not just that you want big text.

TextMate, which seems to get mentioned in everything I write, is my absolute favorite tool for writing XHTML. I use a combination of Snippets and Commands to increase efficiency, and TextMate handles code highlighting and indentation. The screencast at the Macromates site is a pretty good overview, but I’ve written most of my snippets to suit my own needs and highly recommend doing so. I can validate code offline and it has built-in support for HTML Tidy (which can wreak havoc on a page fragment, include file or links with lots of embedded entities that you don’t want converted, watch out!). A live preview window allows me to see the structure of the document before adding any styling.

CSS Editing: Tips

Some general tips for CSS Editing that will help you with debugging later…

Start your project out by resetting your CSS.

This will give you a level playing field and remove a few quirks. Just keep in mind that you have to define every style manually now.

Use shortcuts where you can.

Fewer lines of code can make your CSS file easier to read and debug later.

Use semantic naming conventions.

Don’t call your logo container “header” because it might not always be positioned at the head of your document when the styling is finished. Call it something like “branding” and you’ll know what it is later. This is especially true of sidebars and specific text styles, where naming something “leftnav” or “orangeblock” can lead to complete misnomers when you decide to revamp the page. And yes, I break my own rules, as in the case of this page, which has both a sidebar and a footer in the XHTML and style definitions. I won’t waste space with excuses, I’ll simply say that I’m a little more lax about these things when I know that no one else will ever be working on the site and that the code will die with me ;-).

Separate your stylesheets later.

Some may disagree with me on this one, but I tend to find it easiest to create all of my styles in one file and then separate the hacks and secondary styles into other stylesheets later. This allows me to search the text for a style in just one file when I’m making quick adjustments and working outside of an integrated workflow.

Keep code organized.

There are a few common methods of organizing CSS code. You can group styles related to certain areas of a layout or you can separate layout and text styling. I tend to use the former. I use CSSEdit’s grouping feature to create files that can be easily navigated in the left pane. Then when I want to edit a paragraph in my main content section, I can just locate the “content” group and search for the p selector.

Be specific.

The more specific you make your definitions, the less likely you’ll be to cause overlaps and the more likely you’ll be to hit the element you want to adjust. You can be forward looking and make use of CSS3 selectors and attribute selectors if you want…

Margins v. Padding

You can save yourself some hacking in Internet Explorer if you use margins instead of padding where possible. If you’re working with floats, see if you can add a margin to a neighboring element or the current element to give you the space you need and the box model won’t be as much of an issue.

Remove unnecessary code.

Xylescope and Firebug can both help you locate overlapping styles. Even with just a live preview in CSSEdit you can experiment with removing declarations and seeing whether they had an effect or not. Unnecessary code leads to unnecessary headaches.

CSS Editing: Tools

I use CSSEdit 2 for editing my stylesheets. As an aside, let me mention that if you want to, you can integrate TextMate (or BBEdit) and Xylescope and do a pretty fantastic job of editing CSS files with a Cascade browser, live updates, and all the goodness of TextMate CSS editing. However, I choose CSSEdit 2 because it has built in validation, Milestones (version control) and can handle live previews on web applications.

I usually use CSSEdit with just the source window open (⌘-3). If I can’t remember a declaration syntax or want to access a favorite font family combination, I just hit ⌘-2 and open the visual editor next to the source editor. I like the source editor’s code completion and suggestion, it’s well written and very efficient. I wish that the ⌘-return function was a little more reliable: it should jump to a new line without inserting a line break, but it only works half the time. When I use the “Insert semicolon automatically” preference (which I like), this behavior is slightly annoying, as it either requires a ⌃-E, ⌘-→, or → to the end of the line before hitting return.

One of my favorite things about CSSEdit is the live preview. It overrides the stylesheets for a website and lets you edit them live, and save your changes. This method allows you to preview your style sheets even on a php based site like a blog or web application, and if you’re set up to run a local server, it’s a simple matter of typing in a local address.

The validate feature makes it a snap to look for errors as you write your code, and I tend to validate every once in a while just to make sure I haven’t made any. The first thing I do when looking for bugs is to validate. The Milestone feature provides version control and lets you try out an idea or work in a hack or workaround and be able to easily restore a previous state without a whole series of ⌘-Zs.

CSSEdit also makes it really easy to organize your code, allowing for grouping of sections that appear as comments in your code and folders in the browser. Folders can be collapsed and expanded. I use this to create a section for the reset, layout and basic text styling, and then create groups for specific styles for each section (branding, content, secondary content, etc.).

TextMate has some great tools for CSS Editing as well. I’ve devised and submitted some workflow improvements that were the beginning of my own personal workflow. Once CSSEdit came out, I pretty much stopped editing CSS in TM, but it still happens, and it’s still a pleasure. Code Completion with the ability to remember your previous ID’s and classes is in the works and looking really cool. Plus it has drag and drop for images, which you can make conditional depending on what type of definition you drop them in to. See my past article on TextMate CSS Editing for more explanation and tips.

Bugs (get ‘em off me!)

When I finish my initial design, that generally means it works in Firefox 2.0 for OSX at a couple different screen resolutions. Then I put it through the paces, in Firefox first. The reason for concentrating on Firefox before I do any other browser debugging is that of the standards compliant browsers, Firefox tends to be the most common. And developing for a standards compliant browser and working backwards only makes sense, as progressively enhancing a site that is poorly coded to work with a non-compliant browser will leave you with a real mess. So I pull up Firefox versions 1.5 and 2 and test at different window sizes from 800px up to 1900px, test all of my hover behaviors, and try out other variables. If the site has more than one page design, then I repeat as necessary.

Debugging in Firefox is also nice because of the tools available. The Web Developer toolbar is an amazing tool. It provides you with quick options to disable everything from stylesheets to cookies, autofill forms, edit styles in the browser, etc. Firebug, as mentioned before, is indispensable. Using the Inspect tool and being able to see inheritance and cascade, while trying adjustments live, is an excellent tool. If this functionality existed for Internet Explorer, I could live the simple life. There are various plugins and bookmarklets for Xylescope, CSSEdit and other 3rd party software that can make extracting, viewing and editing source code and stylesheets an integrated part of Firefox.

Then it’s time for other browsers. You could go in order of popularity or in order of CSS compliance. I work somewhere in between. From what I know, Opera is even more CSS compatible than Firefox, so going there next would be a logical step. But Opera is not without quirks and is so low on the popularity list that if my page is perfect in Firefox and both my XHTML and my CSS validate, I’ll wait on Opera. And despite their enormous popularity, Internet Explorer 6 and lower also get moved to the end of the list because I know they’ll take the most hackery, so I’ll make sure everything is smooth up to that point. I rarely support IE 5.5 and lower anymore, but depending on the site, it happens. I’ll check in Netscape, but rarely have a problem since it’s based on Firefox now, and I don’t support older versions. So I work on Safari next, and then the PC version of Firefox. Then Mozilla, Camino and Opera. If the site requires support for other browsers or special cases such as mobile or embedded browsers, then further testing is necessary. But before I get to that, I have to deal with IE6.

Honestly, Internet Explorer 6 is the bane of my existence. I found a tool called CrossOver for OSX that allows you to run certain PC applications natively in OSX on an Intel Mac using WINE. It’s helped ease the process of testing a site on IE, but certainly doesn’t relieve the headaches that certain quirks can cause. Try some of the tricks and resources below before pulling out all of your hair. My absolute favorite method for cleaning up IE6 is conditional comments. They allow you to separate your problematic declarations from the rest of your styles and declare them only for IE. If you call a style sheet using a conditional comment after the other styles have loaded, IE will override the previously declared styles with the new ones. Other browsers will just ignore the block as a comment. It works much better than a bunch of hacks and is far cleaner. This can be used to accomplish progressive enhancement and provide fallbacks for Internet Explorer. There are also some bookmarklets you can use to emulate a couple of the Firefox Web Developer features. Crossover can’t run IE7, so I do have to load up my PC and KVM switcher again to test multiple versions of Explorer.

There are a few tools like Screen capture and Remote Access service for cross platform compatibility testing and HTML design quality assurance.”>BrowserCam that let you see a screen in dozens of different browsers. These are great for relatively static designs but don’t give you much opportunity to test hover behaviors or debug platforms you don’t have access to. You might as well set up a PC with the necessary browsers, load your Mac with every browser you can find, and run Linux on one of them to test for those rare people using Konqueror or Linux flavors of more mainstream browsers.

Browser Quirks

There are a ton of browser quirks and not all of them are related to Internet Explorer. There are some general techniques for finding the offending declarations or necessary workarounds and specific methods for implementing them for individual browsers. I’m not going to detail every browser hack here, but I’ll help you figure out how to find them.

Use Borders.

There are bookmarklets and stylesheets available for adding borders to block level elements. The Web Developer toolbar for Firefox is handy for this and a multitude of other tasks. Adding borders can help you see how things are fitting together and where something unexpected might be happening, and it works in every browser. Remember that adding a 1px border adds 2px to your width and height, so in a float model with very tight margins this could affect your layout.

Understand the Box Model.

Especially in the case of debugging Internet Explorer, understanding the box model in CSS is paramount. Internet Explorer 6 does a horrific job of handling the box model and can cause endless headaches, even after you get it.

Zero Margins, Position Relative

When things aren’t working as planned, try zeroing margins and setting position: relative where applicable. This is sometimes a magic bullet, especially in IE.

Selective Reduction

When your searching for the culprit in a browser quirk case, start selectively removing styles until you find the one that’s affecting the browser in question. Use CSSEdit’s Milestone feature, or just use comments in your code to disable styles until you get down to the nitty-gritty. Once you find the style you can copy it out and find a workaround for that browser.

Quirksmode, Position Is Everything

Quirksmode documents browser quirks and can often be the source of a solution to your particular problem. Position is Everything works to explain browser bugs and covers general CSS problems. Start your search for answers at sites like these.

Tell Google all your problems

Chances are, someone has had this problem before. If you can describe it properly, you can find the answer. Try specific searches first, like “floated div appears halfway down the page in internet explorer 5.5″ and then move to more general seearches “floated div bug ie 5″. Remember that a lot of answers come in forums and people don’t always do the best job of describing the problem in their post titles or even in the post itself. Try coming at the description from a different angle.

There are a lot of good resources available for further exploration… too many to list. In the end CSS is still a challenge but has significant advantages and rewards. The tools covered here do make things a little easier, though.

Well there, short and sweet, right? Hope there’s some useful information in there. I’d love to hear responses and additions to this article.

browsers» bugs» CSS» cssedit» design» development» firefox» hacks» opera» plugins» quirks» safari» standards» textmate» tips» tools» tricks» validation» web standards» webdesign» xhtml» xylescope»