Hello, in this article I will covering how you can write your style sheets more efficiently. This is an area of programming that I have recently been focusing on. This article builds upon the excellent article by Linda and works on the premise of the following things.
- A style sheet should be easy to read.
- A style sheet should be easy to maintain.
- A style sheet should be well commented
- The time to achieve these goals shouldn’t negatively impact the development time of a website.
Tip 1: Comment your style sheet
I use comments for two things. The first use is to break a style sheet into sections. This has a number of benefits. It encourages you to group your styles into sections – I.e. header, navigation, footer etc – , this makes your style sheets far more manageable. The second benefit is readability. It will take you only a moment to note when the section for your header ends and the section for navigation begins.
/**** Header ****/ /**** Content ****/
The second use is to explain unorthodox styles. This allows you to quickly remind yourself why you have inserted a certain hack or property. This can be very helpful when returning to a style sheet after a number of months, it will also help other developers understand why you used the declaration.
!important /** Hack to make IE the render navigation properly **/
Tip 2: Organise your styles alphabetically.
Have a look at the following example.
#header {
width:200px;
margin:0 auto;
height: 80px;
background:url(/images/header.png) no-repeat;
padding:1px 0;
}
Now compare it with the following.
#header {
background:url(/images/header.png) no-repeat;
height: 80px;
margin:0 auto;
padding:1px 0;
width:200px;
}
By listing the attributes alphabetically it greatly improves the readability of the stylesheet. It is far easier to rapidly pick out an element and change it. Take padding for example. Your eyes naturally scan down the alphabetically listed stylesheet, with the ordered style you have to dart up and down until you find it.
Tip 3: Tab nested elements
This is somewhat similar to commenting your style sheets. In an effort to make your style sheet easier to read it is a good idea to tab out nested elements. See the following.
#header{ }
#header #logo { }
#header #logo a { }
#header #logo a:hover { }
#container { }
#container #sidebar { }
#container #content { }
Now compare it to the below.
#header{ }
#header #logo { }
#header #logo a {}
#header #logo a:hover { }
#container { }
#container #sidebar { }
#container #content { }
Tabbing out nested elements allows you to quickly see what is nested in what and in turn allows you to easily see how nested elements are affecting one another.
Over to you
Are there any tips or tricks that you use to make your style sheets easier to maintain and read?
Tip 3: Tab nested elements
but doesn’t this makes the template loading increase?
Hmmm, I’m not too keen on this article. Admittedly the above are good practices for readability, but readability ONLY! Once you step out of your testing environment, that’s where readability ends. Unless you run a site where you want people to be able to read and understand (without having to manually add whitespace) your code, or your site is hosted in a high end platform with lots of bandwidth, then sure, go for it.
If anyone was to do this in production, they would cause an unwanted amount of server overhead when trying to serve files, increase load times and bandwidth usage. For production you should minify you css. Remove all comments and whitespace. CSS functions exactly the same without whitespace. I recommend using a tool such as http://javascriptcompressor.com to compress JS and CSS.
Why would you want your code readable to the outside world anyway? It’s not like comments help the browser understand what’s going on.
Either pay no attention to this article, or get the author to add “FOR DEVELOPMENT PURPOSES ONLY” on the first line.
Kind regards
Ashley
NetTuts wrote a very similar article a while back
http://net.tutsplus.com/tutorials/html-css-techniques/5-tips-to-writing-better-css/
And I agree with what almost everyone in their comments (including myself) said: organising CSS attributes in alphabetical order is just overkill.. there are only 6 tiny lines of code to read per element, how long does it really take to scan to the list? Personally it takes just as long either way for me.
What I do, is use a vaguely consistant structure that makes sense to me: width, height, and float are always the first things to be defined, and border + background are always the last. These are the parts of code that I edit most frequently, so I’ll always know where to find them, everything else just sits in between.
I only see one valid point, that being Tip #1.
Tip #2 I agree alpha is overkill – Plus most editors have “find” .
Tip #3 This is just wasting space. Not enough lines on too many stylesheets for this to be useful.
Too much squeeze
Obviously this article is about tips to keep your development stylesheet organised — hence “tab nested elements”.
A production stylesheet should be minified, but there’s no need for this to affect your development files. You can even separate your styles across multiple stylesheets for convenience, and compile them into one big stylesheet for production.
Alphabetical ordering of properties does seem a bit OCD, but whatever floats your boat.
People not agreeing with tip#3 are not working with front-end teams, the readability of others code is really important and is not a waste of space.
Of course when you go live it is another matter.
I disagree with alphabetical sorting on the basis of horrid readability. What you’re looking for is consistency, which can be achieved through a different, equally-consistent method:
#header {
background:url(/images/header.png) no-repeat;
padding: 1px 0;
margin: 0 auto;
width: 200px;
height: 80px;
}
(In case the formatting doesn’t take: What I describe is that things like padding/margin or width/height are grouped in a logical fashion. May include spacing between logical groups.)
This way, things that are often tweaked in relation to each-other are closer together, and things that are related to each-other are easier to find.
And yes, of course this is all in development.
And no, a few bytes are not going to add a tremendous amount of server overhead (at least on smaller applications — always keep your project in mind, because things will always be different depending on the project).
Happy coding!