Main Points

  • CSS Identification Building coherent style rules. This is basic but absolutely critical to building a maintainable website.
  • CSS Zen Garden Tips Want to create a design like the master? Then study, learn, and worship the masters. Dave Shea may die and roll over in his grave, but here's what I've picked up.
  • XHTML Best Practices CSS does not exist in a vacuum, it operates on content. Here are the XHTML best practices to create a solid foundation for your CSS.
  • Skip to Main Points links return to the Main Points menu.

Here are important CSS Tips to remember.

CSS Identification

There is a movement in the CSS community which I respectfully disagree with. It says that HTML should be as light as possible, that it should reference only content. I agree that if you don't need it, why put it in? Also, from a code separation standpoint, HTML should absolutely define content and CSS should define appearance. However, it's in the implementation that I believe some of the shortcomings of this branch of "best practices" become apparent. In this school of thought, HTML tags are natively present in the webpage, so why add anything else if you don't absolutely need to. Use tags as the basis of your CSS style rules, which produces style rules which look like, body h3 {...}, or ul p span {...}. This kind of CSS is highly specific to the page. That would be fine if the page never changes, but how many websites do you know like that? What happens if you need to change that span to a div? More insidiously, what happens when you remove the lists from this webpage? That's right, you lose all the styling on your span tags even though you never touched them. Identifying objects in CSS style rules by tags can be extremely fragile. A more robust identification scheme is required for the real world. So if the "best practices" are wrong... what's the alternative?

Programmers have a set of best practices for naming variables, ie identifying information. It has spawned a small but growing movement in the HTML community called POSH (Plain Old Semantic HTML), and it is as revolutionary as it is simple. POSH agrees with the CSS designers that HTML should be light. However, that HTML must be Semantic. It must have meaning. In the POSH school, stripping out or ignoring important classes and ids to create lighter code is as abhorrent as using tables for layout. The purpose of HTML is to provide content and Structure. Creating a webpage with content but without structure is like trying to build a house with wood, but without a roof or walls.

POSH advocates for using the correct tool for the correct job; the tags, ids, and classes you use capture the semantic meaning of the content and require some thought. For a practical example, if a paragraph is an address, put a class="address" on it, so that computers, search engines, style sheets, and scripts can identify it as an address. If a div is your footer, put an id="footer" on it. If you don't, your HTML is not creating the structure which it needs to; it isn't identifying the important identities and relationships in your webpage. It's those identifications that you need to reference in your CSS too. So, if you have caption paragraphs after every image then certainly it makes sense to create a style rule like img p {...}, however when you want all addresses to look a certain way, you ought to style them with a rule like .address {...}. When you create a style rule ask "why" do you want to style what you're going to style and that tells you the important identification you need to use in your style rule. While this may seem like an extra step, I find it actually streamlines my work and lets me get more done. You no longer have to wonder how you "ought" to do something, just ask yourself how it should be identified, that structure defines how you write webpages and provides clear direction on how to mark up your pages. This quickly creates good HTML which you can style and restyle against without having to touch your webpage. That is a powerful concept you'll want to use in your own webpages.

So where can you go to find examples of this? You don't have to look far. Try www.CssZenGarden.com. That's right. www.CssZenGarden.com. Yes, I know, Dave Shea himself is an advocate for what I would consider "underdeveloped" HTML which lacks the semantic structure that it needs. However, look at his code. This is awesome, brilliantly semantic HTML. I know, Dave Sheas and others argue that CSS Zen Garden is overbuilt because it's a test site with a gimmick of taking multiple stylesheets; They say that's not meant to show how you code in the real world. Holy cow! Have you seen how they can restyle that website?? Without having to lay a finger on the HTML?? That's what I want my webpages to be able to do! When I need to restyle my websites from scratch, I want to be able to put together some images in Photoshop and recode the stylesheet and be done. Finished. Just like CSS Zen Garden. If that's overbuilt bring it on! Except it's Not overbuilt. It's beautiful HTML that is light and semantic.

Now that's beautiful web design.

Skip to Main Points

CSS Zen Garden Tips

So I've been singing their praises, so OK, seriously what can we learn from them...

Think About Your Images and How You Use Them - They Are Important

There are two ways to add an image: the <img> tag and background property in CSS. It does make a difference. CSS Zen Garden has no image tags. When you consider their experiment it's clear why. For their very particular website, if they included an image... any image, it would be an element that every designer would have to incorporate into their design. Therefore, the website was constructed without a single image tag. Do you miss them?? Take a look at the amazing and beautiful effects they achieve using only CSS background images. It's nothing short of amazing. The lesson for the rest of the internet is simple... You never need to use an <img> tag. It's completely unnecessary with the power of CSS.

Did you hear me right? Never use an <img> tag? Well, that's not quite what I said. I said you never need to. If you want to beautify your website, CSS Zen Garden shows you how to do that without a single image tag. By applying background images to your elements you can go a long way. And when you hit a wall? Well, take a page from Dave Shea's book, cheat. CSS Zen Garden has a set of six divs with the id "extraDiv" 1-6 built in. This is brilliant! You have what passes for six image tags that you can style and position at will anywhere on the page. You probably won't need them all, but they are a great way to avoid <img> tags in your website design. So maybe you add an <img> tag, but you also have another tool in your web developing toolbox, these "fake" image tags.

So when should you use which? What's the best practices? Here's the question I ask. When I was learning accessible web design, I was told to include a descriptive alt attribute to all images that added to the content of the page, and any image which did not, set the alt attribute to "", empty. That way accessible devices will ignore them. Well, if it doesn't add to the content you're trying to convey, why not stick it in the stylesheet instead. Which means you should absolutely use <img> tags, but only when the image provides information / content that you want to use in the page. If not, add the image using the background property of CSS.

Spans Rock

OK, I'd never thought about this much. I'd used spans for what I think most people did, an inline level element to mark up text as opposed to block level elements like divs. Well, since Dave Shea got his hands on an article by Douglas Bowman on www.StopDesign.com it's not your grandma's span tag anymore. Douglas Bowman established the world's best technique for replacing text with images. It's unparalleled; not just because it's so effective and works beautifully, but it's so simple. Identify the element in a style rule, and apply a background image that replaces the text, then you target the span inside it and set it to display:none which vanishes the original text, leaving only the image. Yet, the HTML has no <img> tags running around getting in the way, and all the information is present in text form for accessible technologies. As far as those devices are concerned there aren't even any images because all the "magic" is in the stylesheet; all that's there is text and the text is all there. This is elegant, SEO-friendly, and highly accessible.

Now this is an area where CSS Zen Garden is a little overbuilt. In a normal webpage you don't need a span tag nested inside every single element. In order to give designers maximum flexibility with this template, Dave Shea put spans everywhere. However, if you have anything on multiple web pages, then just like CSS Zen Garden, it might not be a bad idea to include a span on those items in case you need to do an image replacement down the road in some future redesign. In most cases, it's not that hard to go back in our sites if it turns out we change our mind later. If it would be, then be proactive about adding the span just like CSS Zen Garden.

So is that all you can do with spans? Not hardly. Here's another cool trick. Background images are limited. Any element just about, can take a background image, however it can only take one. If you apply a second background image to an element, it cascades and the second image eliminates the first. Well, spans can help with that. If you nest a span tag inside the element that gives you a second targetable element to apply a background image to. So while you can still only apply one image to your <h2> element, you can also target the span inside it doubling how many background images you can use. Pretty slick.

Skip to Main Points

XHTML Best Practices

Is that really a <span>?

<span> tags are cool because they let you highlight important sections of text for styling. They are the bridge between "normal" text and the special bits you're going to apply CSS to.

But Wait!

Is that really a case for a <span> tag? There are dozens of inline tags in HTML, and <span> is the all-purpose jack-of-all-trades tag, so it's very handy and important. Also, there's some trepidation about using these tags. There's a major movement in the CSS community to do away with many of the alternative inline tags. An HTML element like <b> bolds text; but that is what CSS, not HTML, is supposed to be doing. This has caused a lot of people, including myself to shy away from any inline tag except span which is offered as the "right" way to do things. However, there are many inline tags which are perfectly valid and perfectly semantic, most importantly <em> and <strong>. So the next time you go to add a <span> tag, ask yourself why? Would one of the other inline styles be more appropriate? You can do the exact same CSS with a <strong> tag as you can with a <span>, apply classes, restyle, etc. Using the most appropriate tag has a major accessibility and SEO advantage; if your page renders without CSS, the device or bot can still derive the reason this information is different (e.g. it's for emphasis, it's an acronym, etc.) rather than just that it is different which is all a <span> can communicate. It may also preserve some minimal styling even without the stylesheet as <em> typically renders in italics by default and <strong> renders in bold. Here's a list of appropriate inline HTML elements which you can feel comfortable using, and if none of them fit, absolutely use <span>. That's what it's there for, to mark up text when no other element is semantically appropriate.

  • <em> - text to emphasize
  • <strong> - text to strongly emphasize
  • <abbr> - an abbreviation
  • <cite> - a citation from another source
  • <code> - a piece of computer code
  • <a> - a link (easy to forget, but it's another inline element)
Skip to Main Points
<-- Back to CSS / Design Play
Continue to 2. CSS Block / Inline Styles -->
<---- Jump back to CSS / Design Play