This seems potentially a trivial and silly question but it's something I spend waaay too much time thinking about while I'm pain-stakingly composing CSS:
What rationale or scheme do people use to decide what order you put your properties into your selectors/elements? eg:
.selector{
positioning and floats: values
background: values
text and font: values
other esoteric properties: values
paddings and margins: values
border: values
}
I know ordering matters, but it only matters in certain specific cases but for all the rest I just feel compelled to have some consistency, some guidelines - I reckon it makes it easy to both debug and reuse.
Is there some course I missed or some major resource or bible out that you know of that suggests or stipulates what order the properties should be roughly kept in?
Above is basically how I tend to lay mine out - there's no particularly good reason for, it more-or-less just evolved that way. Obviously it's not an ironclad schema, but it's what I use when I need to stick to something.
Any thoughts?
4 answers
points
There are three main ways I know about:
- Alphabetically—easy to find the property quickly
- Randomly—this is the most popular :D
- In order of effect (=from largest effect to smallest effect, and from the outside in)—this is what I do, and while quirky it makes sense to me :D
I start with the things that make the most difference (display, float, position etc), then the box model (margin, border, padding; out-to-in), then background (logically should be before padding, but hey :), color, and finally typography.
Here’s an example:
.main .speaker-list li {
float: left;
position: relative;
width: 20em;
height: 9.6em;
margin: 0 0 1.6em 3.2em;
list-style: none;
}
HTH
- Ah... I suspect #3 was what I was trying to go in for! Though alphabetically sounds really appealing - being the least arbitrary.
- So it’s not just me!? :D I think the important thing is to try to decide on one style and stick with it. It’s the same with separating your CSS into type.css and layout.css—if you do that you’ve gotta put *all* the font rules in type.css :)
points
Here's my preference:
- Display & Flow
- Positioning
- Dimensions
- Margins, Padding, Borders, Outline
- Typographic Styles
- Backgrounds
- Opacity, Cursors, Generated Content
The main idea is "how they affect the box-model"
This is something I've also thought about waaay too much! =)
In fact, I blogged about CSS property ordering earlier this year
point
there's also a view that says you should declare a property just once and then add all your elements to it.
e.g.
h1,h2,h3,h4,h5,h6,pre,body,p,div{margin: 0; padding: 0;}
so instead of lots of different declarations based on html structure, you have a few styles and the elements they apply to.
Personally my CSS is organised according to html structure and properties are in importance order - primae at the top, added to fix bugs at the bottom.
before final use I compress it all anyway, so how I write it tends to be more fluid!
This is my current new file template:
/ =General -----------------------------------------------------------------------------/
/ hack for forcing scroll bars to stop page jog - http://www.splintered.co.uk/experiments/49/ / / html { margin-bottom: 1px; min-height: 100%; } / html { overflow:-moz-scrollbars-vertical; }
/ Remove padding and margin on selected elements/ h1,h2,h3,h4,h5,h6,pre,body,p,div{margin: 0; padding: 0;}
/debug border on all divs/ div{border: 1px solid #ccc;}
/ Class for clearing floats / .clear {clear:both;}
/ Remove border around linked images and fix Firefox odd spaces / img {border: 0; vertical-align: bottom;}
/ =Structural -----------------------------------------------------------------------------/
/ =Typography -----------------------------------------------------------------------------/
/ =Headings -----------------------------------------------------------------------------/
/ =Links -----------------------------------------------------------------------------/
/ =Branding -----------------------------------------------------------------------------/
/ =Main Nav -----------------------------------------------------------------------------/
/ =Sub Nav -----------------------------------------------------------------------------/
/ =Main Content -----------------------------------------------------------------------------/
/ =Secondary Content -----------------------------------------------------------------------------/
/ =Footer -----------------------------------------------------------------------------/
/ =Forms -----------------------------------------------------------------------------/
/ =Tables -----------------------------------------------------------------------------/
table {border-spacing: 0; border-collapse: collapse;} td {text-align: left; font-weight: normal;}
/ =Misc 1 -----------------------------------------------------------------------------/
/ =Misc 2 -----------------------------------------------------------------------------/
point
I generally do as the posters above, that is:
{ floats, display, position, width/height/margin/padding (box model), backgrounds, other stuff }
I also list things on one line, and I indent my CSS according to document nesting and flow. For example:
body { styles... }
#banner { ... }
img#logo { ... }
#header { ... }
#columns { ... }
#content { ... }
#contextual { ... }
#sidebar { ... }
#footer { ... }
With large stylesheets, this organization really shines. Usually you want to find the area you're interested in changing first (#header), THEN examine or change its properties. This method aids in scanning tremendously, and it also orients you to the document flow/nesting if you forget.
If you do it this way, I find it more important to follow the above advice and list the "important stuff" first.
- Interesting. I've been using a single line format for some time now, but never thought to indent in such a manner. I do, however, follow a sectional format where items are grouped between comment headers. I might try working with indented CSS and see how that flows for me. Although changing ones habits is always easier in theory than actual practice.
