Browsing articles tagged with "code organization Archives |"

CSS Continued… Part 1:Organization Boot Camp

Keep it Together Man!

Always keep your styles in external style sheets when possible.
Inline styles, while they seem handy when you just need to make a quick update, will spell trouble in the future when you need to make full design changes. They also make troubleshooting that much more difficult since you have to remember everywhere you’ve put styles.

Use multiple stylesheets whenever handy.
Don’t be afraid to break your styles out as you see fit. While importing additional style sheets can cause additional server load, the benefit is far greater to break out these styles by relevance. So for instance, you might have reset.css, screen.css, print.css and ie.css all for one project.

Use comments, quick colors and tables of contents.
Make sure to comment all of your css style sheets, if you feel so inclined you can add a bookmark type symbol such as an equals (=) sign. The equals sign is a good symbol to pick since it never occurs in css styles regularly. Then add it to your section comments like so:

/* --------------------------- =header ----------------------------------*/

This allows you to do a find on your document so you can quickly jump from section to section. To make this tip even handier, add a table of contents to your document like so:


You can also use the top of your document to reference color codes you use quite regularly throughout your document to help you remember.

Body Background: #2f2c22
Main Text: #b3a576
Links: #9c6d25
Dark Brown Border: #222019
Green Headline: #958944

Thanks to Jina Bolton for all these handy commenting/bookmarking suggestions.

Use consistent organization.
When laying out your stylesheets and styles themselves, try to keep consistent organization project by project, sheet by sheet, style by style. If you work in a larger company, you may want to sit down as a team and discuss how everyone would like to standardize their organization, that way everyone will have the same method to the madness. How you organize your styles is really up to you ultimately, but there are several ways that are common among front end architects.

Sheet Naming and Breakout
Most use the following breakout for their sheets:

  • reset.css,holds the Eric Meyer CSS reset or some variety of it
  • default.css or screen.css, holds all the screen styles, this sheet can also be broken out into the following if you prefer:
    • layout.css, holds all the layout styles
    • typography.css, holds all the typography styles
  • print.css, holds all the print styles
  • ie.css, specific ie style corrections to remain cross broswer compliant, see Conditional Comments on how to implement these

Again, these naming conventions and suggested breakout is just… a suggestion, you and your team can really decide what you want to call these and how many sheets you ultimately end up with. There may be situations in which you want to have a separate style sheet for each theme you use within a site, etc.

Remember the cascade when you import your style sheets, each time a new sheet is called the styles are overridden by the new style sheet if it’s included within. For instance, say you call your ie specific style sheet first, your element style has a width of 200px, and then you call your default.css sheet which has an element style of 205px, the element will pick up the last style it was told, which was 205px from the default, which is not what you want, you wanted the 200px from the ie specific style sheet.

ID vs. Class
I notice that most people who start learning CSS have a tendency to like to use classes more so than ids. When making the choice between using ID or a class, ask yourself one question, “Will this selector appear more than once on a page?” if the answer is yes, use a class, if it’s no, use an id.

Selector Breakout
After you figure out how you want to break your sheets out, take some time to consider how you are going to break out your styles within those sheets. Remember the cascade here too when you’re organizing, since the last style used will be the one the elements pick up. Here’s a sample of how some front end architects organize their styles within each sheet:

  • container styles and parent elements, such as body, wrapper, or containers
  • standard element styles, this includes HTML elements such as h1-h6, p, blockquote, etc
  • global styles, anything that will be used throughout the site such as mastheads, etc
  • section specific styles, anything that changes on a page by page basis

another example would be:

  • parent styles and containing elements, working outside in
  • block-level elements
  • inline level elements

After you layout your styles, you may want to get really picky and organize how each style call is called within a style set. After years of experience, some people just form a natural tenancy to call some styles before others, take for instance the way Jina Bolton does her calls per set:

  • positioning (with coordinates) styles
  • float/clear styles
  • display/visibility styles
  • spacing (margin, padding, border) styles
  • dimensions (width, height) styles
  • typography-related (line-height, color, etc.) styles
  • miscellaneous (list-style, cursors, etc.) styles

I have also personally formed a natural tenancy that goes something like:

  • positioning
  • float/clear
  • display/visibility
  • dimensions
  • margin/padding
  • borders
  • typography
  • misc.

Other front end architects prefer to go another route in hopes to make it easy for others to find things, alphabetically listing their style calls within their sets. At this level, organization might be too obsessive or asinine, but some people consider it helpful.

Also, I’ve noticed two ways of laying out your css sets, some front end architects choose to tab out their calls like this:

.cssSelector {
csscall: option;
csscall: option;

While others like to do it all in one line:

.cssSelector {csscall: option; csscall: option;}

Either is acceptable of course, but again, if you’re working in a team environment, you may want to standardize this so that everyone can read it easily. I personally opt for the all-in-one way since I like seeing how many lines of CSS I *didn’t* have to write to make something work.

Selector Naming
CSS selector naming is also very important. When naming selectors remember that your styles may change, so try not to name based on a item’s location within the layout or particular style attributes, such as color or size. Instead, try basing your selector name on the content it holds, Andy Clarke wrote up a great set of examples.

There is also some debate on whither to use camelCase or to separate using the dash (-). Honestly, either are acceptable. Again, perhaps this is something to discuss with your teammates.

So that’s it for this part of CSS Continued… was there something in here you didn’t quite agree with? Perhaps you want to share how you organize your sheets and selectors… leave a comment and we’ll get some sweet discussion going!

What is this?

This little blog happens to be the personal ramblings of one April Holle - I'm female, outspoken, webbie, a community evangelist, and Principal of Made Better Studio. Check out the about section for more info.

What People Are Saying…