CSS DIY Organization
Tutorial Details
- Program: CSS
- Difficulty: Beginner
- Estimated Completion Time: 10 Minutes
I detest looking at code or mark-up that I’ve written in the past, which I don’t understand right off the bat. I’m surely no different from you in that I want to be able to come back years later, pick the code up, and understand exactly what is going on. I don’t want to dissect the simplest concepts, where the brackets are located, or even how the mark-up is indented. I have created habits to help me with rapid development, which have kept my sanity somewhat intact. I will be honest though, I have never given much thought to how I write and organize my CSS until recently, and that is what I am sharing today.
Introduction: Why Bother?
There are plenty of ways to do what I am suggesting with CSS. Let me be the first to say, don’t use anything that I am writing about today if your comfort level is not high with my concepts. Instead, think about the concepts, and improve on the solutions I am writing about. Share your own insights. I won’t argue with you if you think there is a better way to organize style sheets, as in the end there is no right or wrong way. However, I believe the more structure you add, the better off you are in the end when working with CSS.
“How easy is it for us, as developers, to rapidly find, understand, repair or add-on to a given code base? The easier that task is, the better the internal usability.”
There are a couple of concepts that I want to cover now in general to get the brain juices working. First, there is a concentration on usability with web development. We want the users of our websites to find things quicker, navigate more naturally, and overall intrinsically understand the concepts of our applications. That’s a very worthy use of time and energy. What is sometimes forgotten is the internal usability in all of the planning and discussions for our projects. How easy is it for us as developers, to rapidly find, understand, repair or add-on to a given code base? The easier that task is, the better the internal usability. In my opinion, that concept is as worthy of our time and thought as the front end usability.
Second, remember there is a C in CSS. It’s the cascading part. The method I use might fly in the face of some conventional thoughts, but when you back yourself into a corner for only using a certain aspects of CSS, you lose out on the power. When I am planning a large project, I think of the id selectors as “explain the entity”, class selectors as “describe the entity” and style attributes as “override what I just said”. I cascade the properties down to lessen the code, and give a little method to the madness. Again, there are no right or wrong ways, but when you have no plan, you are setting yourself up for a lot of extra work, not to mention extra overhead.
Finally, remember there are always tradeoffs in development. The most elegant ways of doing things aren’t always the most efficient.
Sometimes, the most efficient ways of doing things cost you down the road when you have to pick the code back up for support.
No one can make these choices for you, but you need to consider the tradeoffs while you write. Sometimes you have to bite the bullet just a little bit, perhaps to add an additional HTTP request to make the end result internally usable. Other times, you need to add a good comment to remind yourself of the choice that you made, and move on.
A Couple of Choices: Frameworks or The Wild West
Chances are, you are using either a framework to handle your CSS or you are adding your styles in a manner that you have grown accustomed to, but without much of a structure. Both have there upsides and downsides. Let’s look at a few CSS frameworks first, from the horse’s mouths:
Blue Print
YUI 2
Baseline
YAML
There are a numerous more, and just like a frameworks for your server side language of choice, each have their advantages over one another, and each have their drawbacks. I am not here to steer you away from a framework, as I have used them in the past and I believe in the concepts. I think when you are working on a large team, there is no better choice as it standardizes your styles and it lessons the voice of the individual developer and designer. That said, I do believe there are some drawbacks from using a CSS framework, as it adds to the overhead particularly with styles you aren’t using, and the learning curve is rather high. This can be a bit frustrating particularly with projects that have strict schedules. That said, the learning curve is just that, a curve, and over time you will master whichever project you deem best. The advantage of using a framework is that you now have improved your internal usability, as you are using a set method paradigm, although that method is something that is most likely outside of your control.
Wild West
The other solution is what I call the “Wild West” where anything goes. I’ll be honest and say there are many times I have just pushed something out the door without much thought to the future, or in the case of a very small project where the CSS is not very substantial. The learning curve here isn’t so bad, because you are writing your CSS as you go. You have complete control over your style’s destiny. Pretty cool so far! The problem is the internal usability. Come back to that project after it is no longer fresh in your mind, and there will be some problems. “Why the heck did I write this like this” or “I have no idea what I meant by this comment” or “Why is that input not changing styles” or “what is this big chunk of chum controlling” are common responses after the style sheet is no longer fresh in your mind.
My Choice: The Hybrid Solution
If I could put the framework solution on a sliding scale with the wild west solution on the other end, I think I would prefer something just in the middle. While one bed is too hard, and the other bed is too soft, I want to find the bed that is just right. That’s what I call the hybrid solution. It shares traits with both the wild west and frameworks. On the one hand, I have control over my styles, and with that the learning curve is rather low. On the other, I want to give a little structure to what I write, so that when I come back to it later, I have at least a familiarity of the structure because I build onto my methods which each project.
It’s a bit of a DIY project like in home improvement. You are trading the structure and cost of a professional for the convenience and familiarity of using your own hands to do the work. What you hope for in the end is the same finished project, but one without the learning curve or foreign ideas and concepts from the industrial strength version.
File Naming Convention
Thinking back on the choices that we have to make as developers, I make the choice of increasing the HTTP requests for a little better organization. I know I am costing myself a little bit of performance but what I get in the end is CSS that is easier to understand when I have to look at them next. You may make a different choice here, and you won’t get much argument from me. I just prefer smaller file sizes organized in a consistent manner over the one large CSS file or header in my HTML.
Here’s what works for me:
-
reset.css : A reset css is one that sets all or at least of the majority of browser styles to nullify. I use a reset css so that I can battle some differences with browsers, and I see the value when dealing with cross browser issues. It’s not Nirvana, and there are some that prefer no reset, or what I recently read, a soft reset. I prefer to reset everything, and I use the Eric Meyer flavor of resets.
-
forms.css: I segregate my form styles from the rest of my CSS. I want to know when I am working on forms, and they aren’t quite appearing as I wish exactly where to go.
-
global.css: My global css file is something that I use for each larger project that I write. What is contained in this small file are small classes which I might use over and over again in projects. My rule of thumb is, if there is a shortcut for the property, then it probably doesn’t belong in the global file. I wouldn’t use the font property. For instance:
/* Colors */
.red {
color: red;
background: inherit;
}
.blue {
color: blue;
background: inherit;
}
.highlight {
color: black;
background: yellow;
}
/* Lists */
.horizontal {
list-style-type: none;
display: inline;
}
.vertical {
list-style-type: none;
display: block;
}
/* Text */
.small {
font-size: small;
}
.large {
font-size: large;
}
.bold {
font-weight: bold;
}
Notice that these are very specific classes, that add to the cascading rules of styles. While none generally will be used as the only style for an element, they add to the description of the element that they class is applied.
-
style.css: My style.css is my main controller of my style. If you think in terms of OO for CSS, my style.css is my class, while the other files extend my class (somewhat anyway) and add to the inheritance of my main objects. I use my style.css to import my other files, and to define my local, project only, id selectors and classes.
ID and Class Selectors: Think a Little Differently
My hybrid method diverges here from most people, as my general rule with ids is merely to explain the element in question. ID Selectors are only used once per page (including GET processes), so I want these to be very specific in nature. In order to really maximize the reuse of code, any property outside of that explanation of an element, I really would prefer to use a class selector. Since this ID is unique to the page, I only want to use unique explanations for this selector.
For instance, my width would be somewhat unique. My padding and margin would be somewhat unique. My position would be somewhat unique. You could argue that the display for this selector would be somewhat unique. My color for the element; not really unique. My background, again not really unique. For the not really unique items, I think of these as “describe the element” for which I use class selectors.
Let’s illustrate this with a little code. For ease, I am using a recent tutorial by Jeffrey Way titled Quick Tip: Practical CSS Shapes. What if we took the original CSS:
#container {
background: #666;
margin: auto;
width: 500px;
height: 700px;
padding-top: 30px;
font-family: helvetica, arial, sans-serif;
}
h1 {
background: #e3e3e3;
background: -moz-linear-gradient(top, #e3e3e3, #c8c8c8);
background: -webkit-gradient(linear, left top, left bottom, from(#e3e3e3), to(#c8c8c8));
padding: 10px 20px;
margin-left: -20px;
margin-top: 0;
position: relative;
width: 70%;
-moz-box-shadow: 1px 1px 3px #292929;
-webkit-box-shadow: 1px 1px 3px #292929;
box-shadow: 1px 1px 3px #292929;
color: #454545;
text-shadow: 0 1px 0 white;
}
and transformed to this:
#container {
margin: auto;
width: 500px;
height: 700px;
padding-top: 30px;
font-family: helvetica, arial, sans-serif;
}
#heading-one {
padding: 10px 20px;
margin-left: -20px;
margin-top: 0;
position: relative;
width: 70%;
}
.norm-background {
color: #fff;
background: #666;
}
.heading-fancy {
background: #e3e3e3;
background: -moz-linear-gradient(top, #e3e3e3, #c8c8c8);
background: -webkit-gradient(linear, left top, left bottom, from(#e3e3e3), to(#c8c8c8));
-moz-box-shadow: 1px 1px 3px #292929;
-webkit-box-shadow: 1px 1px 3px #292929;
color: #454545;
text-shadow: 0 1px 0 white;
}
So far, all I have really done is added two new classes from the unique h1 selector and abstracted that h1 out to a unique ID. I haven’t gained anything for the moment, and in actuality I have added just a whee bit more overhead to my file. Where’s the advantage then?
If you think for a moment that you might reuse these descriptions somewhere else, perhaps for a sub-heading, then we have some code reuse. Let’s look to see what we can do now. Here’s how it originally looks:
and here is how it looks with a sub-heading:
I only added a new definition now:
#heading-two {
padding: 10px 20px;
margin-left: -20px;
margin-top: 0;
position: relative;
width: 30%;
}
Along with a little HTML:
<h1 id="heading-one" class="heading-fancy"> My Heading <span class="arrow"></span> </h1>
<h2 id="heading-two" class="heading-fancy small"> My Sub-Heading <span class="arrow"></span> </h2>
We have code reuse, and we have a method which is consistent. If you take this method and apply it, you will reduce the number of styles (or objects if you prefer) that you write. Less code with a method means easier support at a later date. Really, nothing earth shattering here, but when you begin to explain your ID selectors but describe your classes it’s an easy method to add a little sanity to your code.
Style Attributes
I’m sure someone, somewhere, has told you to never use the style attribute. I am also sure that some of you will disagree with me, and that’s OK, I can take it. I am going to break that rule just a bit with a caveat. Never use it without a little thought to what you are doing. There are legitimate uses for the style attribute, particularly when working with complex applications using AJAX calls, but those uses come from your behavior layer.
When you should use the style attribute, is when you need to make a quick final call to override something in the cascade display for the element which wouldn’t make sense to add to your global.css file. For instance, you might need to override a style from your behavior layer based on an user action. It does add to the complexity just a bit, but it adds to the cascade. I wouldn’t use multiple properties, as this is a quick override, or rather, “forget what I just told you, do this instead”. It’s a cascade, and you should treat your CSS as such, in my opinion.
Indentation, Layout and Comments
We spend a lot of time putting emphasis on our indentation in our code and HTML, but I don’t often see the same emphasis in our CSS. It makes the world of difference. Let’s take our working example again:
<div id="container" class="norm-background">
<h1 id="heading-one" class="heading-fancy"> My Heading <span class="arrow"></span> </h1>
<h2 id="heading-two" class="heading-fancy small"> My Sub-Heading <span class="arrow"></span> </h2>
</div>
If we indent that in our markup, why not indent it the same way in our CSS:
#container {
margin: auto;
width: 500px;
height: 700px;
padding-top: 30px;
font-family: helvetica, arial, sans-serif;
}
#heading-one {
padding: 10px 20px;
margin-left: -20px;
margin-top: 0;
position: relative;
width: 70%;
}
#heading-two {
padding: 10px 20px;
margin-left: -20px;
margin-top: 0;
position: relative;
width: 30%;
}
It adds just a little more emphasis as to what is going on with these ID selectors. I understand now that they are children to the container div without comparing my mark-up.
When deciding on the layout of your style file, this is the rule of thumb that I use. You have to @import your additional CSS files first starting with the reset.css file, and then the rest. Define your elements next such as h1, anchors, etc. Next, define your ID selectors in your style.css. If you are working with multiple pages, comment the start of each new page within your indentation. For instance, #container is probably an element of the layout which is the container for each page, so start there with your indentation and work out commenting where you are using each element. Finally, define your classes. I don’t normally indent my classes, due to the fact that they are often reused, and the indentation doesn’t show where they are used.
Finally, and probably most importantly, comment your CSS just as you would your server side code. If there is any context that you can give to a class, such as elements that it is used, or ID that it matches, comment it. Any context that you give your future self is like having a time machine. Marty McFly might not have knocked that creepy guy out of the way of oncoming traffic if he had just read the Flux Capacitor comments first.
Conclusion
I am relatively sure my methods will not have a new dance move named after it, nor will it cure cancer. I am not even sure if they would be adapted by a single person outside of my immediate family. That said, I really hope you take the concepts away from this and build methods that work for you. Development usability is a goal that we should all be striving to achieve. When you create a methodology, you increase your internal usability exponentially as you are developing habits which you reuse and share with your team and others. It fixes development problems, increases productivity, and decreases the overall cost of development. It is one of those rare win / win propositions that you encounter in your daily development life.
Thanks for reading, and please share your ideas.
Enjoyed this Post?
Subscribe to our RSS Feed, Follow us on Twitter or simply recommend us to friends and colleagues!
By John Cox
Join our newsletter!
Create a Tutorial, Get Paid!
Have something to teach the world? Want to earn money doing it? Tutorials, screencasts, and articles published here on Nettuts+ are largely contributed by readers just like you! We'll pay you great money for good content. Find Out More
hmm.. interesting article :)
Don’t forget about 960 Grid (http://960.gs). It’s the CSS framework I tend to use the most.
This is something I’ve recently started doing myself. I’ve been working on an admin theme for themeforest, and I had the same thoughts. How can I make the code re-usable, maintainable, and easy for others to understand?
I’ve split things into different stylsheets, much like you have, for example, splitting out into reset, text, layout, form, table, calendar and so on. Then like you have, I’ve indented my code to make understanding hierarchy better without checking the css.
One thing I have been pondering though, with several css files, what is the best way to implement them? A global.css that pulls them all in with @import? Calling each one separately in the head of the document? Somehow combining them all into one css file with php (Not really an option for my template, but interesting non-the-less)?
Great article anyway, and makes me happier with what I’ve been doing, and feeling comfortable with =)
I’d @import them at the beginning of my style.css in some type of order like: reset.css, global.css, text.css, forms.css.
Seems they’d cascade best that way and your markup wouldn’t have 5 or 6 stylesheets cluttering the . I did that once, it’s pretty ugly.
I do the @import in my css as I can see the cascade. w1sh mentioned the order as well, keeping in mind they cascade down.
Good article John. Made me think a little on how I structure my css. I can’t use the @import, as I am just starting to use minify, and I believe this causes havoc with it. I did that before though, and it works great. Only one link.
I have tested both using @import and including files into one css with php.
The second option with php seems to be cool cause you have less server requests, but there is one disadvantage with this, the difficulty in finding your CSS property in CSS sheet by looking at the line number ( in Firebug for example ).
Because you have all styles included one php file, and that makes it hard to find the property by looking at the line number.
I’m currently developing a small framework as a base for themeforest themes and have gone through the same problems. I aggree on intending css rules as well: much more readable and i aggree on splitting it into smaller files as well. But i can’t aggree with @Jan. Finding css-definitions in ff firebug addon is such simple, no matter if you @import it or just (in wp-theme cases) use ex. wp_enqueue_style or simply hard code it in your header.
But: if you *don’t* use the @import rule, you’ll get every file loaded in your header and there is the big advantage: you can simply right click on a file and delete it. That makes css-bug tracking and rule-overriding pretty simple. Just delete one file after the other from bottom to top and you will have your trouble causing file & rule in less than a minute.
Good article. Thanks a lot!
Great post. This will help me a lot when coding CSS. I didn’t even know CSS frameworks existed!
Great post, In my opinion, the commenting in the css works the best (for me), because your comments can be as long or as little as you want, so its the easiest way to come and pick it right up, In my opinion, you should try and use as many comments as you can, at least that way, you know what’s going on.
What are other peoples methods, what helps you remember?
Nice to see an article like this. ALways find it an inspiration seeing how other people do things. Makes a change from lists of how-to articles and instructions.
Thank you John for this excellent post. I am currently working on a site maintenance guideline document and this gave me new material to add.
very good post thanks a lot
Really nice post. Organized and simple-looking CSS is really easy to understand to others who starting to learn this.
This is a very relevant topic and a great post. Personally I’ve never used frameworks, but can see how they’d be useful. I tend to write my CSS from scratch as I like to look at it like a blank canvas and not look in a predetermined direction when styling any given site. That being said, if given little time on a project, frameworks I’m sure are quite time-saving.
Great tips, thanks!
I thought I read somewhere else that adding 4 different CSS files is not good, since it adds to the http requests. I use 2 Reset and Styles. Is adding 2 more that important to the number of http requests?
Hey Dan – This is true. However, there are easy ways to combine them, once you deploy.
Jeffrey is right, there a multitude of ways of compressing and importing css files. One of the methods I use (and I cant take credit for this I found the code on another site), is to use php to compress all the css files for me. so code looks like:
and save as compressed_css.php.
then simple inlclude in tag, like:
*note the css file has a php extension
pros: it allows me to write as many comments as I want in the original style sheets, to help explain the code better, but when serving the pages it removes all the commented code. can include as many stylesheets as you want, so splitting up the css files into many “object” type files will be a breeze.
cons: readability of code once the page has been served is bad, all css is on one line, so if anyone is trying to read your code they will have a tough time.
the above might not work for everyone but so far, for me at least, its been simple to implement on my sites and I have not come across any issues as yet…
sorry code didnt come up before (wrap in php tags offcourse):
header(‘Content-type: text/css’);
ob_start(“compress”);
function compress($buffer) {
/* remove comments */
$buffer = preg_replace(‘!/\*[^*]*\*+([^/][^*]*\*+)*/!’, ”, $buffer);
/* remove tabs, spaces, newlines, etc. */
$buffer = str_replace(array(“\r\n”, “\r”, “\n”, “\t”, ‘ ‘, ‘ ‘, ‘ ‘), ”, $buffer);
return $buffer;
}
/* your css files */
include(‘reset.css’);
include(‘grid.css’);
include(‘admin.css’);
include(‘jqueryui.css’);
ob_end_flush();
Thanks for code Wade :)
After reading this few comments i thought it will be usefull a quick tutorial for doing css compression with php file, but with these code is all clear.
Yeah, according to Google’s PageSpeed and YSlow, the more HTTP requests you serve, the slower your site loads. However, as Jeff said, once you deploy you can consolidate all of those stylesheets (in the right cascading order) and compress it with CSS Compressor for a smaller file-size/# of HTTP requests.
As mentioned by Jeffrey and w1sh, it does create more http request, which by the nature of the beast, adds overhead. It’s a choice I make to add a little ease to my code. Everything is a trade-off though, and if performance at the cost of support or development is the choice that makes sense, then combine them at deployment:)
John, maybe Site Deployment and all that is required (or suggested) would be a good idea for a post. Something like a Checklist before deployment. For example,
Don’t forget meta description (check)
Create XML sitemap (check)
Submit sitemap (check)
Compress CSS (check)
Etc, Etc
Dan, Good idea! I’ll see if I can come up with something tangible from the idea:)
This is one of the biggest reasons I use SASS.
Aside from the other benifits, the “partials” feature combined with the directory watch (that updates the main css file when any of the child files are changed) means that I have many files of css… but only ever upload a single one (aside from print/ie6 separate sheets)
That takes teh OOP paradigm a little further, with each file being all the properties of a single “object” – makes for going back into the code much much easier later.
gud article! THANKS :)
dumidesign.com
I would also suggest that you never use colors as class names .red and .blue are bad ideas. Let’s say you have a site where they have a red tagline that is all over the site. A new manager comes along who is going to revolutionize their website and change that red to green. Now you have a .red class that shows a green color.
The same is true for .padding-10 type classes or any class the states what it does specifically. It’s not against the law, but definitely not a best practice.
That’s an excellent point on the renaming. That said, you are replacing the code somewhere, whether as color codes in your CSS or in your structure, and I would rather be descriptive in my mark-up for my own sanity. In my opinion, there are no right or wrong ways in organization, just ways that work best for you.
I agree Seth, generally its not best practice to use literal names such as red as you say, better to give a descriptive name such as warning or error which is less likely to cause confusing when styles change (as they inevitably will). I’ve seen sites using this style cause a lot of confusion when picked up later by different developers. Nevertheless a good post :)
Seth although you make a very compelling point (and one of the reasons I choose to write my id’s and classes as descriptive of the element, not its style) still I would point out in defense of John’s method that even if somebody does come along and make such a change, going through your HTML document and replacing the class with a new name is as simple as “find and replace”.
I have to say I’m not a big fan of the way you have added extra markup to your HTML… even adding an empty span. I understand the appeal of these kind of re-usable class names but like Seth said using class names which describe the style: .red, .green, .padding-10 can lead to issues when those styles change. This also leads to really messy markup… To me the trade-off of having slightly better/smaller CSS file in exchange for dirtier markup which isn’t semantic is just not worth it.
Instead I prefer to use the cascade to target specific elements. Adding class or id to the body can help here too. So lets say you want to target all the h1 tags that are contained within the header. Instead of using h1.fancy-header {} you would have #header h1 {} or if you want to target just the homepage h1 in the header you might have body#homepage #header h1 {} This will also naturally group things in your CSS… visually.
#header h1 {}
#header .nav {}
#header .logo {}
#header p {}
#header .etc {}
Your other points are less controversial and more of a personal opinion. But it is important, especially when working with multiple developers, that you develop a way of organizing your code so that others can quickly find things too. So thanks for the article it is always interesting to see how other developers keep their code organized.
As far as the multiple CSS files go, I don’t see much of an issue. For development purposes it seems like a fantastic way to organize and separate files. On a live site, all the files should be condensed into one and compressed if HTTP requests are an issue for you. But there’s no one saying that can’t keep those old files archived in a different directory on your computer for future use if you need to change things. Then, you can recombine, compress, and re-launch the new css.
Nice post.
I keep my CSS to a screen.css and print.css. If i’m ever incorporating something “stand-alone” like SIFR for example, i’ll typically keep it separate.
My reset style block is at the top of my screen.css (i use the yahoo one, and leave their little copyright/licensing speel) and then i use comment blocks and indentions to break the rest up throughout.
I use frameworks a lot for both my design and my CSS. However, when you get a design from a design who does not follow a grid system this becomes challenging. I try to use the same basic selectors, classes and ID’s if I name my elements myself throughout all project. But for designers who are “web designers” and have no idea of what grid layout is makes it challenging when you get handed off a design that will not work in a grid. These tips work great, if you use the grid. Now some of these really creative designs are not using grids as well. So I am hard pressed to attempt to use grids in all my work. The basic resets my be my staple, but as for a grid system layout, it may go a way the more creative designers start to become.
Try to get the designers you’re working with to stick to a grid system. All designs should have some underlying structure to them even if it’s not immediately apparent. Designers might call it limiting at first, but it’s something they really should be doing anyway. Besides, you’ll often find that the more limitations you impose on yourself the more creative you become!
doesnt longer selector names == more size to the CSS file
Yes. Everything is a tradeoff. If you can come back to code with selector names like:
#a1 { foo }
#b1 { foo }
etc, then cool. I’d rather make a plan to reuse as much code as possible, but have names that make sense than to try to shorten everything possible. Again, some thought has to be given to the development (internal) usability, IMO.
Great posts. As a noobie to CSS this really helps me learn to do things in a structured way.
Thanks!
Great post John.
Ive started indenting my CSS, and loving it. I cant believe i hadn’t started earlier given that we all do it for HTML etc.
Regarding combining css files etc for page speed improvements (less http requests), does anyone have any best practice recommendations for doing this? I like Johns method of breaking up the CSS into different stylesheets so id prefer to keep that for development, but how does everyone (auto?) combine them once the site is live?
This sure looks like a double post with this. http://net.tutsplus.com/tutorials/html-css-techniques/which-css-grid-framework-should-you-use-for-web-design/
Envato, your repeating content.
I don’t like it.
Apart from blueprint that I used for my personal homepage, I have successfully used 1kb css grid that is a “lite” version of the 960 GS.
http://www.1kbgrid.com/
The grid css will be generated on the fly according to the preferences you set on the visual interface.
cheers
Stefano
I agree with many of your concepts and use quite a few of them already. I’m always thinking about how I can make the file size smaller, the CSS easier to read or should styles be inline or in a block. The best thing to do is find a way that is good for you and stick to it. If you’re in a team and share the workload on the same CSS file obviously there’s going to be some kind of compromise.
More artciles like this please!
“Wild West CSS”. That’s a fitting name for the all the wild ways people do CSS. :)
I’m surprised you didn’t mention the @group function. The single biggest help in organizing my CSS files recently has been this function. Code editors like Espresso and CSSEdit support the @group comment that will display everything within /* @group */ and /* @end */ as within a folder in it’s navigator panel. Not sure if other’s like Coda or BBEdit support it also, but I’d be surprised if they didn’t.
You can even give descriptive names to the group. Here’s an example:
/* @group Home Page Styles */
body {
style: value;
}
h1 {
styel: value;
}
/* @end hp styles */
Not only does it make for easy viewing of categories in the stylesheet itself, but viewing it in code editors that support the comment is really helpful.
That’s a really good tip. I wanted to get into the mindset of “explain it” “describe it”, “override it” and I made a decision to stay away from some of the tools that aren’t global across all editors. Real good mention though:)
Coda does not support the @group function. The only reason I still use CSSEdit…Completely worth a separate program running just for the @group function.
I hate indented code. I group things by divs and it’s soooo much easier to pick up when you’ve not looked at it for a while.
When I need to edit someone elses code that isn’t decently formatted, half my time is spent organising it into some readable form…
Maybe my biggest pet hate!
Having a lot of external css means extra http request!
If you set a caching system for the site this problem will be solved.
django_compressor does this stuff if you do your job in python/django.
Love the idea of indenting css code so you know a certain selector is part of the ‘container’ div but what if those selectors are also used in another different container ‘leftcontainer’ somewhere else? Although this technique seems logical you could argue that this might confuse things a little later. I’m quite easily confused when it comes to looking at any old code I’ve written so I’m not sure if any of this would really help me personally, I’m just too unorganised!
The @import make the sites load slower, just watch the page loading with firebug.
More about: http://www.stevesouders.com/blog/2009/04/09/dont-use-import/
960 with some customization is great for me :-)
Not really a fan of css frameworks, seems like too much overhead.
I really like the indentation style, I’ve done it when I first time write CSS. I’m a C++ developer and I really don’t know why they just code CSS with indentation instead of just write comment.
Nice guide
@Carl: Maybe you’ll see the same content about css framework but their content is quite different :)
I’m pretty good with CSS so I just use a sorta ugly but epicly awesome (in my opinion) way of writing mine, which means one liners, comments only to separate stuff, and comments to sometimes explain a weird declaration.
For me, it’s readable and I have went back to my CSS knowing exactly what’s going on but if I was working with someone else, I doubt they would know what was happening. Point is though, whatever works for you keep doing it.
My main CSS file: http://cdn.myunv.com/css/uecore.css
Great Article John. I should reconsider the way i write CSS.
I get the code reuse part, but .red, .blue, .small? Please. That’s ugly, meaningless and a mess to maintain. Keep your styles in the stylesheets.
Interesting article, but there is one thing I don’t really understand, why change the h1?
If your website’s desing is consistent along all its pages then you should only have one style for h1s, one style for h2s and so on. Adding an id to the h1 seems unnecesary because a webpage should have only one h1 tag. Next, if you add an id to an h2 tag that means that your page can only have one h2 tag with that style, again this breaks the purpose of the h2 tag because it is intended to work as a sub-heading and webpages can have multiple sub-headings (h2 to h6).
Don’t people call this classitis?
I think this is a good article but I’m totally agree with Ryan, your adding to much extra HTML and one of my rules on CSS is: don’t create a class for define only a property, this means the example of create a class :
Ex:
.red{
color:ff0000;
}
.padding-10{
padding:10px;
}
Or just
.right {
float:right;
}
You are going to fill all your CSS file with this “general” classes and your HTML is going to be full of classes and id’s. I’m a old school dev guy so I dont use frameworks and I did my own reset based on Meyer and yui reset files… none of this two works 100% on my projects.
If anyone wants to know more about design, CSS and HTML tips, follow me on Twitter (acearaujo) I will be happy to help and learn of you more of your experience on this topics
For a last comment: why create a class:
.bold{
Font-weight:bold;
}
When you have a strong tag?
Strong doesn’t mean “bold the text” in HTML5. It means that it is “very important”, used by screen readers, etc,.
Also, the HTML came from a different article, as pointed out, I was merely adding on to the previous article as mentioned:)
I’m not totally agree, cause for some reason w3c create strong tag and this strong make bold the text. i know we can change that thru css and make it different, but it’s a strong, everybody knows that tag change the text to bold… why bother to create a class for do the same?
I’m that kind of guy who likes a clean html and css, so i use what i have in my hand…
.red ?
red isn’t a class, it’s an attribute.
How long has it been? CSS was invented 1996, and OOP has been around even longer… how do people still not get this?
A class describes a set of objects and should reference what those objects are, like .introduction .navigation. Why tie the class names into their properties, you might as well just do all your styles inline, because you just going to have to go through and edit every single instance when you want to change something. It defeats the whole point of CSS, it looks like it introduces re-usability, but in fact it does the opposite, because you have to edit hundreds of classes on your tags all the time just for minor changes.
I am just so confused how to get something like this on my website. I don’t even understand how to make this computer text work. I copied it and put into my notepad and put the style information after my style brackets and put the headers into the body and nothing shows up.
True. Every designer has his/her own style of work. I have mine too. Though I have couple of mismatches with your techniques, rest of the tips are good to follow. Thanks for sharing.