Search

Improving Your Process: CSS Techniques Part 1

Posted: February 26, 2007 Comments(24)

This article is the first of an upcoming series that will be scattered throughout the life of Monday By Noon. The posts will attempt to provide some tips and tricks as far as design and development is concerned. The contents are purely my opinion, and take into account what helps me do my job.

Improve your document styling process

This first group of tips revolves around some CSS techniques I find myself using constantly. I’m sure you’ve heard of some, if not all, but hopefully something comes across as new and possibly helpful. This list consists of just a few ideas I keep in mind while developing, and there are more to come in future articles.

Try to control browser defaults

Each and every one of my style sheets begins with:

* { margin:0; padding:0; border:0; }

It’s a simple technique that many designers/developers use to ensure that no strange browser defaults are added to the design. It allows you to work from a common starting point and I find it very helpful to use.

When possible, avoid Box model inconsistencies

The Box model seems to be the root of many frustrations for upcoming designers/developers. Various user agents misinterpret the standard Box model, causing large amounts of structural style headaches. The Box Model Hack became popular as a way to avoid rendering issues when dealing with Box model inconsistencies. I admired the hack for it’s ingenuity from the first time I came upon it, and used it for some time. It was early in my process of discovering CSS, and turned out to be one of the smaller curve balls various browsers threw at me. As time went on, it was one of the many hacks I had adopted to use. There had to be a better way.

From then on, I elected to stay away from using a hack, and instead write my CSS in a way which avoided any associated problems. Basically it consisted of never applying margins and/or padding when a width or height was defined. Naturally I would want to achieve the same effect of having a functional box model, which required piecing together various widths, heights, margins and padding using each element available. For example:

#sidebar { width:200px; float:right; padding:10px 15px; }

Could instead be written as:

#sidebar { width:200px; float:right; }
#sidebar ul { padding:10px 15px; }

Applying the padding to the unordered list as opposed to #sidebar avoids any related headaches you could run into when testing cross browser. The success of using this technique will vary from case to case, and it’s very important not to let things get out of hand. Trying to avoid Box model issues will make it very tempting to give something an extra wrapper div, or insert another element for the single sake of helping your CSS. It’s important that your markup remains semantic.

Comment your style sheets properly

As with any programming or markup, it’s important to keep your style sheet well documented (especially if the project is collaborative). I find that labeling sections of the style sheet works very well, but from time to time it helps to write down a quick note just as a reminder if not for anything else.

Organize your style sheets by section

I find it really helpful to organize my style sheets by section. It may seem like common sense to do so, but sometimes new designers/developers will append things towards the end of their style sheet and work in a slightly random fashion. Not only will that make maintenance very difficult, it’s very likely you’ll re-declare properties on selectors which can bloat your CSS significantly.

Use a color glossary

Just about every client project I work on involves a significant probability that a co-worker will need to review the CSS for the site either as a reference, or to make an adjustment. Along with keeping the styles properly organized and documented, I’ve found that it really helps to include a color glossary at the top of any style sheet in order to not only make it easier on other designers, but also ensure that colors remain constant throughout the site.

Name only that which needs naming

Your naming convention is very important in both the longevity of a document as well as its organization. It’s important that a happy medium is found in the frequency of class and id given to various elements throughout the design. Having too few will result in an ineffective style sheet, while having too many will result in degraded readability as well as bloated markup. Naming parent elements with an appropriate class and/or id can often remove the need for specifically identifying any children.

While monitoring the frequency of class and id, it’s also very important to use meaningful identifiers. A meaningful identifier will describe what is being named. Giving a div id="sidebar" is much more meaningful than giving a heading class="red". If the design were updated, and that heading is no longer red, the class you gave it is completely worthless, not to mention it wasn’t very helpful to begin with. Don’t name your elements based on their visual representation, give meaningful identifiers to your id and class.

Begin with a static file, and then port to your template

Turning your design into a template can speed development exponentially. On the other hand, I’ve found that working with a static file initially also helps to speed up my process. Part of my process involves writing all of the XHTML before starting the CSS. I’ll put together a static file containing all of the site markup, and from there, piece together the CSS. After that, the functional design is ported to the template and the project continues down our development checklist. Doing all of the initial work inside a single static file is much faster than working in headers, footers, and trying to put your template together at the same time.

Don’t stop reading

I’m constantly hearing designers and developers ask whether or not it even makes sense to read or write about what can be accomplished with CSS. It’s really disappointing because that thought process leads to a stagnant industry. It may seem like everything has come and gone and the full extent of CSS has reached saturation, but it’s important not to write anything off. Changes will continue to be made, and innovators will continue to document their findings for a long time to come. Thinking that everything has been discovered will do nothing but hinder your skill set.

How do you improve your styling process?

Again, this is just a small list of a few things that I feel could be really helpful to those designers/developers who may not have read about them before. I’m a firm believer in that the Web is constantly changing, that there could be an even better way of doing something. It would be great to get some feedback from everyone regarding their favorite tips, tricks, and techniques as far as styling is concerned.

Related Content

  1. Improving Your Process: CSS Techniques Part 2
  2. Improving Your Process: Thinking More About Your CSS
  3. CSS Organization Methods and Writing Style

Categories

Categories Design, Development, Opinion, Process

Tags

Tags , , , , , , , ,

Get my newsletter

Receive periodic updates right in the mail!

  • This field is for validation purposes and should be left unchanged.

Comments

  1. Great article dude, but I would advise against using * { margin:0; padding:0; border:0; } as it can be really heavy on the rendering engine if it has to restyle *every* element on the page, I find it’s much better to have a default list of things that need the padding and margins removed. Some stuff needs the margin and padding, otherwise you have to go about adding it back to the elements that need it and that just makes your css file bigger!.

  4. I don’t know if it makes that much difference if you use * { margin:0; padding:0; border:0; } or the css resetter from Andrew’s comment. The list of elements de-margined and de-paddinged (or something) looks rather big. Of course it could be faster that using the arterisk, especially on big websites, but I think even a Pentium II processor could render both the styles at about the same speed. I think it’ll have more problems with rendering images on a website. I say: we need benchmarks!

  5. I personally nullify margins and paddings but I don’t think it’s a very good idea to remove default borders from all elements. This will remove the styling of form inputs, including buttons’ rounded corners. Apparently this will be unwanted if one does not intend to style form control. I’d rather use:

    fieldset,img{border:0}

    Regards.

  8. Great list. One of the things I learned in my first web design job (a co-op position) is that you will not always be the person maintaining this site/template/design/css file/script/whatever. So make sure that other people understand what you’re doing. (and that “other” person could be yourself 3 years from now!)

    When it comes to CSS, another suggestion would be to use established names for parts of the layout (#header, #footer, #sidebar etc.) rather than making up your own. And make sure class names are readable and understandable by other people. Too-short abbreviations is something I’ve come across in the past as well.

  10. Great topic. I re-read “CSS Definitive Guide” and “CSS Cookbook”. I’m working through “Transcending CSS”. I was wondering how far to take the default setup. I have seen the Universal selector, “*”, used. But then I have seen developers not use the “*” because of specificity (no child will inherit from its parent), and resort to listing each block tag. Not only setting margin and padding, but also establishing a base font-size and line-height.

  11. I am putting together a similar list, which includes being consistent on the order I specify CSS properties on any element. It just helps me visualize the positioning and the box model, including the inline box and line box. Regarding the box model and not using margin/padding with width/height, would it make a difference if you said, when using margins always have a border even if it is transparent? I use Firebug to watch the box model and it can get really interesting sometimes. Are developers doing a lot of pixel counting to ensure margins + borders + paddings + content_width = parent_content_size?

  12. @MikePearce: You bring up a good point, but it’s very rare that I’ll want the default padding or margin applied to any particular element. I can understand your concern about the rendering engine having to apply the style to each and every element, but once the style sheet is downloaded, the CSS is applied in the blink of an eye.

    @George: Awesome — I’m always interested to read into various processes and take into account whether or not it can help me out.

    @Andrew: Yeah, the YUI CSS is definitely an option, but adds another request to the bill, which is more expensive than using a universal selector. Thanks for the tip!

    @Rommert: You’re right, it would definitely be interesting to benchmark the difference between the two techniques.

    @Dimo: You bring up a really great point, I only recently added border:0; to the list because each project required some pretty custom forms as it was. Before that I was only using margin:0; padding:0; by themselves.

    @Megan: Yes definitely. I can remember some of the names I have come up with in the past, and revisiting them later really led me to ask what I was thinking back then. Meaningful identifiers can be so helpful both when reading the markup and style.

    @Sunny: The Box model can sometimes get extremely tricky for people. Complex layouts can become confusing quickly, so I try to write my style so that it embraces the Box model, but doesn’t push it to the limit. Given the fact that I still feel it’s important to support IE6 (for the time being), relying on a consistent Box model is just out of the question.

    Thanks for all the great responses. I’m sorry it took me so long to get back to everyone, the past couple days have just flown by.

  13. Wouldn’t you make your customer dependent on Yahoo if you used the link rel YUI CSS? What if they change something, are down, or slowed for some reason. You have no control, when, how. That doesn’t seem like such a good idea.

  14. I tried splitting up my CSS files into layout/typography/colors/etc., but I found it too time consuming to be flipping back and forth between files as I coded. I prefer to keep everything in one well-commented file. Love the color glossary idea–I’m going to use that from now on.

  15. @Brian: I could never work productively when splitting my CSS into separate files for typography, layout, colors, etc. It just didn’t make sense to me. To change the appearance of a single element, it’s very likely you’ll have to open up two (or three!) files just to make the change.

  20. @Paul – Design Mancester: There are a number of ways I’ve seen people comment their CSS. At the end of the day it comes down to what’s most useful to you.

    One thing I’ve seen from time to time is using a specific syntax (that you’ve come up with yourself) for finding particular areas of your stylesheet, i.e.:

    /* !footer */

    That way, after using your own namespaces, you’re able to use the exclamation point as a bit of a flag for the top of a section in your CSS. You could use various characters to outline various sections of CSS based on your needs.

    Other types of commenting that I’ve used include blatant attention-getting, such as:

    /* --------------------------------------------------------

    SIDEBAR

    -------------------------------------------------------- */

    Using comments such as these can help you to section your CSS to easily find a particular area when scrolling through the stylesheet.

    Sometimes, it’s helpful to include some notes as reminders, especially if you use conditional comments. It can help to jot down a note reminding you that this particular element has ties with another IE-specific stylesheet.

    I hope you find these notes helpful, but please be sure to inquire if you have any further questions, or if I’ve interpreted your request incorrectly. Thanks for taking the time to comment!

  21. Johnathan, I like the header comments like this:
    /*
    Theme Name:
    Theme URI:
    Description:
    Version:
    Author:
    Author URI:
    */

    I agree with you that it is better to avoid IE bugs than use hacks.

Leave a Reply

Your email address will not be published. Required fields are marked *