Updating a theme; CSS Challenges

I’ve recently updated the theme used by this wordpress-based blog. In doing so I learned a lot about Cascading Style Sheets (CSS), layout and the implications on a website that uses a mix of base “product” (i.e. WordPress) and a multitude of plugins from a variety of authors that often follow their own standards on style and formatting. This article summarises the key things I’ve learned. They are not in any particular order.

How Are You Going to Style Your Site?

Before jumping into creating the style (CSS code itself and the CSS references in the HTML/PHP code) for your theme, you need to have a think about your approach. You need to think about the general layout of the pages (sections, placement, overlapping elements) and how they need to be defined in CSS, as well as the look and feel of the site (fonts, sizes, vertical spacing etc.).

I have covered how I approached the layout in a separate post. I applied the concepts as mentioned below, such as the use of divs for structural elements.

It makes sense to start with an existing theme’s style and modify it. That’s what I did. But I found halfway through that I was discarding a lot and restructuring the file(s) to suit my approach. The following are some general approach-type comments.

Approach to the Style Structure

Here are a few rules I tried to follow when building the theme; the structure of the style and how it will be implemented in CSS. This involves both the various div and class references in the HTML/PHP code and the CSS code itself:

#1 – Think about the overall look’n'feel of your site and identify the common or default settings (e.g. fonts and font sizes for text and headings) Try to set some default/fallback settings in the generic settings (e.g. a {…}) like fonts, sizes, colours that will apply to every element on the page. For example all headings, body text and lists should use a standard default style for all pages. This way you only need to make changes in one place.

#2 – Use divs and id selectors (<div id=”blah”>) for layout/structural elements like sections of a page or where you want to do some funky placement. These definitions will cover sizing, placement, spacing, and background elements.

#3 – Use sectional-specific overrides for tags, such as <ul> maps to #blah ul where you need a different look in a specific section (such as the sidebar).

#4 – Use class selectors sparingly; normally where I want to have some sub-sections with different layouts (like in the main body posts) or where a plugin specifically needs them.

#5 – Use highly specific overrides where a particular element is picking up some settings unexpectedly from a generic setting, and changing one of the more generic settings messes up other things. These are kept to an absolute minimum.

Approach to CSS File Structure

Try to keep your CSS reasonably simple from a maintenance perspective. Products like Wordress that support plugins will test your (base) CSS; some have their own CSS files, others expect you to modify your style.css. Either way, if you’re CSS is a mess before adding a new plugin, it will be a nightmare to make the new plugin pages look like your theme.

Some specific CSS file approaches I use:

• Structure the CSS file along the structure of the pages (e.g. header, body, sidebar, footer) and mark each one with a comment so it’s easy to find stuff when the CSS file gets big. For the plugin CSS, if it’s completely standalone or covering the entire page I put it at the bottom of the CSS file. If I need some plugin-specific CSS code that overrides something else I place it near the code it’s overriding.
• I have used a common set of values for the most common HTML tags (e.g. “html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, font, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td”) at the top of the file setting common values like colours, font sizes etc.

This list is not exhaustive, and won’t solve every problem, but I found it helped me a lot (eventually).

Vertical Spacing in the CSS

I spent ages trying to make vertical spacing look how I wanted. I ended up with a mix of margins and padding both above and below some elements. It became a mess!

When deciding on where you will (consistently) apply spacing (padding and margins) you could always apply it below elements (e.g. padding-bottom, margin-bottom), always above elements (e.g. padding-top, margin-top) or the mess I ended up with.

I’d suggest to pick one approach and try to stick to it, such as only applying margins below an element. So headings would have a margin set below them, as would the paragraphs following. This seems to be the approach used on many production sites (such as The Age online newspaper) and assists maintainability of the CSS.

Technical Considerations and Challenges

There are a number of technical considerations when working with CSS for WordPress and it’s various plugins (which would also be relevant for other LAMP packages, such as Gallery2).

Use Firebug

The Firefox plugin Firebug is your friend. It will show you the CSS settings being used. You can edit changes on the fly.

I particularly like the ability to edit a setting and use the up/down keys to toggle through the settings. When working on positioning, you can easily use the up/down keys to move elements around; very nice and a great time saver.

Use of the hover Psuedo-Class

I like to use the hover psuedo-class for links; underline for text, border for images. Don’t get the two confused; use text-decoration for the “a” (only) defs and border for the “a img” defs. The following works well:

a {
   color: #224040;
   font-weight: bold;
}
a:visited {
}
a:hover {
   text-decoration: underline;
}
img {
   margin: 2px;
}
a img {
   border: 1px solid #FFFFFF;
   background-color: #FFFFFF;
}
a img:hover {
   border: 1px solid #224040;
}

Typos

Be wary of typo’s. I spent ages trying to figure out why my underlines weren’t working for a hover psuedo-class. It turned out I had put “text-decoration: underlined” instead of the correct “text-decoration: underline”.

Embedded CSS

Be wary of plugins that insert CSS directly into the page headers. I’ve found Vipers Video Quicktags and Collapsing Archives/Categories do that, but seem to play well in the sandpit; I’ve not had any clashes.

Lists in Plugins

I often found that lists just didn’t behave consistently. I had some generic settings for lists and some sidebar-specific overrides. Some of the plugin lists appeared correctly and others didn’t.

I found that some plugins, and wordpress functions, put the <ul> (or ol) and <\ul> tags around their lists, and others didn’t. I had some overrides built that assumed the ul/ol was there. I had to allow for both in my CSS. For example, to make sure none of my sidebar lists had bullets I set:

#sidebar ul, #sidebar li {
   list-style-type:none;
}

Understand Specificity

Why some settings seem to override others, even when you think the inheritance should drive the behaviour you are expecting. This is due to specificity. You think that as you haven’t set a specific CSS setting for an element, it should pickup the default one but instead it picks up one from an id somewhere else up the tree.

You need to understand specificity. There are a few good articles out there, such as:

• CSS Specificity: Things You Should Know
• CSS: Specificity Wars

I don’t know that I truly understand, but I was able to apply very specific overrides for some of my plugin CSS to achieve what I wanted. For example, I needed to override some settings for a WPG2 image that’s in a list. It has a class specified, but without the following, it was using the #sidebar ul li settings:

#sidebar ul li .g2image_normal {
   margin:0;
   padding:0 11px 12px;
}

I’m sure I uncovered a lot more things I didn’t know and should have documented, but that’s all I can recall. I hope it’s of value to someone.