http://lanyrd.com/2008/barcamp-london-5/sg/
She splits everything in to general styles (basic HTML elements), helper styles (things like forms, notifications, icons), page structure (header, footer, layout columns etc), page components (reusable composable classes for components that occur on different pages in different combinations, such as a news teaser) and over-rides (special cases for individual pages, rarely used).
She hardly ever uses IDs, preferring classes for almost everything - because CSS written against classes can be used more than once on a page.
She uses CSSEdit's groups feature to make the CSS easier to navigate - it's all in one file. http://macrabbit.com/cssedit/
View the stylesheets on http://lanyrd.com/ and follow the link at the top to the unminified version to see annotated examples.
Goes hand-in-hand with javascript to ease selector targeting.
I never scope ID's either, that's the wrong way to do it. An ID is always unique so it is top-level.
I agree about IDs for JavaScript though.
Ids should be used only for scripts, and most of the time should be auto generated anyway.
Leave IDs for uniquely identifying an element on a page because you need to access it from a script.
Treating them like "Extra Strong" class names is a maintenance nightmare.
Would you mind elaborating on the JavaScript point? Is it for convenience with document.getElementById or something?
Using jQuery, I tend to prefer class selectors the same as in my CSS.
Don't worry, I'm sure all those developers are "doing it wrong" too.
I think it also has to do with frameworks. Sometimes frameworks spit out a lot of HTML you won't ever need. So the HTML is bloated in the first place. Then it's a hell of a job to style the mess.
When you are fortunate to control the HTML you should first start to optimize your HTML before you even start with CSS.
We use a far-future expires header (and serve from Amazon CloudFront), so browsers should only ever fetch the file once no matter how many pages on the site the user visits.
Then, my code is usually organized as follows. Each section can be extracted to a partial if it gets long enough or if more separation is desired.
Framework includes and resets
Variable declarations — colors, possibly specific widths
Universal method declarations
Standard global tags — headings, p, a, ul, li, etc...
Generic form styling, usually in a dedicated partial
Layout — container, header, content, footer
Then to specific section styling
I'm pretty happy with this approach. It was formed fairly organically but become more defined as I use it for more projects. It also seems to work well for both large and small projects, since partials can be used when the code starts getting long.
More on debug-mode: http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#de...
Grab the Firefox add-on here: https://addons.mozilla.org/en-US/firefox/addon/firesass-for-...
What an awkward sentence. I need sleep.
Sass::Plugin.options[:line_comments] = true
# or with compass:
sass_options = {:line_comments => true}
/* line 138, sass/screen.sass */
#navigation a:hover {...}
https://addons.mozilla.org/en-US/firefox/addon/firesass-for-...
Doesn't seem to support FF4 yet though.
reset.css - I use eric meyer's
elements.css - Global defaults for things like body,
h1, h2, h3, p, a, input, strong. All
or almost all selectors in here are
just tag names.
layout.css - Just sets up the global layout with
containers: e.g. header, footer, left
column, right column.
blocks.css - Reusable chunks.
All files get concatenated and minified before serving, obviously.
For a website: callouts, user quote styles, tables styles [zebra stripes, etc.], feature lists, intro paragraph styles, Flash/message styles, common control styles, etc.
Stylus is great: http://learnboost.github.com/stylus/
I made a post about it, and personally prefer it to Sass and Less: http://nylira.com/stylus-the-revolutionary-successor-to-css/ The hardcore abbreviation mixins in my post seem to offend some coders. When you work in CSS and HTML hours every day though, every character saved adds up to a huge productivity boost.
My current project has 30 directories with 73 partial Sass files, which compile down to one 320kb file.
As to your question, I organize my partials based on controller and url structure.
Isn't that a lot to download? That's like 2 seconds on average to download that file in the U.S., and probably in the 10 seconds or higher range for a lot of folks. I guess if the download is delayed to after some kind of engagement (sign up, etc) it's not a big deal?
Is 320K of CSS really necessary? (legitimately asking)
Keep in mind that this only 42k gzipped.
I'm working on a few relatively complex web apps where the CSS download time don't come to anywhere near that size. In my world (mobile devices, in particular) 320k would be totally unacceptable. 100k is about the point where I start re-evaluating my design.
reset.css //for resetting browsers
grid.css //if I'm using a css framework
global.css //styles that are shared across the site
section.css //styles that pertain a specific section. The name of the file varies, i.e. "about.css".
reset.css There's a bunch around, I use the one from htmlboilerplate.com, but there's many good ones available. (Eric Meyer's). You will almost never touch this file.
grid.css I only use this occasionally, when I'm working on sites where the grid is very clear and I take out all the stuff I'm not going to use. I usually go for a three col version of 960.gs and trim it to about 12 lines of css. Never touch this.
global.css Here you put your nav, your footer, you body styles, etc. I think that separating by colors and typography doesn't make sense, because you usually change a widget's appearance.
section.css I count on the body tag having a classname, so I can have body class="about" and then do...
.about section.photo {...}
Miscellaneous I avoid the one declaration per line convention when I have similar styles and I want to be able to read them in a table format, i.e.
.available {background-color: #0f0;}
.taken {background-color: #00f;}
.deleted {background-color: #f00;}
.foo { x: y; a: b }
.bar { m: n }
.baz { background: blah blah url(xyz.png) top left;
x: y; i: j; }
.foo {
x: y;
a: b;
}
.bar {
m: n
}
.baz {
background: blah blah url(xyz.png) top left;
x: y;
i: j;
}
My screen is wide, my editor is wide, my code is fairly wide, but the standard format for CSS is really narrow. Every time I see the vertical format in my editor, easily 80% of the window space is completely empty, and otherwise useless, and 80% of the CSS is not on the screen and I have to page up and down, or search, to find stuff.
This is a workflow optimization that works for me. It might work for others too.
Most of the command-line diff tools don't highlight changes within a single line, and annotation tools usually work on a per-line basis as well.
I always put universal elements first (body, img, @font-face, etc.), then I just organize it top to bottom by page location (i.e. header, content, sidebar, footer, etc.). I also tab-indent so that elements within another are indented and "contained" underneath, making it easy for me to move from one section to the next. I also write the CSS horizontally, only making a new line for a new element.
I should also note that I'm a n00b :-), so this could be a horrible way to do it.
Also, when having quite a few properties for a selector, it's quite difficult to read when all is on one long line, so I use new lines for each property.
(I actually find the tab-indented elements really interesting and may have to try it on my next project!)
One thing you didn't mention were comments. I've seen some css files with great commenting. For instance, comments at the top that act as an index/table of content for the css file. Very nice!
Generally, these library files will simply contain mixins (reusable chunks of code), so they don't output anything directly into your CSS, but allow you to include the mixins in certain styles. Very useful for adding effects, rounded corners, etc. on different elements.
Keep in mind however, that mixins can be overused, adding bloat to your code. CSS does cascade, after all. You should always look to see if you can separate reusable css rules to include in markup (commonly seen with grid systems). How you balance out the convenience of keeping your css flexible vs. not littering your markup with lots of styles really depends on the project, but it's something to think about.
I have developed one very useful trick while using Sass for managing colors. Instead of assigning colors directly to an element (very hard to track down later if a change is necessary), I create color variables named after the element and attribute in question. Then in my colors.scss file, I build up my color palette, and after, list all the color variables I created in my stylesheets, setting their values to the appropriate color from the palette (with tweaks, if necessary).
// in colors.scss ---
// color palette
$red: #ff0000;
// assign colors to elements
$body-background-color: $red;
// in layout.css, for example ---
body {
background-color: $body-background-color;
}
She used this approach at Facebook (and Yahoo, I think?) to successfully tidy up a huge code base of thousands of CSS files down to a more manageable few.
I attended her workshop at Webstock and since then had a chance to put it into practice on a 'get it up quick' green fields project (http://chchneeds.org.nz). I must say I was really pleasantly surprised at the way this approach just avoids a lot of the pain points, as a web developer/coder (ie not an html/css guru) I so often face when just getting the simplest things to 'work'.
I guess the hardest thing for me to get my head around to was that to make things more modular you had to let go (a tiny bit) of being so religious about 'semantic html' as a requirement for the HTML, but I think its worth it to get your CSS a whole lot more modular and 'pluggable' together.
Still a bit more work to do, IMHO, but I'm definitely going to be monitoring this project closely.
Nicole Sullivan's site: http://www.stubbornella.org/content/
1) Layout and widgets only.
I start with a reset, then layout (block positioning), then widgets. Everything other than layout is a widget. There are no global styles. If there is one of it, it's an ID. If more, it's a class.
2) No (global) element styles! Ever!
No, not even a p { margin: xyz } or a ul { list-style-type }. Every element that cannot be referred to by class / id must look exactly like it would after the reset.
This avoids complex dependency chains where coincidence influences look. Widgets can be moved from one site to another and you actually have to think new widgets through rather than relying on the default values.
3) Avoid classes and id's as much as you can.
Have single base element with a simple but descriptive class name, and then specify the sub-elements.
For example: Instead of “div.content-title” use “#content h1″ (e.g. div#content with a h1 tag inside it).
Basically, design widgets which consist of one base element, and refer to sub-elements via longer expressions. Use indentation to separate sub-elements.
My strong preference is to maximize for human readability (=short dependency chains, descriptive widgets rather than single elements) rather than short CSS. Cascading within widget-scope is fine, but cascading with global styles should be avoided. I find that when I follow these rules, I like my CSS a lot more.
I utilize mixins heavily so I can modulize all my styling and make sure it's included in areas that are appropriate. I've learned this is the only way to handle CSS without styles getting too complicated and accidentally changing something where you didn't mean to.
Example (create a mixin that has certain styles for forms and then include it in a body.wizard page) this way I keep my CSS very dry.
General coding guidelines are horizontal. I recently switched to this. I used to do vertical and indentation but it's very hard to read with big files. I've found that it's a lot easier to read horizontal CSS.
I alpha all my styles from a-z.
stylesheets
- ie.sass
- master.sass
patials
- _base.sass
- _forms.sass
utilities
- _custom_mixins.sass
vendor
- _facebox.scss
The nice thing about sass is that it you can change output format, so you can just include all the external CSS files as partials and automatically output a single compressed files with your entire CSS.
When I work with a designer who uses CSS I use a structure like this:
stylesheets
- master.sass
partials
- _style.scss
vendor
- _facebox.sass
I also have a "colors" partial where I put variables for all my color definitions, such as $light-blue, $dark-gray, and $background-color.
- Have only one CSS-file, unless your project is huge.
- Never use IDs
- Avoid reset CSS (espescially if you can ignore IE6/7
- If you think you need variables (like in SASS), you are probably thinking about it the wrong way
- Give classes functional names, not presentational
- Linebreaks after declaration. (Makes your CSS-file easier to navigate)
- Remember that you can use you media queries inside your CSS-file
Web designer Jens Meiert has some good articles:
http://meiert.com/en/blog/20090401/why-css-needs-no-variable...
http://meiert.com/en/blog/20080515/css-organization-and-effi...
http://meiert.com/en/blog/20070321/css-practice-pseudo-names...
Also, if you just resolve to always use classes instead of ids, then you can eliminate the cognitive overhead that comes with every new selector of, "Should this be a class or an id?".
I do agree on the cognitive load though.
A selected with one ID will outweigh a selector with two classes for instance. This can quickly lead to complexity because you need to use a ID many places in order to override a selector that used ID.
A class only used once serves the same purpose as ID (CSS-wise), expect that you avoid a lot of problems.
I might use IDs for anchor purposes (site.com/foo#section), but I never reference it in my CSS.
I've yet to see CSS code for page layout without the usual awkwardness where margin-left of some element MUST equal some other element's width minus some bar's left offset, yadayada. It's for stuff like this that variables make sense. I wholeheartedly agree that if you need a variable to colour two bars and a heading orange, you're probably doing it wrong.
The blog you refer to only has an example with colours, which is just too easy.
CSS complexity is increasing at a huge rate and the volume of CSS for even a simple site is running at hundreds of lines. Splitting it into separate files keeps it readable and reusable.
Edit: Rephrased to try and better express the idea.
I also had trouble phrasing the idea in a way that didn't sound stupid.
- Almost all CSS goes in 1 big file. One line per selector to keep thinks clean and easy to find. Styles from external sources (like jQuery UI) go in separate files.
- Reset lines go at the top, if you use them, in a / RESET / section.
- Styles for individual HTML tags are next in the / HTML TAGS / section.
- Then a / UTILITY CLASSES / section for clearing floats, etc.
- Next comes site layout. Headers, footers, page width, etc. all go here. Just the layout though - think the grid. No real content styling yet.
- Now sections for each piece in the layout. Content styles go here. First a section for the / HEADER CONTENT /, then a big section for the / PAGE CONTENT / (vast majority of styles go here), then the / FOOTER CONTENT / styles.
Other than that, the best advice I can offer that I DO follow is that I group all HTML elements together, all IDs together, and then all classes together. Within each of those groupings, everything is in alphabetical order.
body { foo: bar; }
form { foo: bar; }
h1, h2, h3 { foo: bar; }
input { foo: bar; }
p { foo: bar; }
#container {}
#footer {}
#nav {}
.etc {}
.even {}
.odd {}
one thing to do is to place class names based on the url with your id's. the class name can be generated from the request_uri (assuming the html code is in a view/template/include).
example: <div id="container" class="contact_us">
then if you need tweaks to a specific page, just add #container.contact_us { foo: bar... }
After reading all comments it seems there is no (universal) solution to write good HTML/CSS code. Not like in Ruby or Python or other programming languages.
Since this year I'm struggling to create a post / best practices how to code front-end but the problem is too complex (for me).
The biggest issue is how to mark up HTML to have a DRY (minimal) CSS. And how to remember easily these mark up rules to be able to maintain anytime in the future your CSS/HTML.
If you would elaborate your naming / marking up best practices instead of suggesting frameworks/tools maybe that would help better.
2. Only use the minimal selectors you need: div#features ul.feature_list li.feature a{color:red;} could be DRYed up to be .feature_list .feature a{color:red;} which will be far easier to override later.
3. Avoid !important at all costs (sometimes you can't, but try).
4. This is personal taste, but I also usually avoid IDs for styling.
5. Grid frameworks (Blueprint, etc.) are usually overkill, but syntax frameworks (LESS CSS, Compass) are fantastic.
It really boils down to experience, and knowing what you DON'T need - most people add in a ton of extra cruft and end up with hard to extend and debug spaghetti.
I have a navigation list which I want to display horizontally as a menu bar. In plus I want to highlight the current element with jQuery.
How to mark up this list? My immediate answer would be this:
<ul id="navigation" class="inline-list">
<li><a href="">...</a></li>
</ul>
The rule for marking up in this case would be:
* use #ID whenever you want to locate an element
* use .class whenever you want to alter the display of an element from the standard
<ul class="main-nav inline-list">
<li><a href="">...</a></li>
</ul>
$('.main-nav.inline-list a.selected').highlight();
//Each time you add another instance, you have to add its new id/selector (not very DRY)
#navigation.inline-list li,
#navigation_b.inline-list li{float:left;}
$('#navigation.inline-list a.selected, #navigation_b.inline-list a.selected').highlight();
The times I use ID in my markup is more for sub-navigation through the page rather that styling-specific reasons.
<h2 id="chapter_two">Two</h2>
<a href="#chapter_two">Got to Ch. 2</a> /* HTML STRUCTURE STYLES */
body { foo: bar; }
h1 { foo: bar; }
a { foo: bar; }
/* Image Replacement & Hacks */
.ir { foo: bar; }
/* Container Styles */
#header { foo: bar; }
#main { foo: bar; }
#footer { foo: bar; }
.column { foo: bar; }
.sidebar { foo: bar; }
.img-cotainer { foo: bar; }
/* Everything inside of #header */
.navigation { foo: bar; }
#header li.nav { foo: bar; }
/* Everything inside of #main */
.content { foo: bar; }
/* Everything inside of #footer */
.social { foo: bar; }
#footer li.nav { foo: bar; }
/* Everything in specific view inside of a container from above */
.profile { foo: bar; }
.comments { foo: bar; }
/* Media Queries */
@media all and (orientation:portrait {
* { foo: bar; }
}
/* Print Styles using Media Query */
@media print {
* { foo: bar; }
}I'll admit it's a personal preference, but as a team consideration I don't recommend the 'all properties on one line' approach. It's discouraged in other languages so why do it in CSS?
Definitely check out OOCSS as well as the Natalie Downe talk both posted by in the comments already.
I can't overstate how highly I recommend Sass/SCSS. It's been mentioned already as "for Ruby". Yes, you need Ruby installed to use Sass/SCSS but you do not need to be working on a Ruby project to use it. You can run "sass --watch (directory name)" from the command line and sass will automatically compile your .scss (or .sass) files to .css files upon save. Even if you're scared of the command line I assure you, it's easy! If you're a TextMate user, there's also a great SCSS bundle here: https://github.com/kuroir/SCSS.tmbundle (it was enough for me to abandon CSSEdit for good)
One thing that hasn't been discussed in this thread yet is the organization of properties within a declaration block. It's a good idea to have an approach and stick with it. Alphabetizing the properties is one approach. I wrote about my preferred approach a couple years ago here: http://fordinteractive.com/2009/02/order-of-the-day-css-prop... (also check out the SitePoint discussion linked in the "Further Reading" section of the post)
Order is: * Reset (only for early IE )-http://developer.yahoo.com/yui/reset/ I find myself using it less and less
* Global Styles - HTML tags - global font faces
* Clearfix - http://www.webtoolkit.info/css-clearfix.html
* Skeleton/Structural Styles - grids/divs/columns
* Headers/footers/persistent styles
* Page specific styles and IDs
* Conditionally load IE Styles if they're required
* load javascript plugin css with the plugin's preferred dir if possible
As for pipelining them, I usually just use a gzipped connection and still serve them individually, since internal image paths for backgrounds rely on the CSS path. CSS caches very nicely, so take advantage of it on the HTTP side.
example: http://code.google.com/p/streeme/source/browse/trunk/web/css...
I always start off with a base which consists of the misc. browser fixes and hacks + basic typography elements, rough blocking. My philosophy on formatting really follows what everyone here is saying. I really prefer horizontal lines and proper tabbing of all the sub elements because its really hard to read otherwise.
While commenting is really good and I like it, finding the proper balance is the key. When you're doing fast iteration it gets really tedious and cumbersome to go back and make sure your comments are in sync.
This is how i arrange my css: http://maderogue.com/public/assets/css/base.css
For bigger project I like to break things down by specific functions & models. (ie. tables, buttons, sorting controls, etc.)
i really like the way jquery ui themes are done.
This gives a max of two css files per page. For the landing page I compress the generic file along with the controller-specific css file for the default page into a single file. This speeds up the loading process while preventing too much bloat. Since the other pages are usually hit after the landing page they require only a single extra download. Any reset code can be included in there as well, although maintained as a separate file.
I doubt this approach is ideal when it comes to organizing things, but it's fairly fast when it comes to development. I design by including css in style="" and then refactoring the markup into classes once the design is complete. Saves a lot of back and forth while getting things lined up.
Using Haml:
%body(class="#{controller.controller_name} #{controller.action_name}")
<body class ='<%= "#{controller.controller_name} #{controller.action_name}"%>'>1) Use as few separate stylesheets site-wide as possible so any contradicting or repetitive rules will be obvious.
2) Use one line per rule so I can scan the selectors quickly, then scroll horizontally if necessary
3) I prefer complex comma-separated selectors which set one or two properties to simple selectors which set many properties. Grouping in this way gets me closer to having constants, e.g. a specific hex color won't be rewritten again and again, it will just follow a complex selector list.
4) Once a selector works, I try to make it more general, e.g. "div.info { font-size: 12px }" can probably just be ".info { font-size: 12px }". More general rules will apply in more cases, so fewer overall rules will be necessary.
I'm going to finally start turning off text wrap. You've opened my eyes to this. Thanks for sharing.
First the global styles, then different things like Header, Navigation, Main Content, Right-hand-side-doodad, Widgets, Footer, etc.
Then create a Table of contents at the top and give each section a unique identifier, FEDCBA-Head, FEDCBA-Nav, etc. Go down to each group and put in a comment saying "Start of Navigation CSS <FEDCBA-Nav>".
Now you can look in the table of contents and do a quick file search on the unique identifier, and be taken right to the CSS you're looking for.
I generally make the table of contents a lot more detailed, and it has an upkeep cost, but it's well worth it when the CSS file gets big.
/* header / .header { margin: 0 auto; padding: 0; width: 800px; }
/ body / .body { margin: 0 auto; padding: 10px; width: 800px; background-color: #fff; }
/ footer */ .footer { margin: 0 auto; padding: 10px; background-color: #EEE; border-top: 1px solid #BBB; }
(this is just an example, assume the classes are for div's)
If I have multiple CSS files, I may just call one (style.css) in the <head> of HTML document. Then within the style.css, I can just make a list of the documents using @import.
((by the way, this didn't come out the way I expected on here))
Then use a per page sass file that references default.sass
If you want something pre-built that does all this use compass.
Within the selectordefinitions I write general definitions like width, heigt, displaytype and position (top/left.. margin, padding) first. Then contentspecific definitions like fontdefinitions. At the end I write border and background definitions.
That way it's an ease to see if an element hast a specific definitions, because I know if I'm looking for the width and the first definition is not the with then there is no width set for this element.
Within the selectordefinitions I write general definitions like width, heigt, display-type and position (top/left.. margin, padding) first. Then contentspecific definitions like font definitions. At the end I write border and background definitions.
That way it's an ease to see if an element hast a specific definitions, because I know if I'm looking for the width and the first definition is not the with then there is no width set for this element.
html-reset.css layout-fixed.css page-backgrounds.css messages.css pages.css blocks.css navigation.css comments.css forms.css fields.css print.css ie.css ie6.css
Drupal's CSS optimization, once turned on, will roll all of these up for you automatically, so if you aren't using Drupal you will need some sort of build system to combine and minimize everything. But I think this is a good start.
On a side note, I really like the method the Zen theme uses for CSS columns. Worth checking that out as well.
This is especially true when you're working either in a team environment or on a large site. The very nature of CSS (and how things cascade down) can become a nightmare when organization isn't taken into account from the start.
1. Using the 960 grid system (or your preferred grid flavor) 2. Grouping by the following:
Body Typography Forms (Other global stuff like links and buttons) /* Layout Element 1 / ID1 {} ID2 {} class1 {} class2 {} / Layout Element 2 */ ID3 {} ID4 {} class3 {} class4 {}
I also write my styles on one line, but that's just personal preference. I find it easier to scan down for the selector, then across for the property I want. I definitely don't do it for aesthetics or file size ;)
- reset (duh) - layout (structural stuff) - typography (general typegraphic styles) - styles (stuff gets prettier than the already are).
As for the grouping o selectors, i try not to reuse much code so cascading will not mess stuff up, i'd rather make big css than fragile css. I also try to group code on a per section basis… just remember i do have a typography stylesheet which makes most of the stuff readable and pretty before the glitz rolls in.
.wrapper { ... }
.sidebar { ... }
.content { ... }
Then @import everything in screen.css.
I use this system for about 4 years and am still delighted on how easy it comes to me. In brief:
- Split up your style sheet according to rule types.
- There are three main rule types that help when split: grid, decorations and fonts.
I think when you find yourself writing nested selectors that are heavily dependent on the HTML structure, it's an indication that your code could be less fragile if you just used the HTML style attribute instead.
Eg. Files would be something like:
* reset * global (eg header/footer) * common (stuff used most places but not all, eg. forms) * specific to section of the site * specific to the page
1. reset.css 2. global.css - reusable classes and styles for common selectors (html, body, a, etc) 3. css named per page (or type of a page) - ex. home.css / about.css / results.css / static.css
* I usually add a class / id to the body and use that as my first selector on the page-level css. This allows me to combine all + minify for production
Personaly i keep everything to do with each area to gether ie. Header, footer, I wouldn't seperate out the <h> &
tags & place all the
's together.
if i'm working on a large site i tend to seperate out the css by section home, Base template (about for example), contact, blog, news, shop...
By simply organizing the structure of the file well, you can have a easy to navigate css file. Of course there may be a few extra style sheets; ie.css, section specific.css, print.css and mobile.css.
Here's my CSS file structure:
-reset
-html tags h1,p,q etc
-header
-navigation
-content
-sidebar
-misc (popups, forms, buttons)
-footer