50+ CSS Best Practices and Coding Guidelines

50+ CSS Best Practices and Coding Guidelines

What to avoid

• In-line CSS
• Absolute font sizes
• Single quotation marks around paths for images
• CSS hacks
• Redeclaring inherited values
• Applying padding/borders and a fixed width to an element.
• !important and position: absolute
• Name classes/IDs based on appearance

Good style

• CSS declarations on one line
• Comment your code
• Organize your CSS file
• Indent as necessary
• Make your code easy to read
• Use a common naming system
• Sort declarations alphabetically
• A ";" is not necessary for the last declaration
• If declaring a unit of 0 px/em/%/... you can ommit the unit
• Keep containers, properties, selectorsand CSS hacks to a minimum
• Group selectors allow you to select multiple elements at once
• There often is a handy shorthand notation
• Shorten hexadecimal colour notation
• Define pseudo classes for links in the LoVe/HAte-order
• Define element’s margin, padding or border in TRouBLed-order
• You can use child selectors
• Make use of different media types
• Name classes/IDs based on function, not appearance
• Learn to exploit the cascading nature of CSS. CSS has sophisticated rules for inheritance of rules
• You can use attribute selectors. Attribute selectors match elements based on the presence or value of attributes
• Change capitalisation using CSS
• Order all the elements belonging to the header, main container, footer ... together for better overview
• Take a look at coding guidelines of big companies
• Seek inspiration from the gurus of design
• Take a look at Blueprint, a CSS framework, a lot of great ideas are integrated and commented

Ease your life

• Use a CSS cheat sheet
• Build and test your CSS in the most advanced browser available before testing in others, not after.
• When in doubt, validate
• Test embedded, launch imported
• Keep a library of helpful CSS classes
• Try out an online CSS compressor, some of the methods that CSS shrinkers employ to squeeze your CSS file size down can be employed in a less extreme way to make your CSS more streamlined
• Get the web developer toolbar for Firefox
• Keep a library of helpful CSS classes.
• Use a CSS framework like 'Blueprint'

Did you know?

• You can assign multiple classes to a given element
• Set constant values throughout a CSS document
• The simplest option is just to include the color value in every rule you want it in, and use search and replace when you want to change it. This is pretty trivial with a good text editor.
• Since an element can have more than one class on it, you can make classes for each constant or variable you want to create, then assign these classes to the (X)HTML elements you want to affect. Since an element can have more than one class on it, this shouldn't interfere with any existing uses of the class attributte. Then if you want to change the color, all you need to do is change the class definition.
• Use a Server-Side Language to Write Out the CSS.
• There are some examples of CSS server side preprocessor languages now. Switch seems to be the most developed
• You can add CSS-styling to RSS-feeds
• You can prevent spam with CSS
• You can offer customizable design by dynamically creating the css file with php
• There are ideas for CSS Design Patterns

If you want to know more about next level of CSS, learn about CSS2 and the best place to do this is HERE (w3.org website - external link).

Hope you find this useful.

 

why not single quotation marks around paths?

 

Thanx mate for the valuable info/guideline. I am new in CSS design and this teach me a lot. If you have more CSS related tips and tricks please share with us.

 

Because they are not required therefore a waste of time and bytes

 

Is this written by you ?

 

The tips are gather by me, and i just want to share with you.
They was useful for me. Hopefully they will be for you too.

 

Some of these I won't do:

CSS declarations on one line <--harder for me to read
A ";" is not necessary for the last declaration <-- but means I don't have to keep track of it when I add or delete properties
You can use child selectors <-- if I lived in a country that used FireFox or Opera in a percentage greater than 1% I would
Change capitalisation using CSS <-- except you can't if people are filling in your form in all CAPS... then you could text-transform: lowercase but you can't Capitalize Their Words (I've tried), so scripting has to take care of that... also, technically, changing an H to an h is changing the content as they are actually two different characters.
Take a look at coding guidelines of big companies<-- usually nasty code, so I look to see what to avoid (there are a few exceptions)

Rest of the list is nice recap. I really saw what I was missing when I saw some design tricks in the Zen of CSS book... looking at others' designs is definitely a good thing, as well as trying to imitate others' designs, as it increases your skills and helps you encounter common bugs or quirks (and thus helps you learn automatic techniques against said quirks).

Waiting for CSS to turn into a language and have variables and do math... because I expect it to some day.

 

I've been doing CSS for a long time but I need to follow this thread,

thank you

 

If you know a lil PHP you can make your css very dinamic and useful for you. But CSS will never turn into a language.

 

In-line CSS - Agreed, should not be done without good cause (like perhaps an image that is best styled as background but has to be assigned to each element different by your SSI/CGI)

Absolute font sizes - Sometimes they are necessary depending on the graphics being used - dynamic fonts over a fixed image is an auto /FAIL/ at intarweb since said layouts end up broken on 'large font/120dpi' machines... good rule of thumb I've found is anything below 12px is a total /FAIL/, and I get squirrelly about fixed sized fonts below 14px... but there's the old addage, if you use fonts BIG ENOUGH IN THE FIRST PLACE it's not a problem. The same goes for fixed width columns - if the column width does not adjust with the font metric, the layout is probably going to break.

Single quotation marks around paths for images - Agreed. Wasted characters, nothing more.

CSS Hacks Should be avoided when possible, but thanks to IE it's not always possible... Though I divide hacks into three categories - variable initialization, safe and unsafe. Variable init is just handling values that have different defaults in different browsers... Safe hacks are things like height:1% - as long as the containing element doesn't have a height declared on it all browsers should treat ANY percentage height as height:auto; so that's safe to trip haslayout since you can feed it safely to all browsers... unsafe is crap like clearfix, which you have to set, reset and ice-skate to get to work.

Redeclaring inherited values Also agreed. You see this WAY too often.

Applying padding/borders and a fixed width to an element - Eh, if you do them at the same time you lose IE 5.x support, otherwise who gives a ****.

!important in a site design with total control - yeah, !important should NEVER come up. If you are working on a site that only lets you try to bend their code using CSS (like a blog) then !important is often the only solution.

and position: absolute This has it's uses provided you are 'upstream' from flow, or working inside a flow positioned element - in those cases you can use it with impunity and never have a problem. The problem arises when people try to use it for things like making their columns or positioning EVERYTHING on a page... on that note position:relative at the same time as top, left, right or bottom should be added since MOST of the time that just causes IE render bugs that could be avoided by just using MARGINS.

Name classes/IDs based on appearance Also very much in agreement on. "LeftColumn" is bad since any GOOD HTML should be able to be completely redesigned from the CSS without even touching the HTML. (see Layout Gala) - as such what you call a leftColumn today might not be the leftColumn tomorrow, it might be on the right or in the middle.

CSS declarations on one line WHY THE BLOODY BLUE HELL DO PEOPLE DO THIS?!?!? Seriously, it looks like shit, you can't tell where one property begins and another one ends, it almost ALWAYS ends up with someone declaring the same property more than once... Who the bloody blue hell thought this was a good idea?!? Probably the same people who don't bother with forced wrapping or use inverse indenting because they don't know any better than to not use 5 to 8 space tabs.

Comment your code - This hinges on what you mean by 'comment' - if you use MEANINGFUL classnames, semantic markup the only things you should have to comment is 'out of the ordinary' stuff. Too often I see shit like:

/* Main Menu start */
#mainMenu {
	list-style:none;
} /* Main Menu End */

Code (markup):

If you don't know how stupid that is, do the world a favor and back away from the keyboard now.

Organize your CSS file - Well that's vague... though I think I agree with the intent... though I might disagree. I like to put my classes and ID's in the order they first appear on the page, but tags that are flat declared before that. I do NOT advocate or understand this rubbish of people separating FAC from Layout.

Indent as necessary - Can you give me a "OH HELL YEAH"?

Make your code easy to read - Uhm, isn't that the opposite of 'one line' and the same as 'indent'?

Use a common naming system - Ayup... camelbacks, underscores for spaces - PICK ONE AND ONLY ONE.

Sort declarations alphabetically - that's often confusing to me, I prefer to list them by type - list/table, dimension, margin, padding, classification, positioning, font/text, background, border - in that order. (though sometimes I'll move border up next to margin and padding if a fixed width is declared since they all add up together)

A ";" is not necessary for the last declaration - But it's consistant and makes future edits easier - especially when cutting/pasting between properties.

If declaring a unit of 0 px/em/%/... you can omit the unit - ayup. I still have trouble with this one coming from 30 years of programming since in some metrics zero is not always zero... but yes, in CSS 0 is always 0.

Keep containers, properties, selectors and CSS hacks to a minimum That last part is redundant, you already said that. The overall advice is good though... and goes hand in hand with:

Group selectors allow you to select multiple elements at once - hence the term 'classitus'... Too often you'll see people do multiple tags in a row all the same tag with all the same class on them, when there's a perfectly good ID or Class on the element wrapping them. Waste of code, nothing more. There is NO good reason to EVER see:

<ul id="mainMenu">
	<li class="mainMenuItem"><a href="#" class="mainMenuAnchor">Item 1</a></li>
	<li class="mainMenuItem"><a href="#" class="mainMenuAnchor">Item 2</a></li>
	<li class="mainMenuItem"><a href="#" class="mainMenuAnchor">Item 3</a></li>
	<li class="mainMenuItem"><a href="#" class="mainMenuAnchor">Item 4</a></li>
	<li class="mainMenuItem"><a href="#" class="mainMenuAnchor">Item 5</a></li>
</ul>

Code (markup):

and yet you see this bullshit all the time.

There often is a handy shorthand notation - Vague, but yes when properties can be shortened to a single property instead of multiple declarations, do so.

Shorten hexadecimal colour notation - #FFFFFF or worse, rgb(255,255,255) - oh hell no. #FFF; is sufficient.

Define pseudo classes for links in the LoVe/HAte-order - I've not heard it called that, and frankly that doesn't include focus and is backwards on hover since most people these days are advocating the order "link, visited, active, focus, hover"... though in most cases there's no reason for the last three to be any different from each-other, and you probably shouldn't be wasting time saying :link since you would just dump all like styles and :link's values on the master element itself.

Define element’s margin, padding or border in TRouBLed-order - Uhm, didn't you say this with shorthand notation?

You can use child selectors Duh.

Make use of different media types - too often you see designers not even THINKING about media types, shoving their one stylesheet at everything. To this I would append it's a good idea to send "projection" the same style as "screen" since some kiosks (usually opera based) report themselves as such. (Opera will do so if you set it for fullscreen operation)

Name classes/IDs based on function, not appearance inverse of the last of your 'avoid' - redundant.

Learn to exploit the cascading nature of CSS. CSS has sophisticated rules for inheritance of rules - Hmm. You're going in circles here.

You can use attribute selectors. Attribute selectors match elements based on the presence or value of attributes - Yes and no, depends on what attributes and if you care about the page being broken in IE.

Change capitalisation using CSS - depends... do you care about degredation with CSS off?

Order all the elements belonging to the header, main container, footer ... together for better overview - Again, you said this already just in a different way.

Take a look at coding guidelines of big companies - given that the big names (amazon, eFence, Google) are still a decade behind on their code, this isn't the greatest advice.

Seek inspiration from the gurus of design - Vague, and a matter of taste... I'm wary of some of the so called 'gurus' because it wasn't until I stopped listening to them and started THINKING about my designs instead of blindly following others lead that I got any sort of 'progress'.

Take a look at Blueprint, a CSS framework, a lot of great ideas are integrated and commented That steaming pile of shit isn't worth the time of day. Multiple inlined imports, directory tree hell, redundant properties, poor or nonexistant property condensing, it's more a howto of NOT to make CSS. Hell, the examples for it and most pages in it violate MOST of the things discussed so far.

Use a CSS cheat sheet - That's why I like Opera's sidebar, I'm able to keep a list of CSS properties open in it for when I forget lesser used properties.

Build and test your CSS in the most advanced browser available before testing in others, not after. WRONG. You should be testing in ALL BROWSERS at the same time - or should I say the relevent versions of said browsers. Right now I test my pages in Opera 9.24, 9.5 beta, Firefox 2, Safari 3 beta, and IE 5.5, 6 & 7... and by test I don't write the whole page then test, I style a small section, I test in all the browsers, I write another small section, test a small section - lather rinse repeat. Coding to just one browser then running around like a chicken with it's head cut off for silver bullet fixes to get around code designed for just one browser is stupid - yet seems to be the most commonly advocated practice. See the rabid "code for Firefox, hack for IE" mantra which is much akin to saying you play both kinds of music - country AND western.

When in doubt, validate - Ayup. Also get familiar with what warnings and errors are total bullshit you can ignore (ooh, you didn't redeclare color with your background declaration), and which ones are not. (hey dumbass, you forgot a semi-colon)

Test embedded, launch imported - I disagree with this first because the standalone versions of IE often render inlined CSS different from imported (that one can drive you NUTS) and second I like to see my HTML side by side with my CSS, so I keep each open in a separate editor window... Which is part of my distaste for tabbed editors since they don't tend to like to let you do that, and the ones that do generally restrict it to one window meaning if you have a GOOD development workstation you can't split them between displays. Usually for the base layout I'll keep it embedded, but once I start dealing with the inner workings I split it right out.

Keep a library of helpful CSS classes - Yes and no. This often gets taken to absurd extremes which leads to trying to shove a square peg into a round hole. It can also lead to one's designs getting 'stale'.

Try out an online CSS compressor, some of the methods that CSS shrinkers employ to squeeze your CSS file size down can be employed in a less extreme way to make your CSS more streamlined - yes, but be sure to keep a uncompressed 'development' copy handy... and frankly most of the time if you keep the markup clean and the css minimalist, the compressor will only net you 200 bytes... if a compressor nets you more than 1K, you probably have major issues in your coding style in the first place.

Get the web developer toolbar for Firefox - useful for getting resolution and determining filesizes, the rest of it is REALLY overrated... Though nowhere NEAR as overrated as firebug (which I found more annoying than helpful)

Keep a library of helpful CSS classes. - You said that.

Use a CSS framework like 'Blueprint' - OH HELL NO... and you said that already.

You can assign multiple classes to a given element[/p] - Something I know experienced coders who don't realize it.

Set constant values throughout a CSS document - Uhm, CSS doesn't HAVE constants... or do you mean something else?

The simplest option is just to include the color value in every rule you want it in, and use search and replace when you want to change it. This is pretty trivial with a good text editor. - just be wary of changing elements you don't want to change - sometimes if you have two sets that MIGHT be different, but are the same for now you can make the two values 1 apart on the blue channel, and the user will never see the difference (since the blue channel has 200-300% the range the human eye can see). For example: #FF0; and #FFFF01; - you'll NEVER see the difference, but it lets you differentiate in the code if desired.

Since an element can have more than one class on it, you can make classes for each constant or variable you want to create, then assign these classes to the (X)HTML elements you want to affect. Since an element can have more than one class on it, this shouldn't interfere with any existing uses of the class attributte. Then if you want to change the color, all you need to do is change the class definition. - and kiss separation of content from presentation goodbye - this violates half the stuff in your first two lists - Whiskey tango foxtrot?

Use a Server-Side Language to Write Out the CSS. - and why the HELL would you do that? Waste processor time, two or even three file accesses and memory on something that SHOULD be static? Sorry, but that's just plain stupid... ESPECIALLY since php NEVER returns a 304 code, so sending css via php means it NEVER GETS CACHED - defeating ANOTHER of the reasons to use CSS in the first place. At that point you might as well say '**** it' and inline everything.

There are some examples of CSS server side preprocessor languages now. Switch seems to be the most developed and such a waste it makes RUBY look peppy.

You can add CSS-styling to RSS-feeds defeating the point of RSS and making most RSS clients hate you, or have to spend more time stripping your crap out.

You can prevent spam with CSS - ok, this one I've GOT to hear.

You can offer customizable design by dynamically creating the css file with php - Yes, but be sure to have the php write a .css file - NOT have it run every single iteration as that's just stupid and wasteful.

There are ideas for CSS Design Patterns that has to be the most vague statement on the page... What the hell does that even MEAN?

 

are we just talking about colours that can be shortened to 3 digit hex notation?
otherwise i'm pretty sure there are 16^6 - 16^3 = 16773120 fewer colours available when changing from 6 digit to 3..

i don't know though.. maybe there is a 3 digit equivalent to #ABCDEF? or maybe we've decided there is no need for so many colours?

 

Thanks deathshadow for your review, i really enjoy reading it.. i noted down some of your opinion.
You wanted to know about Preventing Spam with CSS, well you can read about an example HERE (modernbluedesign.com - external link).
Hope you find it useful.

Jamie18
Hexadecimal colors come in two flavors: RGB triplets and shorthand. So instead of this:

.orange {color:#ff6600;}
Do this:
.orange {color:#f60;}

Nearly all browsers (version 3 and above, except IE3 Mac) support shorthand hex colors. RGB triplets can be abbreviated if each of the Red, Green, and Blue hex pairs are the same. So when you use colors where there are three pairs, you can abbreviate each color channel using one character instead of two identical characters. So this:

.dark-yellow {color:#ffcc00;}
Becomes this:
.dark-yellow {color:#fc0;}

Browsers automatically expand these three-character colors into six by replicating the R, G, and B values. This technique saves a few bytes for each color abbreviated with shorthand hex notation.
Here`s a short list with some Color Equivalents
Color Hex Pair Short Hex
Aqua #00ffff #0ff
Black #000000 #000
Blue #0000ff #00f
Fuchsia #ff00ff #f0f
Gray #808080
Green #008000
Lime #00ff00 #0f0
Maroon #800000
Navy #000080
Olive #808000
Purple #800080
Red #ff0000 #f00
Silver #c0c0c0
Teal #008080
White #ffffff #fff
Yellow #ffff00 #ff0

Hope you find this useful.

 

http://www.w3.org/TR/2002/WD-css3-color-20020219/#css-system

^ do these not qualify as constants? or maybe I'm mixing up the definition with keywords... but aren't they the same thing?

 

Just because you can't read it doesn't mean it's shit. It's easier because everything is on the same page, no scrolling up and down for days to find a single value that needs changing. Even on a big project, there is minimal scrolling. It's easy to find ID and class names, just skim down the left side and it has them all.

Easy like pie

 

It's easy to read for the original developer, but if ever/whenever you need help it will be a pain to anyone else reading your stylesheet (unless it's listed by something like Firebug).

 

The best answer you can get in this matter i think is HERE.

There are some things that every developer choose how would they be and this are the best for him or his team.

 

Assuming you turn word wrap off - in which case you have to scroll for the properties, a royal pain in the ass.

Somehow I don't have that 'issue' in my CSS, but then I tend to put elements in the order they appear on the page and/or page/subpage matching the menu, and indent so the classes/ID/Tagname stands out.

You let it wordwrap, you can kind of see all the properties but good luck actually figuring out what properties are declared - conversely you don't let it word wrap and you can't even SEE the properties. /fail/ /fail/

It's cute for short examples like the one you had, but if you were dealing with say this:

#container {
	min-width:740px;
	max-width:992px;
	margin:1px auto 1em;
	overflow:hidden;
	position:relative;
	text-align:left; /* return to normal behavior after IE fix*/
	background:#FFF;
	border:1px solid #000;
}

Code (markup):

As a single line it SUCKS.

#container {min-width:740px;max-width:992px;margin:1px auto 1em;overflow:hidden;position:relative;text-align:left;/*return to normal behavior after IE fix*/background:#FFF;border:1px solid #000;}

Code (markup):

The only pie that would be is mud. Worse, most of the time I see people format their CSS that way, they end up declaring the same properties multiple times because even THEY can't read their own code despite claims of being able to do so...

It slows development to a crawl because you cannot clearly see where each property begins or ends, much less WHAT properties are actually declared.

 

Ah, that one - good luck with it since most spam targets specific forms or specific softwares, so adding something like that only protects you until the spambot catches up.

You also have the issue said technique does NOT degrade gracefully to non-css, making it something that should not be used if you care about accessability.

 

I don't really want other people to be going through it.. if they can't edit CSS properly, odds are they shouldn't be editing anyway

Even multi-line its easy to read, its like a book (or maybe I'm just the weird one who reads books left to right, top to bottom)

Doesn't make it any slower, and its easy to read (and therefore see all the properties and their values)

My elements are arranged the same way, using defaults, header, body, footer.. and then elements within the those headings are sub-indented so its easy to find something such as a search box or whatever the case may be.

 

Never had any problem reading or writing in both styles

From what I've read IE5/Mac chokes on single quotation marks. Nothing other than that.