CSS Conventions / Code Layout Models [closed] - css

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Has there been any attempt and creating a formalized method for organizing CSS code? Before I go and make up my own strategy for keeping things readable, I'm wondering what else is out there. Google hasn't been very helpful, as I'm not entirely sure what terms to search for.
I'm thinking more along the lines of indenting/spacing, when to use new lines, naming conventions, etc.
Any ideas?

Answer 1

Natalie Down of ClearLeft fame produced a really great slide show covering this topic and more http://natbat.net/2008/Sep/28/css-systems/
Download the PDF as it includes a lot more information than the slide show. I'd recommend this to CSS devs of all skill levels.

Answer 2

This is all very subjective as per the usual code formatting debates and I do not know of any formalized conventions.
The method I've chosen is to use all lowercase classes and ids with underscores separating words (#page_container for example). I declare all my tag styles first (html, body, ul, etc.), then all classes and ids, sorted alphabetically. Additionally, all the styles defined in each class, id, or tag are defined alphabetically as well. Using this convention makes it easier to track down a particular style.
For formatting, I always compress it as small as possible, but still legible. I put everything on one line with appropriate white space. If you have Visual Studio, you can specify this format and have it automatically formatted this way for you (Set Style to Compact rules under Tools, Options, Text Editor, CSS, Format).
Naming conventions are extremely subjective here, but the thing to keep in mind is to name your elements as their intended purpose, not their styled meaning. For example, if you have a company slogan you want to style in a large, red font name the id #slogan instead of #red_bold.
Here's a full example to give you an idea:
body { background-color: #fff; color: #999; font-family: verdana, arial, helvetica, sans-serif; font-size: 76%; padding: 0; margin: 0; }
a { color: #2c5eb4; text-decoration: none; }
a:hover { text-decoration: underline; }
h1, h2, h3, h4, h5, h6 { color: #f70; font-family: helvetica, verdana, arial, serif; font-weight: bold; margin: 1.2em 0; }
h1 { font-size: 2.4em; line-height: 1.2em; margin-bottom: 0em; margin-top: 0em; }
h2 { font-size: 1.7em; }
h3 { font-size: 1.4em; }
h4 { font-size: 1.2em; font-weight: bold; }
h5 { font-size: 1.0em; font-weight: bold; }
h6 { font-size: 0.8em; font-weight: bold; }
img { border: 0; }
li, ol, ul { font-size: 1.0em; line-height: 1.8em; list-style-position: inside; margin-bottom: 0.1em; margin-left: 0; margin-top: 0.2em; }
#content { clear: both; margin: 0; margin-top: -4em; }
#columns { height: 36em; }
#column1, #column2, #column3, #column4 { border-right: 1px solid #dbdbdb; float: left; width: 18%; margin: 0 0.5em; padding: 0 1em; height: 100%; }
#column1 { width: 28%; }
#column1 input { float: right; }
#column1 label { color: #999; float: left; }
#column2 a, #column3 a { font-weight: bold; }
#column4 { border-right: 0; }
#form { margin: 0 2em; }
.help_button { float: right; text-align: right; width: 30px; }

Answer 3

Here's a draft of how I order my css properties. It roughly follows the guideline of doing positioning and layout first, then typography, then backgrounds and other minor things. I try to order my properties by how they affect the box model as much as is reasonably possible. However, my ordering tends to shift around a bit. I'd appreciate any comments on this.
el {
display:;
float:;
clear:;
visibility:;
position:;
top:;
right:;
bottom:;
left:;
z-index:;
width:;
min-width:;
height:;
min-height:;
overflow:;
margin:;
padding:;
border:;
border-top:;
border-right:;
border-bottom:;
border-left:;
border-width:;
border-top-width:;
border-right-width:;
border-bottom-width:;
border-left-width:;
border-color:;
border-top-color:;
border-right-color:;
border-bottom-color:;
border-left-color:;
border-style:;
border-top-style:;
border-right-style:;
border-bottom-style:;
border-left-style:;
border-collapse:;
border-spacing:;
outline:;
list-style:;
font:;
font-family:;
font-size:;
line-height:;
font-weight:;
text-align:;
text-indent:;
text-transform:;
text-decoration:;
white-space:;
vertical-align:;
color:;
opacity:;
background:;
background-color:;
background-image:;
background-position:;
background-repeat:;
cursor:;
}
Personally I prefer to keep one property per line indented one tab, with the closing curly brace indented one tab. To me it's more legible this way, but that's definitely a matter of opinion/preference.
I used to tab indent css declarations to match my html parent/child relationships as much as possible, but I no longer do that. The grouping feature ofCSSEdit helps greatly reduce the temptation to do so.
CSS doesn't really have any prescribed convention for code structure. So it comes down to what works best for you.

Answer 4

Well I don't personally know of any convention per se, but I know there are a lot of recommendations out there that are really good idea to follow, but basically depends in how you want to implement your CSS for you to choose the one that fits you the most.

Answer 5

Files should be modularized, so you can make use of #imports. I typically have a base.css file for base classes (such as typography and colors). Depending on your site structure, it may be advantageous to also have other CSS "partials" to reuse throughout user-facing stylesheets. These descendant stylesheets can extend base styles with more granularity as needed (E.g., .warn {color:red;} might get extended by p.warn {font-style:italic;}, or h1.warn {border:5px solid red;}), which is a great design pattern for implementing so-called object-oriented CSS.
Within the files themselves, I like to alphabetize my selectors and property lists. I have tried maintaining separate lists for different types of selectors (an id list first, then my list of classes, and then my list of element selectors), but I've found this unnecessarily difficult, so I have all selectors in the same alphabetical list. That way I can quickly find the root of all complex selectors or any styles given to a simple selector.
Within complex selectors, I list each selector alphabetically.
If I can't use Sass for some reason, I might imitate its nesting pattern (I'm still unsure if this is working out or not), like so:
#import url('/css/base.css');
a {
color:#369;
font-family: Helvetica, sans-serif;
font-weight: bold;
text-decoration: underscore; }
a img {
border: 0; }
blockquote, .nav, p {
margin-bottom: 10px; }
blockquote {
background: #eee;
padding: 10px; }
h1, h2, h3, h4 {
font-family: Georgia, serif; }
h1.warning {
border: 5px solid red; }
.nav a {
font-size: 150%;
padding: 10px; }
.nav li {
display: inline-block; }
p.warning {
font-style: italic; }
p.warning a {
background: #fff;
border-bottom: 2px solid #000;
padding: 5px; }
p.warning .keyword {
text-decoration: underline; }
Unfortunately, you may look for the margin for p and not realize that it's part of the blockquote, .nav, p. This also isn't very "object-oriented" design, but it's arguably better than putting strings of classes on virtually every element that requires styling.
So, this approach isn't perfect and doesn't completely free you from sometimes having to find-in-file, but it's the best approach I have developed when I cannot use CSS templating tools for reasons beyond my control. I would love to hear any suggestions on improving this method :)