Here at 55 Minutes, we spend a lot of time studying the latest and best practices in web design, constantly striving to improve our development process. Over the years of learning and experimentation, we’ve collected a set of best practices, conveniences and quick-starts that we use in our everyday work, and which we’ve distributed as a series of open source projects.
One of these, the cornerstone of all our projects, is our CSS3/HTML5 foundation. This quick-start contains all the (to our minds) necessary building blocks for static sites of applications:
- The best practices recommended by the 320 and Up boilerplate project, which center on using CSS3 media queries to provide resolution-specific styles. As the name suggests, the core styles are done according to the mobile first philosophy, with styles for higher resolutions layered on using progressive enhancement.
- A fluid, percentage-based layout, as recommended by the principles of responsive web design. This kind of layout more elegantly scales to browser environments of any size than a fixed-width layout.
- Sass and Compass, which are, respectively: an extension on—or rather, the evolution of—the CSS language, and a framework used to make writing Sass easier. See our previous post on the two to learn more.
- A style guide based on the Twitter bootstrap containing examples of the styles defined in the project. This also serves as a good regression test when altering styles; it should highlight unintended cascades and undesirable overrides of default styles.
In addition to incorporating these best practices and recommendations, we spent some time fine-tuning the code writing and organization process. Over the years, one of the biggest challenges our team has faced has been maintaining styles for large and growing projects. Sure, it’s not so bad when there’s just one HTML/CSS developer, but code organization that makes sense to the original author is not necessarily obvious to another developer who only needs to alter CSS piecemeal.
How could we organize the code in such a way that it’s intuitive to every developer, regardless of how often she touches the CSS, where to look for a style definition she needs to alter? After trying several different organization schemes, what we eventually agreed on is below.
We’ve copiously commented our code, so please refer to individual source files for detailed information on what should be included there. In the meantime, here are some general guidelines for file organization:
- styles/ contains the Sass source files. We use the SCSS syntax, since it is more accessible to CSS developers than the original Sass syntax.
- styles/basics/ contains the building blocks of our styles: the reset stylesheet and the Sass variables that define the colors, the typography and the grid.
- styles/shared/ contains application-wide styles like header, footer and form styles. Default styles for the basic HTML tags (
p, etc.) should also be included here.
- styles-compiled/ contains the compiled stylesheets, the CSS files that we will include in our markup.
- scripts/lib/ contains libraries like jQuery and Modernizr.
CSS rule organization
But file organization does not solve the problem entirely. A single CSS rule set can quickly grow large and unwieldy, so to promote ease of reading and maintenance, we recommend following a prescribed order for writing your CSS rules.
Some teams alphabetize all the rules, but I find that, though alphabetic sorting makes reading easier, it doesn’t suit the way I think when I’m authoring CSS. The way I prefer to work, and the way we organize rules in the CSS3 foundation, moves from the outside in, from layout to text:
It should have become clear by now, by the way, that our CSS coding standard is that the open brace is on a line by itself, and rules are also written one-per-line. There’s no reason to do multiple rules in one line when the Compass compiler can strip the whitespace for us through a configuration option.
Other best practices
Here are some other policies we follow/tools we use when writing our styles:
- Update May 9, 2012: We no longer recommend font sizing with rems, and have gone back to using pixels, for several reasons:
- Most of our layouts are uncomplicated, so adding IE7/8 support was a relatively simple matter if we switched back to using px sizing.
- We no longer assume that the default font size is 16px (which isn’t a guarantee in any case), so the layout is more forgiving of different user defaults.
- Pixels are just easier to understand.
- CSS sprites for icons and images with hover states
- The sassy-buttons gem to make button styling easier
- A workaround for the MobileSafari orientation-change zoom bug.
- When calculating a percentage for the fluid layout based on desired pixel sizes, round the resulting number down to 3 decimal places. More than that is just hard to read.
- Even when adding markup that is solely for presentational purposes (sadly, that is still a necessity), we still use semantic markup (
b, even though the latter is shorter to write).
How this all fits into our design process
The coding conventions and best practices I’ve defined above are just part of our design process. Here’s a rough outline of how we typically work the design and early UI-development phases:
- The designer creates a set of fixed-resolution mockups for the various parts of the site or application.
- The designer creates a library file containing the UI conventions and color palette to pass on to the developer.
- When the design is considered polished to a sufficient degree, the developer begins work by translating the library file into the shared components of the project, e.g.
- The developer takes the fixed-resolution mockups and makes them fluid. If the layout is too complex to quickly translate to code, the designer is brought in again to simplify and refine the design.
- After the initial styles are complete, the developer will iterate on the HTML mockups by working closely with the designer to implement layout that was not practical to specify in the mockup round. For example, we would start with mockups for the iPad in portrait mode, and extrapolate up and down to layouts for other resolutions.
We spent quite a few years and tried a quite a few things to arrive at this set of principles, but we feel we have a solid, reusable base upon which to build our current and future projects.
Fortunately, you won’t have to spend years to be able to take advantage of these tools. To get started, just get the code from Github and follow the instructions in the README. Play with it and see where it takes you!comments powered by Disqus