Creating Sexy Stylesheets
Lately, I have taken interest in discussing methods of creating sexy stylesheets. While CSS can be used to create sexy websites, writing CSS can actually be an artform by itself. The way in which CSS is created, structured, and maintained can be a thing of beauty.
So how does one create sexy stylesheets? What characteristics would your stylesheets have?
A few months ago, I had the opportunity to present on this very topic at Web Visions 2007 conference in Portland, Oregon. In preparing my presentation, I surveyed twelve people who work in web design and development. The results of this survey, combined with my own work experiences helped me to compile a list of essentials to remember when creating stylesheets.
01. Keep CSS out of the markup.
Linking and/or importing stylesheets would seem to be a no-brainer to the intermediate or advanced CSS developer, but I want to stress why this is so important. I’ve seen many sites start out with clean, well-organized CSS files but then get littered as time goes by, with embedded or even inline styles (due to fast updates needed on short deadlines, or possibly sometimes even pure laziness).
Imagine that you are working on an extremely large-scale website with hundreds of ways content can appear. You have fast deadlines, so you opt for making “quick fixes” or updates by using embedded or inline CSS. Years go by, and this habit continues… Until one day you’re told the site is being completely redesigned (but all the content is to remain the same), and you only have a week to build it (including testing).
Normally, this would have been a fairly simple task of updating the stylesheet(s). Except you have years worth of “quick fixes” scattered throughout the site — and no way to remember where they all are. So now you have to either a) find a way to clean everything up and get everything styled for the redesign in one week (Good luck!), or b) find a new job.
Don’t make your job harder than it really has to be. Linking and/or importing your stylesheets is not optional. Create it clean, keep it clean, and you’ll be much happier.
NOTE: Be careful of adding too many linked and/or imported stylesheets in your markup. If you’re tempted to create a new stylesheet every time you make an update or add new content, you’re not doing yourself any favors. Excessive linking and/or importing can make bug-fixing difficult, and make your styles harder to maintain. It is understandable to want separate stylesheets for different sections or components for larger websites (I’ll go more into that later). Just be careful that you don’t go overboard.
It is worth mentioning that linking too many stylesheets requires additional HTTP requests, which can add up, and potentially hinder performance. Also, Microsoft Internet Explorer 6 has a limit of 32 linked stylesheets.
02. Semantics is not just a buzz word.
You know I have to bring it up; semantics are your best friend. Beyond choosing the most appropriate, meaningful elements to describe your content, make sure also that you’re choosing semantic class and ID attribute values. Besides being the “right thing to do,” it really does make your life easier (and it makes the lives of your fellow team members easier too– if you working as part of a team). Take a look at the following rule:
.l13k { color: #369; }If you were new to the job, and you saw that in the CSS file, are you going to know right away what that class is for? Most likely not. This class name could be an abbreviation for something, but there’s no real way you can tell right off the bat. Alternatively, maybe you put it there, so you know what it means, right? Today. But will you know what it means three years from now?
Now, let’s take a look at this rule:
.left-blue { color: #369; }You might immediately know what purpose this class selector serves as you know exactly where the left-side blue module appears. So it would appear that this works. Until along comes that redesign you have to build in a week, as I mentioned earlier. In the redesign, this module is now to be positioned on the right, and colored red. The class attribute values no longer makes any sense, so now you have to either change all your attribute values, or leave it as it is (which could lead to mass confusion).
It is always best to refrain from using colors (either the color name or its hex value) or width/height dimensions in your class attribute values. You should also avoid any attribute values that are presentational (such as “box”).Presentational attributes defeat the purpose of separating presentation from content.
Finally, let’s look at this more appropriately named rule:
.product-description { color: #369; }Here you can see that the rule styles product descriptions, no matter how many times your design changes. Clarity is a beautiful, beautiful thing.
03. Take advantage of commenting.
Commenting your CSS files can be a great deal of help to you and others during development if you use comments in creative and meaningful ways. At the most basic level comments provide little reminders why a certain rule is used. But you can use comments to really help improve organization and efficiency.
Reminders and notes
The common approach for commenting, leaving reminders and notes for yourself and other developers can help avoid confusion later. Keep these brief and simple. For example:
/* Turn off borders for linked images */
img { border: 0; }
Time stamp and signature
Some designers and developers also note the date and time that the CSS file was last updated, along with their name or initials. This information can provide a quick indicator of who to contact, as well as how up-to-date the file is.
/* Sushimonster Typography Styles
Updated: Thu 10.18.07 @ 5:15 p.m.
Author: Jina Bolton
----------------------------------------------------*/
Depending on the project, this can be a good idea, particularly if you are working on a team. Keep in mind that some organizations require leaving this type of information out (some companies prefer to keep names and dates out of files), so it is best to find out if there is a mandate on this sort of thing.
Organization
It’s a good idea to use comments to indicate the different sections within a CSS file. For example, if all header styles are grouped together, you can use a comment to section these styles off from the next section’s styles:
/* HEADER
----------------------------------------------------*/
I’ll go more into this a little later, when discussing “Separating style types.”
Comment flagging
If you have your CSS file organized into sections as I described above, comment flagging can also be useful to make it easier using FIND to skip down or up to the parts of the file you want to see. You can use a character (such as an equal sign [=]), along with a keyword (typically the name of the section, such as “HEADER”) to provide “anchors” in your CSS file:
/* =HEADER
----------------------------------------------------*/
This is particularly useful in long and complex stylesheets. You can read more about this at Stop Design.
Reference
A less common, but nonetheless useful approach is to use comments as reference guide. One example of this might be to include a color guide as you can see in Steve Smith’s CSS file:
/* COLORS
Body Background: #2F2C22
Main Text: #B3A576
Links: #9C6D25
Dark Brown Border: #222019
Green Headline: #958944
*/
You should place this guide at the top of your CSS file to help you remember what color values you use throughout your site. Another example is of an index-like approach. Here you can define different sections so that you can jump down to them (perhaps by using comment flagging). Here’s one example:
/* GENERIC
HEADER
SIDEBAR
FORMS
TABLES
FOOTER
*/
/* =GENERIC
----------------------------------------------------*/
04. Know when to use conditional comments or hacks.
There are many articles regarding the problem with hacks, and why Conditional Comments are a better way to handle Internet Explorer issues. Then there are articles that say otherwise. While I agree that Conditional Comments can be a much better solution than littering your CSS file with hacks, only recently have I come to realize there are instances where they are actually not the most appropriate solution.
Imagine that you want to set a minimum height for an element. The IE6 developers did not implement min-height, so you know that you can use height, which will be treated the same way. Does it make sense to create a whole new stylesheet, and inject it by way of Conditional Comments in your markup, when all you need is this one rule? Would it make better sense to keep the min-height and height rules together, and opt for a small “hack” within the same CSS file? In this case, I would consider it less efficient to use Conditional Comments.
Another thing to consider: if you have multiple places that your styles are located, using multiple CSS files and Conditional Comments can make your debugging process more difficult. Also, if you need to alter something (perhaps the min-height value in the above-mentioned scenario), you have to open more than one file to make this change. In many cases, this may not be such a big deal for you, but imagine if you have something defined in your main CSS file, and then redefined in 3 different IE stylesheets. That could turn out to be a hassle later down the road, especially if another developer making the edit doesn’t realize that these overrides exist.
If you do use Conditional Comments, I recommend leaving a comment in your main stylesheet letting you or a fellow developer know that an IE-specific rule exists. That way when you have to edit a height or something of that nature, you know that you have more than one file to open.
As always, if you do use hack, remember that browser updates can change what works later down the road, and the hack you use now may not work later versions.
05. Organizing selectors and declarations
Always, always keep your CSS clean and organized. I prefer organizing my selectors by style groups:
- reset styles
- typography styles
- layout styles (header, content, footer, etc.)
- module or widget styles
- etc.
Then, within each of those groups, I organize selectors by DOM hierarchy (working down the page, from the outside in):
- any parent styles (containing elements, working outside-in)
- block-level element styles (paragraphs, lists, etc.)
- inline element styles (links, abbreviations, etc.)
- etc.
Then within those, I work by element types:
- paragraphs
- blockquotes
- addresses
- lists
- forms
- tables
- etc.
Finally, I prefer to organize my CSS declarations by style type:
- 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
Some people like to organize declarations alphabetically. It doesn’t make sense to me, but it might make perfect sense to you. Whichever method you choose, stick with it, and be consistent.
06. Creating a framework
When it comes to developing CSS, If you find yourself doing the same things repeatedly, it is a good idea to consider creating a library or framework. A framework can be made up of a group of stylesheets that act as a foundation for your site, and help speed up your development time. Typical stylesheets you may find in your framework might include:
- screen.css - A screen CSS file can either have all your styles you want to be used for on screen, and/or can import additional styles, such as the following:
- reset.css - A reset CSS file can be used to “reset” all the default browser styling, which can help make it easier to achieve cross-browser compatibility.
- typography.css - A typography CSS file can define your typefaces, sizes, leading, kerning, and possibly even color.
- grid.css - A grid CSS file can have your layout structure (and act as the wireframe of your site, by defining the basic header, footer, and column set up).
- print.css - A print CSS file would include your styles you want to be used when the page is printed.
One example of a framework is the Blueprint framework put together by Olav Bjørkøy (which based itself off of work developed by authors including Jeff Croft and Eric Meyer). Another popular framework can be found at the Yahoo! User Interface Library. Many developers do feel that these pre-built frameworks contain markup and CSS that are a bit “bloated” and also that they contain presentational class attribute names.
NOTE: As I was writing this article in its draft stages, Jeff Croft released the post What’s not to love about CSS frameworks?, in which he mentions in the comments he was told that people think I am strongly against frameworks. I’m not sure where this came from, but as I stated in my response, I am not against CSS frameworks, and am very much for them.
For the best results, I recommend that you create your own framework that works best for you or your organization.
07. Balance readability and optimization.
Styles in formatting vary from developer to developer. Some developers use formatting styles that offer great readability, and then optimize the files (removing comments, spaces, tabs, carriage returns, etc.) before pushing the file live. This is a great technique and one I would recommend (done carefully). However, if you are somehow in a situation where you can’t really go through those steps, try to find a style that balances readability and optimization. Steve Smith has a great suggestion that offers a little bit of both.
Also, consider using hyphens instead of underscores. Microformats use hyphens as a standard separator, and certain older browsers have a hard time with them. You can read more about this at Underscores in class and ID Names.
08. Master your text editor.
Just as an artist has proper tools they know well, it’s important for a designer/developer to know the tools they use well. For CSS, that would be the editor you are using.
There are many text editors to choose from: TextMate, Coda, BB Edit, TextPad, DreamWeaver, etc. I’m not here to tell you which one to pick; they all have their pros and cons, and the right editor for you is up for you to decide. However, once you have decided on a text editor, make sure you learn everything you can about it. Find out what the shortcuts are, and learn all the tips and tricks you can.
Mastering your text editor is the best way to speed up your development time, and help you be more much more efficient when creating sexy stylesheets.
09. Use version control.
Smoother maintainability is also an important part of creating sexy stylesheets. This is where version control can be your best friend. It’s not only helpful for teams, but it can be a lifesaver even for the sole designer/developer.
Some applications have built-in mechanisms for source control. DreamWeaver uses a check-in/check-out system (that can help make sure that a developer doesn’t edit a file that is already currently being edited), as well as synching capabilities (which lets you sync and merge your local files with your remote files, or vice versa). This can be very handy, but are somewhat limited.
Subversion (SVN) or Concurrent Versions System (CVS) are great tools to use for more robust management, with additional options, like being able to revert, view changes (which is extremely helpful for teams — you can track who added/edited/removed code and when they did it), and resolving conflicts. There’s a great article by Jonathan Snook, called “Hosted Subversion” you can read for more information on how to set this up quickly and easily.
10. Create and maintain a style guide.
While in some cases, a style guide is an author’s guide with grammar rules and writing standards, it can also be used to outline standards for design, development, and content. A style guide is a great way to have a reference manual that can clarify rules on typography, grid, color, image sizes, etc.
When creating a style guide, it is a great idea to provide reference for the markup and CSS. This reference can be used as a handbook for the development team and future developers. It can include defined layouts, in which you can list the different layouts that can be used, and provide the associated markup and styles.
Finally, you can also leave steps for quality assurance for developers, (such as checking validation and accessibility) to ensure the highest quality.
Conclusion
Being an expert in CSS is so much more than having advanced CSS skills (i.e.: fully understanding the cascade, the box model, and how browsers work). I encourage you to think about ways you can constantly and consistently improve maintainability and efficiency. Think beyond what is designed in the comp, even if that is all that you have been provided. Make the CSS intelligent and plan for the future. Overall elegance in workflow is essential to master.
via :thinkvitamin
Labels: CSS
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home