Advertise here with BSA

Structural naming convention – in essence – just means that you name (by assigning a class and/or id attribute to them) elements by describing what they are, and not where they are or how the look.  Its counterpart is called presentational naming which describes the location and/or appearance of web page elements.

This CSS tip discusses the concept of structural naming conventions, the benefits of using this convention, and shares some guidelines on practical applications of structural naming conventions.

Let’s start with a presentational naming example

To illustrate by way of example, take a look at Example 1 which uses a presentational naming convention.

Example 1: A presentational layout.

What’s wrong about the layout?

There are two major fundamental flaws in using a naming convention such as shown in Example 1.

First, it makes it hard to move things around without affecting the accuracy of your markup.

Although the #top-div and #bottom-div will most likely stay in place, a design decision to put the secondary content (#right-col) to the right of the main content area (#left-col) completely invalidates the document’s model.

Secondly, the names don’t help describe what the elements are – what they’re for and what they do as part of the overall document.

For example, the link with the class .red-link in Example 1 describes the color of the link, but not what it’s for.

A realistic example

Let’s pretend I hired a new developer in my team – let’s call him Dave Newbie. I’ve given Dave the task of updating a website that uses a presentational naming convention instead of a structural naming convention.

The site’s CSS is much like Example 1, but instead of only 13 lines of declarations, it’s 500 lines (single-spaced, single-lined, shorthand notation).

I didn’t give Dave any other instructions besides updating the pages and assigning elements the appropriate class or id (I didn’t comment my code, because remember – I like to do things the hard way).

In a web page Dave was tasked to update, he encounters a special class of links with the name .red-link (as shown in Example 1).

Now he’s scratching his head wondering why these guys have a class of .red-link…

What if instead of .red-link, I named it .external-link?

Dave would know instantly (and if he doesn’t – then I’d have to reconsider his employment) that any links that point to another website gets assigned a link of .red-link.

And that’s the practical reason for choosing a structural naming convention instead of a presentational naming convention – if not for semantics and best practices – then for helping Dave Newbie know what particular classes and ids mean, not what they look like or where they are (which he can already see anyways – granted that he doesn’t suffer from dyslexia or particular forms of color-blindness).

Let’s rework Example 1 to reflect a (sort of) structural naming convention.

Example 2: A structural naming convention.

In Example 2, I’ve renamed the classes and ids to structurally-descriptive names.

#top-div has become #header, #left-col (short for left column) has been renamed to #main-content, and so on. That’s much better and more intuitive.

Wait a minute!

After looking at the example, some of you may be saying “Wait a minute Jacob, aren’t #header and #footer presentational descriptors?” -  some might even modify this question with an abbreviated explicitive and exclamation point like “…WTF!”, and some may go further with “WTF n00b!!”.

Yes, indeed you’re (mostly) right.

But now I ask you this: without any additional information – what does #header and #footer mean to you?

Some of the responses might be:

#header is for…

• logo/branding
• where your primary navigation is
• where the tagline of your website is, etc.

#footer is for…

• Copyright information
• a repeat of important page links
• auxiliary information or additional site features

Without telling you (or Dave Newbie for that matter), what they mean to me, you already know what they are for and what they probably mean.

That’s because names such as #header, #footer, and #sidebar are well-established.

In a survey of websites of some web professionals, Andy Clarke lists the naming convention used for the structure of these sites, check it out here.

You can see in Andy Clarke’s survey that #header and #footer are staples, and are used the majority of time. So they’re instantly recognizable.

We can follow a structural naming convention blindly by instead using #branding for #header and #siteinfo for #footer – but at the end of the day, I chose to bend the “rules” for the purpose of practicality.

#header and #footer still describe the purpose and the structure of those particular elements in the document, exactly like #branding and #siteinfo does.

In short, Dave Newbie won’t be knocking on my door at 3:00AM in the morning asking me what #branding means so that he can meet his deadline (and Dave, please call or text next time, don’t just show up in my front door steps).

But for those who are unwilling to compromise, let’s rework Example 2 to a strictly structurally-named example.

Example 3: Really using structural naming conventions.

Example 3 is fully-structural in naming convention. It describes what the div’s and other elements are for, instead of where they are or how they look. I’ve used Andy Clarke’s suggestions in an article he wrote a ways back.

A few guidelines

Here are a few guidelines to help you name your elements structurally, and these are just that – guidelines. In the end, you have to use what’s best for you and the project at hand.

1. When assigning a class or id, ask yourself “What is this element for?”

For example, if you have a span class that’s meant for captions, you might call it .caption or .figure-caption instead of .smaller-text.

If a particular group of images are banner advertisements, you might want to call the class .banner or .ad-banner instead of .sidebar-images (since they may change locations).

2. Avoid using names that rely on locational or visual aspects of the particular element

In Example 1, we used .red-link for links that are red, and #left-col for the column on the left.

Later on, in Example 2 and Example 3, we changed them to .external-link and .main-content.

The practical reason for doing this is that it keeps your HTML markup accurate even if – say – you change the style of the .red-link class to green or brown.

Of course you can always do a batch find-and-replace if you have a static site, hunting down .red-link and replacing them with .blue-link in all of your affected HTML documents, but why rely on that when you can avoid it in the first place with a little forethought.

It also keeps your code (code is used literally here, not to imply that CSS or HTML is programming – which they aren’t) semantic.

You don’t have to change .red-link in the markup even when you’ve changed the value of the color attribute in the stylesheet, but it would be semantically inaccurate in describing that particular element.

For example, even if it’s called .red-link and you changed your style declaration to:

a.red-link { color:  blue;  }

a elements with the class .red-link will be rendered as blue despite of their class name (at least in most browsers).

But wouldn’t that be irritating? I know I wouldn’t be able to sleep at night knowing that my .red-link‘s are being rendered as blue.

And wouldn’t that be confusing to Dave Newbie, the new member of my development team?

If instead of .red-link or .blue-link, I used .external-link, then it wouldn’t matter if it’s red, green, blue, or black – it’ll be accurate as long as I do indeed use them for external links.

3. Use names that are intuitive to you

Earlier, in Example 2, I used #header instead of #branding. The reason is because I feel that #header is more recognizable than #branding. Notice that even though it can be interpreted as a locational description – I still used it.

I decided to do what’s best for me and what I think is best for the people that might be working on the same project. I bent the “rules” (notice that rules are in quotes because these are more like guidelines, not the law of the land) – so to speak – for the purpose of practicality and general intuitiveness.

Here’s a good guideline for naming classes and id’s intuitively.

Ask yourself, “If I asked Dave Newbie what this class (or id) is for, would he automatically know?”

That’s programming 101, naming variables intuitively so that other programmers will know what the variable holds ($total instead of $t) – and that lesson is applicable to CSS naming conventions.

Further reading

The concept of structural naming isn’t new, and there have been wide discussions about the concept. Here, I’d like to share a few resources on the topic to help you further explore the concept.

Structural Naming

In a short post, Eric Meyer discusses his viewpoints on class and id naming conventions, mentioning Andy Clarke’s viewpoint on the matter.

Standardizing CSS class and id names

Michael Meadhra discusses presentational naming conventions and structural naming conventions.

Build for the Future: Bend, Don’t Break

Garret Dimon discusses the foundations of creating a flexible and adaptable website that’s always prepared for changes in the future. He also mentions how HTML markup is the foundation of a website, citing names like left_bar can quickly be outdated in a design change.

About the CSS Tips series

The CSS Tips series is a group of articles on Six Revisions that focus on a particular CSS tip, concept, or best practice. In each article, I’ll deconstruct a particular tip/standard/best practice and provide the context, benefits, and disadvantages of each.

I believe in learning both theory and practice, as well as striking a balance between strict, uncompromising standards and practicality, so you’ll get a chance to learn the way people generally do it, and why you shouldn’t necessarily follow them blindly.

I’ll present each CSS tip as comprehensively as I can, but I depend on you to correct me if I’m wrong, expound on things I skimmed over, clarify things that may be confusing to our fellow beginning developers, and provide your own input on the subject – so I highly encourage you to contribute in the comments.

To see all the CSS Tips articles thus far, you can go to the CSS category.

Related content

• Innovative (and Experimental) CSS Examples and Techniques
• 8 CSS Techniques for Charting Data
• 20 Websites To Help You Learn and Master CSS
• Web-Based Tools for Optimizing, Formatting and Checking CSS
• 30 Exceptional CSS Techniques and Examples

Advertise here with BSA

This is the first part of a series of articles that will discuss a particular CSS best practice or tip. I’ll be covering a mixture of topics that deals with CSS best practices, performance optimization, and tips and tricks to improve your workflow.

Today we’ll be covering the topic of resetting your styles.

Resetting your styles, commonly referred to as CSS Reset or Reset CSS is the process of resetting (or more accurately – setting) the styles of all elements to a baseline value so that you avoid cross-browser differences due to their built-in default style settings. By resetting your styles, you avoid defaulting to the browser’s built-in styles, which differs from browser to browser.

CSS Reset avoids browser inconsistencies

For example, say you use an anchor tag <a> in your HTML document. Usually, browsers like Internet Explorer and Firefox will render it as blue and underlined.

But five years from now, someone decides to release a new browser (let’s call it UltraBrowser) and they decide that they don’t like blue, underlined links – so instead they set the default style of <a> tags to red and boldfaced. If you always set a baseline value for your <a> elements, then you’re guaranteed that it will always be the same, regardless of what UltraBrowser thinks <a> elements should look like.

A simple example

Example 1: How paragraph tags are rendered by default.

In Example 1, I’ve placed three unstyled paragraphs <p> inside a container <div> (I gave the container div a blue background and orange border to highlight the difference).

By default, in Firefox, you’ll see that there’s a space in between the top of the first paragraph and the top of the container div, and a space between the bottom of the last paragraph and the bottom of the container div.

By default, these spaces don’t exist in Internet Explorer.

So which browser is right, Firefox or IE? It doesn’t matter. What does matter is that the spacing in between your paragraphs and other elements will look dissimilar if you don’t set a style for a paragraph’s margin and padding.

Of course that’s a rather simplified example. In practice, CSS Reset is important in removing inconsistent margins, paddings, line-heights, and other attributes that can cause your web pages to look differently across various browsers.

So that’s the basic theory of resetting your styles which just means you set your style rules for all elements to avoid having the browser do it for you. Further down, we’ll talk about it in practice, but first a little bit of history on how CSS Reset became a standard practice for modern web developers.

A reset to where it all started…

The concept of CSS Reset was first discussed formally way back when dinosaurs still roamed the internet (2004 to be exact) by Andrew Krespanis. In his article, he suggests using the universal selector (*) at the beginning of your CSS file to select all elements and give them 0 values for margin and padding, like so:

* {
  margin: 0;
  padding: 0;
}

The universal selector acts like a wildcard search, similar to regular expression matching in programming. Since in this case, the * isn’t preceded by another selector, all elements (in theory – some browsers don’t fully support it) is a match and therefore all margins and paddings of all elements are removed (so we avoid the spacing differences shown in Example 1).

Applying the universal selector margin/padding reset to our earlier example, we now remove all inconsistent spacing between all browsers (in other words, we don’t make the browsers think for us, we show them who’s boss).

Example 2: Applying the universal selector margin/padding reset

But now we don’t have any spacing in between paragraphs, so somewhere below our universal selector reset, we’ll declare the way we want our paragraphs to look like. You can do it a number of ways – you can put margins (or padding) at the beginning or top of your paragraphs, or both. You can use ems as your units or pixels or percentages.

What’s important is that we choose the way the browser will render it. For our example, I chose to add margins (instead of padding) both at the top of the paragraphs and at the bottom – but that’s my choice, you may want to do it differently.

Here’s what I used:

* { margin:0; padding:0; }
p { margin:5px 0 10px 0; }

Example 3: Declaring a style rule after the universal selector.

Note: The example I used for discussion is a simplified example. If you only used paragraphs for your web pages and no other elements, you wouldn’t want to reset your margins to 0 using the universal selector only to declare a style rule right after it for your paragraph. We’ll discuss this more fully along with other best practices later on down the page.

Shortly thereafter – CSS guru Eric Meyer further built on the concept of resetting margins and paddings. In Eric Meyer’s exploration, he discusses Tanek’s work undoing default HTML styles (which he called undohtml.css) which not only resets margins and padding, but also other attributes like line-heights, font styles, and list styles (some browsers use different bullets for unordered list items).

After many iterations and refinements, we come to a wonderful solution called CSS Reset Reloaded CSS Reset, which not only makes this CSS reset method more accurate than the universal selector method by using higher specificity by naming all possible HTML tags (because the universal selector fails to apply the reset to all HTML tags), but also sets default values for troublesome elements like tables (in which the border-collapse attribute isn’t rendered consistently across browsers).

Of course, there are other methods of resetting your CSS (such as Yahoo!’s YUI Reset CSS which I currently use on Six Revisions), and you can roll your own based on your preference and project needs.

Now let’s go through some tips and best practices when applying a CSS Reset solution to  your own projects.

Applying CSS Reset: tips and best practices

1. Start by deciding exactly how you’ll reset your styles

Above, I’ve shown you the two extremes of CSS Reset. From a sweet and simple method using the universal selector (which I don’t recommend you using) to a more involved and complex method with Eric Meyer’s CSS Reset Reloaded (edit: or the more current version, Reset CSS).

I also briefly mentioned the YUI Reset CSS which you can use directly off the YDN so that you don’t have to serve it, saving you some server resources when your web pages are requested. You can also roll your own and tailor it to your specific needs.

There’s no pre-defined step-by-step method for determining the right way of resetting your styles; the important part is that it works to compliment your own development style and principles.

To help you make your choice, here are a couple of excellent resources to get you started:

• A Killer Collection of Global CSS Reset Styles
• Less is more – my choice of Reset CSS (by Ed Elliot)

2. Your CSS Reset has to be the first thing the browser sees (duh).

Resetting your styles after declaring a style rule for an element will mess you up. You’ll scratch your head wondering why the margins you declared for .some-class isn’t working. Therefore it’s essential that the first thing the browser sees is your CSS Reset.

Laugh now, but it’s a common mistake amongst rusty veterans and beginning developers.

Note: In case you fall into the “people-prone-to-this-common-mistake” category, here’s the reason why it has to be at the very top of your CSS document/s: CSS works on a top-down hierarchy with rules lower down the CSS document taking precedence if there’s a conflicting/redundant style rule declaration.

Just to continue beating a dead horse, let’s explore an example. I used Eric Meyer’s CSS Reset Reloaded verbatim in the example after declaring a style rule for the margin of my <p> elements.

Example 4: Putting your CSS Reset in the wrong place

I have the style rules at the examples’ HTML document (for convenience), so that you can view the source and see what I mean.

In essence, what you see is that even though I declared margins for my <p> elements, my CSS Reset “reset” them to 0 because it takes precedence over my initial style rule declaration.

3. Have a separate CSS document for your CSS Reset

I have to mention this tip because it’s common practice and one that many people advocate.

I’m on the One Big CSS File (of course it varies on a case-by-case basis) camp for page performance reasons (I’ll save this discussion for another day, perhaps on another CSS Tip article), but a common practice is to have a separate CSS document (named something like reset.css) that you can reuse throughout your projects. This helps you keep your style rules organized and modular, but more importantly, it makes it easier to change and tweak your CSS Reset without having to go back to your old projects and updating it.

4. Avoid using the universal selector reset

The universal selector reset is the first true conception (that I know of at least, so please correct me if I’m wrong) of resetting your styles, but it has many shortcomings and browser inconsistencies (which is what we’re trying to get rid of in the first place) that make it a poor choice.

I’ve already mentioned that IE doesn’t apply and support it as intended; it doesn’t cover all your bases and you should only use it for simple, short, static, and predictable web pages (if you really have to use it).

This tip especially holds true when you distribute a “one-size-fits-all” solution like a content management system theme which will be used and hacked in unpredictable ways. Using a solid foundation at the get-go – an extensive CSS Reset method – ensures that you’re truly resetting your styles and it’s worth the added bytes in your CSS document.

5. Avoid redundancy with your CSS Reset and subsequent style declarations

Another reason I don’t like having a separate stylesheet for my CSS Reset is that it can cause redundancies with other style rules after it. It’s good practice not to repeat your styles, and although sometimes it can’t be avoided (because you’re lazy like me), you should make an effort to try. Going back to Eric Meyer’s CSS Reset Reloaded set of rules, he gives default values for line-height, color, and background of the body element like so:

body {
  line-height: 1;
  color: black;
  background: white;
  }

If you already know that the body style attributes will be (for example):

• background-color: #cccccc
• color: #996633
• and you want to tile a background image horizontally

there’s no sense declaring another CSS selector for the body element later on the document – you should replace that part of your CSS reset to the following:

body {
  line-height: 1;

  color: #996633

  background:#ccc url(your-tiled-image.gif) repeat-x top left;
  }

Don’t be afraid to use your own judgment. Tweak, re-structure, delete, and add things as you see fit and as it pertains to your particular case.

Eric Meyer echoes this in his discussion of CSS Reset Reloaded with the following statement:

[…] That’s much of the point here: that this is not a case of “everyone must use these styles in a certain way without alteration”.

Further Reading

Here are a few excellent resources that I recommend you read on the topic of resetting your styles.

[WSG] Zeroing default padding/margin

Probably one of the first threads that discuss the universal selector reset on the Web Standards Group mailing list.

Universal Selector

Eric Meyer discusses how the universal selector works.

No CSS Reset

Johnathan Snook discusses why he doesn’t reset his styles; a great counter-argument from one of the most respected web developers/designers out there.

Why I Like (and Use) Reset CSS

A short and sweet discussion of why resetting CSS is a great idea.

Tripoli – a CSS standard for HTML rendering

Tripoli is another popular CSS Reset option that has several versions so that you can use the one most appropriate for your project.

About the CSS Tips series

The CSS Tips series is a group of articles that focus on one particular CSS tip or best practice. In each article, I’ll deconstruct a particular tip/standard/best practice and provide the context, benefits, and disadvantages of each.

I believe in learning both theory and practice, as well as striking a balance between strict, uncompromising standards and practicality, so you’ll get a chance to learn the way people generally do it, and why you shouldn’t necessarily follow them blindly.

I’ll present each CSS tip as comprehensively as I can but I depend on you to correct me if I’m wrong, expound on things I skimmed over, clarify things that may be confusing to our fellow beginning developers, and provide your own input on the subject – so I highly encourage you to contribute in the comments.

To see all the CSS Tips articles thus far, you can go to the CSS category.