Top CSS Tips

I thought I'd share some of my habits when it comes to doing CSS work and let me warn you, some of what I have to say is probably a little controversial. But what's life without living it on the edge. (Yeah, I live an exciting life when CSS is considered 'the edge'.)

px for font sizes

Sacrilege, I know. There are perfectly good ways to get consistent font sizing and I really should use them but Internet Explorer is the only browser that I can think of that doesn't resize text. If the majority of your audience uses IE, then be nice to them and don't use pixels. Otherwise, I figure with IE7 supporting it, pixels are the new ems.

When using pixel sizes, I also get to be sparing in my usage. I specify it on the body and any headers that need it. Inheritance is less of an issue (how many sites have you seen list items inexplicably smaller than the rest of the content like it was less important).

CSS declarations on one line

I've always put my entire declaration on one line. Here's an example to explain what I mean:

h2 {font-size:18px; border:1px solid blue; color:#000; background-color:#FFF;}

h2 {
   border:1px solid blue;

The second one may look prettier but it sure doesn't help me find anything. When looking for something in a style sheet, the most important thing is the ruleset (that's the part before the { and } ). I'm looking for an element, an id or a class. Having everything on one line makes scanning the document much quicker as you simply see more on a page. Once I've found the ruleset I was looking for, find the property I want is usually straightforward enough as there are rarely that many.

Blocking the Styles

I break down my style sheet into three separate blocks. The first is straight element declarations. Change the body, some links styles, some header styles, reset margins and padding on forms, and so on. This is usually a small block as I only like to redefine what I need to. No global margin and padding reset for me. I clear the body and form and maybe adjust paragraph if the design really needs it. Otherwise, let the browser handle it. I find the more you try to override what the browser does, the more styles you have to put in, which simply adds to the time to track down bugs and maintain the code.

After element declarations, I have my class declarations; things like classes for an error message or a callout would go hear. I usually only have a couple of these.

Finally, the meat. I start by declaring my main containers and then any styles for elements within those containers are indented. At a quick glance, I can see how my page is broken down and makes it easier to know where to look for things. I'll also declare containers even if they don't have any rules.

#content {float:left;}
   #content p { ... }

#sidebar {float:left;}
   #sidebar p { ... }

#footer {clear:both;}
   #sidebar p { ... }

Browser Support

Support only the latest browsers. That means dropping support for IE5 and IE5.5. Lots of time and effort to be saved here. No box model hacks needed for IE6. In fact, in supporting just the most recent versions of browsers, I end up using very few hacks. Along with using very few hacks means I can avoid shovelling different style sheets to separate browsers. I have one sheet, and that's it. Any hacks I do use are normally commented as such. Similar to the use of pixel measurements, you have to consider your audience before dropping browser support.

The biggest thing for me is still triggering hasLayout in IE to do float containment and I've been using zoom:1 for that. I like it because it's innocuous and shouldn't mess with anything else.

Containing Floats

I just touched on float containment so let's expand on that. My current approach to containing floats is using overflow:hidden (with possibly zoom:1 for Internet Explorer). No clearing div or use of :after. Only worry about containing your floats if you have a background you are trying to set on your container. The overflow should be set on the container.

Keep in mind that the content within the container should be designed to stay within the container. Anything too big and it'll get clipped. Shifting things using negative margins outside the container will also get clipped.

Understand Overflow

Overflow is usually where people get bit by IE. If you've got two floated elements and the content from the left container overflows then, in IE, the container grows and inevitably pushes the right container below it. This is usually a sign that you've messed up your margins, widths, or padding on one of these containers but Firefox (et al) won't reveal this. Using something like overflow:hidden or overflow:scroll on a container can help prevent IE from allowing the content to push the width of the container but you're better off trying to fix the issue in the design.

Allow Block Elements to Fill Their Space Naturally

My rule of thumb is, if I set a width, I don't set margin or padding. Likewise, if I'm setting a margin or padding, I don't set a width. Dealing with the box model can be such a pain, especially if you're dealing with percentages. Therefore, I set the width on the containers and then set margin and padding on the elements within them. Everything usually turns out swimmingly.

Use CSS Shorthand

This might seem like beating a dead horse but I still see people doing really verbose statements where they're setting margin-top, margin-right, margin-bottom and margin-left. My general rule of thumb is, you can use the long form only if you're setting one side. Once you have to set more than one side, it'll take less bytes to use shorthand.

In shorthand, remember that the properties start at the top and work clockwise. margin: top right bottom left; It's also handy to know the shorter forms if you have equal values for top and bottom or left and right.

margin: 5px 10px 20px; /* top left/right bottom */
margin: 10px 20px; /* top/bottom left/right */
margin: 0; /* all sides */

For border, if you only have to set more than one side differently then use two declarations. The first to set all sides, and then a second to change the values for one of the properties.

/* 1px blue border on the left and bottom */
border:1px solid blue; border-width: 0 0 1px 1px; 

Avoid Unnecessary Selectors

Just specify the minimum number of selectors necessary for the style. If you find yourself doing ul li {...} or table tr td {...} then you're being more verbose than you need. LI's will inevitably be in UL's (okay, I suppose they could find themselves in OL's, in which case, be more specific for those styles) and a TD will inevitably be in a TR and a TABLE.

Or putting the element name in front of an ID selector (Example: div#navigation). I used to do this because it'd help me "remember" which element the ID is on. As it turns out, I tend to use similar class names from project to project and they inevitably appear on the same elements. I also tend to just do a search to find where something is. So, these days, I just leave it at #navigation.

Using less selectors will mean less selectors will be needed to override any particular style — that means it's easier to troubleshoot.

Keep it Simple

If it hasn't been evident throughout this post, only add when you need to, and that includes hacks. No need to get any more complicated than you need to.

Now, I'd love to hear some of your tips.

Published September 20, 2006
Categorized as HTML and CSS
Short URL:


116 Comments · RSS feed
Miles Johnson said on September 20, 2006

That was a great read, even though I do do many of those things already, its good to let other people know. I did learn something new though, about margins... 0px 0px 0px... I didnt know you could do that and have it top left/right bottom. Thats a great one to know. :]

kimblim said on September 20, 2006

Regarding the font-sizes:
I know that it is considered "bad habit" to use PX, but why is that? What if the designer behind the site actually wants a heading to be exactly 24px? Then use PX..

Sometimes a sites design is as important as its usability and accesability - not often, but sometimes, and why shouldn't you use PX for these?

rich said on September 20, 2006

Some great points but I have to say I much prefer my CSS declarations well-spaced, at least while I'm developing.

It's just easier for me to scan vertically than horizontally, especially with rules with many attributes which can lead to horizontal scrolling. Good reasons to avoid that as we know from designing pages :-)

Horses for courses though, and good call on pixels. Hopefully as IE6 drops in popularity as IE7 is adopted we'll be able to use them more often.

George said on September 20, 2006

'Support only the latest browsers.' IE5 still has around 5% of the market so I'm not dumping it until IE7 comes out.

Yes the box model is an irritant but one I am prepared to accept for 5% of my audience.

Most of the time you can limit box model hacking by applying padding and margins to elements within the div rather than the div itself so it is not too much effort.

A couple of months after IE7 is out and if the stats for IE5 are lower I'm dumping it too though!

Fredrik Wärnsberg said on September 20, 2006

I tend to agree with you on almost every point. I've never tried the zoom:1; property combined with overflow:hidden; for floats though, so maybe that's something to try.

I also couldn't agree more with you about declaring the css on one line, it makes it so much easier to find the element you wish to modify (even if other people seem to get annoyed by it).

Phil Nash said on September 20, 2006

With regards to font-sizing, and I'm sure you knew you would take some stick for this when you wrote it, I follow Richard Rutter's method of thinking in pixels but coding with ems. It makes sense to me anyway.

Also, putting CSS delcarations on one line doesn't work for me either. The pretty method is the one I use as I can easily search for the element, id or class I'm looking for then instantly see all it's attributes, rather than see all the elements and have to scroll or read long lines to find the attribute I need. Still, whatever works for you!

I definitely need to work on a logical stlye for setting out my CSS files though, reading my code is embarrasing at the moment. I might gove your one a go.

Thanks for the tips though!

Nate K said on September 20, 2006

RE: PX for font sizes
Unfortunately, for several sites I work with IE6 still has a strong hold. I know its nice to have pixel perfection, but for my cases I cant make the move to sizing with pixels. I will use a base font and percentages after that.

RE: CSS Declarations on one line
Though I agree with everything you said, I take a different approach. Instead of trying to work on a project with it all on one line (sometimes its NOT the selector I am looking for), I work on spaced out versions - with indenting and shorthand. I also separate my styles into 3 sheets (have been doing this for a while): typography, colors, and layout. Keeping these separate makes it much easier to find what im looking for. Now, before it gets sent to the client I use PHP and a rewrite to join all three files, remove all the comments, and then remove extra spacing inside of the declarations. So, the client can get the compressed version while I can still work on my version on the backend. I am still working on combining styles with the PHP as well, but for now it simply joins colors, typography, and layout into one sheet for the request.

RE: blocking the styles
As said above, I agree with you completely here. However, I think zeroing out margins and paddings helps overall. Especially since some browsers assign different padding to different elements. So, if you went with the default (especially for form elements), then you would most likely get inconsistent results. IF I do zero out everything, my first block sets some defaults that I would use to override (for lists, paragraphs, and headers).

RE: Browser support
Again, for the majority of the sites I work on - I have dropped support for IE5/5.5 (Mac/PC), as well as NS4 (a given). I have never believe that hacks were the best way, so I avoided them if I possibly could. I have used the same method where I dont apply margins/paddings on the containers - but on the containing elements.

RE: allow block elements to fill their space naturally, use css shorthand
I have addressed these above, I agree with you completely on both aspects.

RE: Avoid unnecessary selectors
I think depending on the project it can go both ways. This is why you should plan out your project ahead of time (a given). So, there are some styles that you want to be available in any given container, and there are some for specific parts. Make sure you plan for this and understand how the cascade will affect your declarations. I do agree that there is no need to be so verbose - its just added markup and makes for a tougher time troubleshooting (in my experience).

soxiam said on September 20, 2006

Nice write-up. The only one I personally disagree with is CSS declaration in one line. The reason for me? It's so much harder to notice missing semi-colon at the end of each property that way. And I think we've all experienced pulling our hair out over CSS classes that don't work only to realize that the property wasn't closed correctly.

Jason Kataropoulos said on September 20, 2006

Thank you very much for your tips.

One thing that I tend to do is to use one global CSS file in my HTML page and then import the rest in that one. I tend to split the CSS classes and definitions in a logical way. For example I differentiate the structure styles from font formatting styles in different files.

Jeff S said on September 20, 2006

Regarding font sizes - I tend to put a font-size on the body tag with value: 62.5%. This allows you to use EMs to specify sizes while thinking in PX terms, e.g. 1.3em is approximately 1.3px. Try it out, it's pretty close. Now, if you don't have some sort of container to specify the base font size (e.g. 1.3em) for the child nodes to inherit, it's a pain, don't use it. If you do, like in a fixed-width design (e.g. div with id="wrapper"), you can think PX while using EM.

Ed Eliot said on September 20, 2006

I personally think we're some way off using px for font specifications. Even on very technical sites the IE 6 percentages are generally very high.

For containing floats I've traditionally used the easy clearing (:after) method or simply floated the container (some side effects, but ok in most situations) but I've started looking at using overflow:auto; zoom:1. This overflow method seems to work in all bar IE 5.0 which is cool since I'm no longer concerned about it.

The things I'd add to the CSS shorhand section - always shorten colours where possible #f90 instead of #ff9900 and never specify units when the property value is 0.

stephen said on September 20, 2006

I also find "em" interesting for font-height. It allows for the 98% of IE users who want to be able to change the size of their fonts - but in true IE form, "em" brings up a whole lot of font-type problems

Declarations in one line? Interesting. One problem: CSS Validator does not know you have your editor settings on "NO WORD WRAP". So when it says there is an error at line 22, it might be line 9. So you have to go hunting for it...
Which is why I am happy to keep doing the good ol'fashioned attribute-per-line method.

Style-blocking Elements, classes, custom is definately a good idea. My first designs had 2 style sheets - skeleton.css and skin.csss. The reasoning was good, but The practicality brought up headaches very quickly!

Indenting the styles for an element is a great idea. I now do this more often - it certainly makes it easier. Style-section-titles also helps.

Dropping supporting for lower-end browsers is OK. Not having hacks is almost impossible. As more and more people use Mozilla Firefox as their preferred browser, the tantek box model hack becomes a necessity.

Contained floats has some advantages. It allows multiple background imagery. Ok, so its slightly tacky, but if used effectively can reduce the amount of imbedded imagery.

Your method for avoiding the tantek hack (width vs padding/margin) is like a slap on the forehead. It makes perfect sense.

I encourage CSS shorthand wherever I can. I managed to shave 1.5kbs of a 5kbs CSS recently using shorthand. Where the previous editor had defined every single margin-width, I shortened to a one line decleration.
Your suggestion for border-width decleration is the newest change to my CSS writing. I tested and tried that a month ago with amazing online-life-changing results.

This is my only conflict: To say a selector is unneccesary is not necessarily correct. For instance I might have a drop menu that expands to a 3rd directory. Therefore #navigation ul li ul li ul li is going to make sure that third li gets the color and style I want for it. If I only define one of them... well, you can imagine the consequences.

Jeff Croft said on September 20, 2006

I'm with you on pixels for font size. I don't always use pixels, but I certainly don't feel bad when I do. As far as CSS is concerned, there's nothing wrong with pixels at all. The only reason people avid them to to work around one quirky browser's mishandling of text resizing.

As for CSS declarations on one line: I find that harder to read, but if it works for you, more power to ya.

I like the idea of blocking the styles, and I've tried to do it myself -- but usually found I'm not meticulous enough to stick with it. But I think it's a great tip for management of CSS rules.

I think browser support question have to be answered on a site-by-site basis, but generally I'm with you -- I don't spend a lot of time worrying about IE5 and 5.5.

Nice post, Jonathan!

Jonathan Snook said on September 20, 2006

George: 5% for IE5? Ouch. Don't these people realise they're using a browser that is fast approaching 10 years old? Give 'em a nudge into the new millenium!

Putting everything on one line: I usually only have 4-7 styles defined per element so horizontal is just as easy for me to scan. Stephen: For the CSS validator, it tells you what line AND what property is incorrect so it's still easy to find out what's messed.

Multiple CSS files: Because of my minimalist approach, my files rarely push above 10k. Separating that into multiple files just seems wasteful. It's taking longer for the browser, having to request multiple files instead of just one.

Stephen: your ul li ul li ul li example could easily be shortened to li li li. See how the UL is superfluous?

Thomas Messier said on September 20, 2006

Nice, I use a lot of those and learned a bit as well. One very basic tip that beginners may not know is the ability to apply style attributes to multiple elements/classes. So when you have 2 very similar elements (say a blue button and a red button that have same height, width, font, etc.), you don't have to rewrite everything, just specify the colors. Sometimes, I take it a step furter and specify the same color for both so I only have to add one more rule overriding the color for one of them. Not sure it's good practice, but saves me time and makes the file smaller.

Nate K said on September 20, 2006

RE: test
Multiple CSS files. Who said it had to take longer for the browser? With PHP - I can build a compressed version of my stylesheets. That compressed version doesn't have to be built on the fly. I can build it whenever I want - and then it is just like a regular stylesheet, minus the spacing, indenting, and comments. So the browser is getting a neat and tidy version (cache control if necessary), while I can still work with the separation on the backend.

jonathan snook said on September 20, 2006

Nate K: You're absolutely right. :)

beth said on September 20, 2006

I enjoyed this article, but I have to question not supporting older browsers. There are some places where I think this is fine, but a lot of public/non-profit sites will be mainly accessed on public computers, which often use dinosaur browsers.

Unfortunately also, at the agency I work, a lot of our clients are using crap browsers, so we have to design with them in mind even if most of their audience is using something relatively up to date.

Nate K said on September 20, 2006

I change my last post to say RE: jonathan snook - hehe. For a short time it came through as 'test' - even though I knew it was you.

So, what do you say? hehe.

Andy Kant said on September 20, 2006

I might have to try out the single line CSS declarations, I never thought of the scanning for selectors thing.

However, like others here, I would prefer scanning vertically rather than horizontally. If I really need to see all element selectors at once, I could probably just use my IDE (SciTE) to collapse all of the declarations which has the same effect as single line but still allows me to view the attributes in a more readable format.

kimblim said on September 20, 2006

I also use more than one css-file, but that's because I work on a large corporate site all the time, and a page like the frontpage doesn't need all the styles from an article and vice versa.

For the site I work on it is extremely important that the files are as lightweight as possible, and when dealing with 6-7.000 pages, there are a lot of styles, that needs to be seperated into local css-files.

rich said on September 20, 2006

That's a good point Andy. Textmate also allows you to close blocks of code as well so you could have the best of both worlds.

Nate K, is there a more detailed explanation of how you do your CSS with PHP? I'd be interested in reading it.

Elliot Swan said on September 20, 2006

I often use several selectors (I also usually place the element name in front of the id or class), as it helps me see where things are without having to view the source.

Sometimes I'll find myself coming back to a project a few months later, so being able to look at the progression of elements to see how I got to this specific one can be quite helpful.

Though, since you indent your code according to order in the source code, that does much of the same thing.

Nate K said on September 20, 2006

RE: rich
I will give some more information soon. For some, CSSTidy will work, for others they can use Gzip compression. Personally, I have something custom I use for my projects that lets me input the 3 different css files, then using regular expressions it parses (this is still a work in progress) the CSS, cleans it up, then writes it to a default.css file.

The downside is having to recreate the CSS each time, but the benefits far outweight the downsides. Also, I use gzip compression with all of my pages - so its an added layer on top of that.

Ill do a simple writeup of how I do it. There are many different ways, this is just my preferred method and is working well for my needs.

Colm said on September 20, 2006

At the beginning of the CSS I would tend to put the following:

* {
margin: 0;
padding: 0;

This will remove any padding or margins that are added by default by the browser.

For form element, they don't tend to resize as well as text so I tend to just add in

input, select {
font-size: 100%;

PS: This commenting is very slow I type a word and it takes 30 seconds for it to appear - Using firefox 1.0.4 on OS X, there also seems to be errors popping up in the Javascript debugger.

Jonathan Snook said on September 20, 2006

Colm: I avoid using the global reset for the very reason that you mention. Suddenly you're adding styles to override other styles. It's just easier for me to leave things as-is.

As for the slowness, it seems isolated to Firefox/Mac (even in 1.5). Still unfortunate. Sorry about that. I wonder if Camino suffers the same?

jz said on September 20, 2006

I'd add one more rule: put css in about 3-4 files
1. global style and positioning (widths, floats, margins, paddings, inline/block, etc..)
2. visual style (font-sizes, line-heights, etc)
3. color style - to let me easily group color rules (I don't like doing multi-replaces when my client says 'make that orage a bit more orange). It also makes testing various color-schemas easy - you simply load one another file.

IMO it builds a nice hierarchy of style and makes your life easier in commercial projects

4. administration panel additional styles (they don't have to be loaded on the client-side)

What do you think?

Jonathan Snook said on September 20, 2006

jz: For web sites, I stick to one file. My files really don't get complex enough to warrant more than one. In the case of web applications, however, some pages may need a number of styles, usually for specialized form layouts and what not. This applies to admin panels as well. These would get specialized stylesheets just for them.

Kumar said on September 20, 2006

px >> agreed; although my friends will shoot me...

browser support >> agreed; supporting onlder browser supports older habits, and using IE is a bad one =P

great read!

Lamby said on September 20, 2006

Re. CSS all in one line

If your editor could do folds, then it would be okay ;-)

Sam said on September 20, 2006

I think this post is useful not only for newbies but for advanced users either. While creating CSS sometimes we even do not think about the structure of it etc. Thanks for sharing. It was really helpful to read.

rich said on September 21, 2006

Jon, Camino suffers a bit as well i noticed yesterday, but seems ok today. No idea why. I've not got so many apps open though.

When working on templates to hand over to server side developers it can be good to put styles for CMS editable areas and forms into a seperate stylesheets to keep things clear as possible.

Also recently we've been working with .Net developers and found they prefer us to avoid using ID to style forms and controls due to limitations in .Net (more to do with Visual Studio I suspect) so we've been sticking to classes and tag based rules for forms.

SEO Position said on September 21, 2006

Great read Jonathon. I've found that since I started using single line CSS declarations as you mentioned in your tips above that I can reduce the actul lines of cose in my CSS file by 20, 30 lines or more. I agree with the overflow comment though... IE burns me every time.

Andrew Herron said on September 21, 2006

PX: I have always used pixels for my font sizes and have never had any regrets. My computer screens works in pixels, not ems.

Single Line Declarations: This is almost definately the preference of the developer, or the mandate of the bossman. Using more than one line makes reading the code very easy, for the sake of more bytes. I use vertical formatting, but if I'm creating a rule that has only one property, I'll use a single line.

Blocking Styles: Awesome tip. I try to block mine but not in the same manner. I'll be putting this method to use on my next project and see how it affect my ease of readability.

Browser Support: I fully agree. People continue to use what they have because they've not been given enough of a reason to switch. We as developers have the most power to give them that reason. They don't know that they don't know, so it's time we put them in the know.

Floats, Overflow, and Box Fill: Where was this post 3 months ago when I almost went bald?

Shorthand: Is there really any reason to not use shorthand when you can? I've come across some people who prefer the verbose, but most of the time it's because they're copying/pasting code rather than hand typing it.

As for using multiple files, that's only an option when you're going to be reusing specific rules on different parts of the site. Other than that, it just seems like you'd have to have one more thing open in your editor.

Jeff J. Snider said on September 21, 2006

I wish a lot more people would write posts like this. I absolutely love reading about how other people do things, and between this post and the comments, I have come across a thing or two that I am very interested to try in my projects. This sort of thing is, in my mind, what online communities are all about.

Regarding file size, how many bytes is a line break and a tab? Is it really a big bandwidth saver to put all your rules on one line? (I realize that the original post didn't mention bandwidth at all as a reason for doing things this way, but a couple comments have mentioned it, so I want some clarification.) I guess I could find out for myself by taking one of my stylesheets and removing the line breaks and tabs and comparing file sizes.

Jonathan Snook said on September 21, 2006

Your mileage may vary when it comes to file size and some of it depends on how your editor handles indenting.

Here's an example: you have one declaration where you set 5 different properties. Each property is on a new line and indented 4 spaces. Each line break and indent is 5 bytes (6 if you're on Windows using an editor that puts both new line and carriage feed characters). That's 30 bytes used for clarity (I'm assuming your closing } is also on a new line and indented.) That's just for 1 rule. If you have a 100 rules (this site has about 150), then that's 3KB you've used.

So, for me, not only is it easier for me to use, it also saves me space. Although, as Nate mentions above, other things can be done to minimize file size.

Andy Kant said on September 21, 2006

I didn't even think about the size wasting with my CSS...I don't have my editor convert tabs to spaces but I'm still wasting up to six tabs on a line. One of my websites totals up to around 750 lines with 3-5 wasted bytes per line (more if using IE). Thats a special case though (AJAX powered online multiplayer game). Maybe I'll have to consider using a compressor for production.

Thomas Messier said on September 21, 2006

I think that the file size aspect really dependes on your site/application. To give an example, I tested it for one of my stylesheets that was 6.6KB, with rules on multiple lines and each rule separated by a blank line. I put each rule on one line, without leaving a blan line between rules (which makes readability poor). The file ended up at 5.13KB. So I got it to 1.5KB smaller. Is it that big of a deal? Depends. If you have a site that gets millions of hits a day, it adds up. If you have a size with limited traffic, then I guess it's not nearly as critical. Personally, I liked the tip a lot more for its presentation aspect than any file size advantage. I want to try it out to see if I prefer scanning through that way, I suspect that I will because when you have 400 lines to scan through. Sure, you can search, but even having to search gets annoying at times, you just want to look and find.

Caesar Tjalbo said on September 21, 2006

N00b questions from a CSS n00b: does font size in pixels behaves the same on different platforms? (It's a long time ago since I've been close to a Mac)
Wouldn't it be better to define no size and leave it up to the visitor's browser, with percentages > 100 for the H's?
I'm working on my first site and this seemed a 'logical' approach to me: don't assume or force too much, it's not your browser.

Thx for the insights, I loved reading it!

Jeff J. Snider said on September 21, 2006

Just an FYI on the bandwidth question. I just took a huge stylesheet from a project I worked on, and I changed the format from having each property on a new line (about half used 4 spaces to indent, the other half used one tab, due to several people working on it) to having all properties for each declaration on one line. Here is what I discovered:

1) I reduced the number of lines of code from 1,212 to 204.
2) I reduced the file size from 24.7 KB (25,364 bytes) to 22.7 KB (23,297 bytes). That is an 8.2% savings.

Obviously, it will be different for each person, depending on the size of the stylesheet, the number of properties per declaration, etc. But based on this, it looks to me like bandwidth may not be a huge consideration when determining the format. At least, not huge enough to do something you don't want to do.

(That said, as I was reformatting this file, I realized that there are some things I REALLY like about having each declaration and all its properties together on one line. I thought I would hate it, but it's not too bad. I may give it a try in a real working environment and see if I still like it.)

Jeff L said on September 21, 2006

My favorite CSS tip came from Garrett Dimon, in his Digital Web article here - it's down near the bottom entitled "Alphabetizing" - I find that I can't read CSS these days unless I alphabetize it first.

Cem Gencer said on September 22, 2006

Really nice thoughts; especially to be verbose and shorten the adressing of the elements is a #1 for me. and to indent any rules which belong together hierarchically. thanks.

Sholom Sandalow said on September 22, 2006

Nice post. Although the No Hacks is a bit unrealistic for client work.

Kobalt said on September 22, 2006

Nice article Snook. I'm noobe but I want to commet some things:

1. Px - yeah, '%' and 'em' are nice idea but sometimes it causes more troubleshots than it worth it. And stop to whinge - 95% IE users don't know they can change font-size, they get site "as is". If someone has changed it in their browsers they think that a site is broken.

2. Overflow: hidden; hmm... sounds good, I'm gonna try it. It could be very usefull on CMS, sometimes a client can devastate our layout. Thx for an idea.

3. Padding and margin without width. Damn, that's it! It really works and we should say it loud: "No width if it's not necesary !".

4. Shorthand. That's right! If you learn it, you will never go back to the long formula.

5. Declaration on one line... No no no. I'm gonna stay with my style :) Everyone has some habbits and it really doesn't matter how we write CSS. The arguments that the files are smaller sounds ridiculous. Different beetwen 30 and 34kB CSS?? YOU MUST BE JOKING ! What bandwidth do you have? 512kb? 1Mb? 2Mb? Today almost every site has >150 kB. The site you can download on about 2-3s. And you wanna tell me that you can see different beetween 150 and 154kB? You have your style of creating CSS, I respect it (it has some advantages) but don't try to tell me that file size argument is serious.
It can couses some problems if You want to see the site's source.

6. Sorry for my terrble english. I'm working about it :).

Jonathan Snook said on September 22, 2006

Caesar: yes, avoiding specifying font sizes altogether is the best approach but most designers are pickier when it comes to the look and feel of their sites. These days, px is probably the most consistent cross-browser.

Sholom: absolutely No Hacks, true. But I think it's a goal to work towards. My recent stuff I've been able to reduce things down to only having to use one or two hacks. And that's for client work. I think we too readily rely on hacks when we don't need to.

Kobalt: file size certainly isn't critical but I don't think it should be ignored altogether. I still take the top to optimize my images, be minimal in my use of HTML, JS, and CSS. All of this adds up. I certainly didn't take it as far as I could have but as it is I've been able to stay under 100k total page weight for most projects.

stephen said on September 22, 2006

[14] ... Stephen: your ul li ul li ul li example could easily be shortened to li li li. See how the UL is superfluous?

Tested on CSS of this new page. Thanks for the lesson.
Also checked the CSS Validator, re: line-wrapping. Yep, you were correct.
Jon', You offer an amazing array of information that which I will return to regularly to improve/enhance my knowledge base. Thanks.

Juergen Riemer said on September 25, 2006

"CSS declarations on one line"

why not use your VIM to fold your CSS declarations? :P

Steven Hambleton said on September 29, 2006

A favourite is to see what elements share the same rules and bunch them -

h1,h2,h3,h4 {font-weight: lighter;}

Wilson MIner said on October 01, 2006

I'm with you 100%, except maybe on the last one (avoid unnecessary selectors). In principle, definitely. Don't make it more specific for no reason. But I do use overspecific selectors a lot for the sake of context. Once I'm down to the id level in the stylesheet and I'm creating all the styles for a particular page element, I try to keep the initial element id in all the rules, so when I'm scanning the rules they all are grouped together visually. For instance...

#container { width:250px; }
#container .title { color:red; }
#container .description { color:black; }
#container .description a { color:blue; }

Improving scannability has made a big difference in my productivity and I think this was a big part of that.

I also include the tag in a lot of id and class declarations, just to avoid namespace conflicts in large sites, but I think that's just an example of breaking the rules when it makes sense to.

Bernhard Welzel said on October 02, 2006

how strange. you manage to to everything exactly the other way around:

px for font sizes:
i can´t see ANY reason for px for font sizes. its just plain wrong. sorry, and shame on you.

css declarations on one line:
yes, good advices. besides you like to have readable css for somebody besides yourself. and maybe some people don´t want to spend big time on decompressing your css?

blocking the styles:
this makes perfectly sense with putting css declarations on one line.
for everybody else: bad practice, because your css becomes messed up badly

browser support
YES. drop support for everything not cutting edge. GREAT IDEA.
how about this: don´t mess around with old browsers? i keep my css seperated: nn4.css for everything "not so new", and a "standard.css" for the modern generation.
now comes the very surprising part: for about 99% of all my projects, they still look good in ie5 even on mac.
how does it come? maybe i´m to stupid to use all this hack the hell out of the css, just use css3 properties and be a cool-ass programmer.

use css shorthand
i dont recommend this, because its a pain in the ass for problem tracking / debugging.
ever tried to figure out why a page breaks, because some "expert" need to put margins all over the place and messed up the top/left/right/bottom order?
forget about the few extra bytes - it will reward you big time with a BIG saving on your time, managing the css.

i fully and 100% agree with:

keep it simple !

A2D Webdesigner said on October 02, 2006

Hi Jonathan,

Thx for this great tutorial/tips. I have a problem with my css IE hacks. (\height: and h\eight:)

here is my css declarations. How can i make it W3C valit with the same effect? can you give me perhaps few tip... Thank you

/* <![CDATA[ */
#navMainContainer ul li a {
padding:0 24px 1px 25px;
\height:16px; /* ie5 */
h\eight:15px; /* others */
#navMainContainer ul li a:hover,#navMainContainer ul li a#active {
\height:16px; /* ie5 */
h\eight:15px; /* others */
/* ]]> */

A2D Webdesigner said on October 02, 2006 can I post here css codes? I try it again. hopefully it folds now

#navMainContainer ul li a
padding:0 24px 1px 25px;
\height:16px; /* ie5 */
h\eight:15px; /* others */

#navMainContainer ul li a:hover,#navMainContainer ul li a#active
\height:16px; /* ie5 */
h\eight:15px; /* others */

Kamil said on October 03, 2006

Nice tips. I have too some of this on my site.
I prefer CSS declarations on one line too, than on block. But most of peoples says that it's bad practice :)

Olmec Sinclair said on October 04, 2006

Generally I agree with your comments, the mostly point to common sense (byte sizes etc) but I prefer my personal layout and verbose margin declaration.

I try to write my CSS files top to bottom (or following the HTML flow) which helps me locate the relevant classes.

Thanks for helping promote 'good CSS'

Jonathan Snook said on October 04, 2006

Bernard: Why is using px wrong? If you ask me, Internet Explorer is the only one who is wrong. And like I said in the article, with IE7, even it will allow resize of web sites that use px. And considering 99% of people who use IE don't resize their fonts, I hardly consider it wrong.

As for css on one line, people are going to prefer one way or the other. I find everything on one line easier to read. Therefore, if I were to try and read your stylesheets, I'd be equally frustrated. Besides, decompressing the css for anyone who cares would take all of 2 secs. Try not to be overly dramatic to prove a point.

Wilson: with indentation, I've no longer need to add the extra container id at the beginning. But I agree that larger sites may introduce the need to add some extra safe-guards.

Darren Hoyt said on October 12, 2006

This may not be a popular stance, but I couldn't get used to putting all declarations on one line.

If you use Dreamweaver or another code editor with a Line Numbers function turned on, it allows you to add/edit/delete lines of info really easily simply by clicking the number. Entire declarations get pruned with relative ease. I'd prefer that any time over reading sideways over a long horizontal list and precariously making cursor selections in order to edit/delete something.

It also looks more legible to me when line breaks are used, but everyone's mileage varies.

Dave Everitt said on October 16, 2006

Two handy 'which order is it?' mnemonics:

Top Right Bottom Left

Link Visited Hover Active


Jens Meiert said on October 19, 2006

> I've always put my entire declaration on one line.

Scanned the comments, and nobody seems to have pointed out that apparently, you mean "entire rule" here.

Regarding "rules on one line", I actually take the same approach:

Nonetheless, code style is an important topic, and it's always good though controversial to talk about.

(German readers, by the way, see my former article on GMX' XHTML and CSS coding guidelines, which will be updated by another article - or blog post - "soon".)

pauldwaite said on October 25, 2006

<blockquote>CSS declarations on one line

Boy crikey. The second one isn't just prettier, it's surely more readable. If you've got pretty short rulesets, notquite so bad, but even the example you've got there with four rules looks unclear to me.

If you're looking for an element, an id or a class, surely using your editor to search for it is quicker?

I guess if editors would automatically indent code according to our preferences this wouldn't matter.

the more you try to override what the browser does, the more styles you have to put in, which simply adds to the time to track down bugs and maintain the code.


Support only the latest browsers. That means dropping support for IE5 and IE5.5

Come now, surely that's irresponsible without checking your usage stats? (Unless we're talking personal sites here.)

I can avoid shovelling different style sheets to separate browsers. I have one sheet, and that's it.

I have one extra stylesheet for each versions of Internet Explorer that needs one. That way, I can support them, and easily tell exactly how much work it is for me to support them, thus more easily making the case to clients and myself about dropping support when usage becomes low enough.

putting the element name in front of an ID selector

I entirely agree this is a bad idea. It can come back and bite you if the element gets changed, but still needs the same styles.

the only hint I've got in addition is that, if you're specifying a length value of 0, you don't need to add the unit (e.g. px, em), as 0 is the same whatever unit you're in. All modern browsers support this.

pauldwaite said on October 25, 2006

I'm getting the comment slowness in Camino too. Version 1.0.2.

The more keystrokes I do per second, the worse it gets, I think. Have you got a function executing on the onchange event of the text box?

Ah, yes: previewing the comment :)

Fabrice said on October 26, 2006

Hi, thanks for the tips.

I use a dedicated CSS editor [CSSEdit] that you might be interested in.

CSSEdit is only for Mac lovers but easily solve Jonathan's dilemna between a clean declaration and a fast way to browse selectors.

It also allows to create folders and subfolders, now that's what I call a block system !
Of course you can clean the CSS before exporting if this is a concern.

If you forget about the visual editor that most advanced user won't need, it features a really smart auto-complete, and a live preview that doesn't flicker. All that in a clean and simple interface.

As a beta tester I just can say that 2.0 is coming soon and is amazing, there is no coming back.

Andrew Massey said on October 26, 2006

IE DOES NOT resize the fonts, it resizes the whole page. If you use the traditional "Page => Text size" menu items you get the same functionality, i.e. no resizing for px.

Just wanted to clear that up; apart from that I enjoyed the article...thanks

Mike Stenhouse said on October 26, 2006

Peronally, I favour writing my CSS to be the most readable, understandable and maintainable it can be. If I need efficiency I use a compactor...

I've never been able to find anything in single-line definitions and extra selectors help anyone else coming to the code to get oriented more easily. If it's only you who's ever going to look at the code then fair enough but in a team environment that's not necessarily the way to go... I wrote up my views on this malarkey a while back.

Jonathan Snook said on October 26, 2006

Andrew: Yes, very true. Thanks for clarifying that. The important part is that IE7 users will have a mechanism for seeing the text larger if they need to.

For those that mention code-folding as an alternative, I don't like it as most code-folding hides the contents whereas, I still need to see them.

Mike: I find having the properties on each line harder to read, therefore, it's not necessarily about 'playing nice with others' as inevitably some will prefer one way and others will prefer another.

I should also clarify that I develop on a wide screen so having all the properties on one line, I can still see most rulesets without scrolling.

Mike Stenhouse said on October 26, 2006

I've got a nice wide screen but I use it to keep things side by side rather than maximising any single app (other than Photoshop) so long lines have always annoyed me. Out of interest, do you have an order for your properties within each rule? Mine are grouped, with each group ordered... Slightly compulsive obsessive! It lets me find what I'm looking for very quickly though.

Jonathan Snook said on October 26, 2006

Mike: yeah, I group. :) width and height go together, margin and padding go together. position and top/left/right/bottom go together. color and background go together. font properties are grouped. float and clear get grouped.

Basically, anything that is related tends to get grouped.

Josie said on October 26, 2006

That was very helpful, thank you!
I never knew you could set the border for only two sides with the border then border-width properties. I used to do something like:

border-left: 1px solid #000;
border-right: 1px solid #000;

holly said on October 27, 2006

I believe using px in any way is seriously outdated by now. Scaling possibilities of every element in your design is key to give each user it's proper experience. So if he/she scales text, its container will scale the same amount including margins and padding.

Not keeping 'outdated' browsers in mind when designing a commercial website is just plain lazy in my opinion. You comment with "Give 'em a nudge into the new millenium!". As if a visitor of your website would upgrade to a new version just to be able to see it the way you want him to!? He will not. In fact: he will leave, and his sack of money too.
It's like closing your real-life store for people with 'old' shoes, or age. Sounds silly right? It is. So don't do it!

Your writing tips seems pretty straight forward, but all that is good looks simple right?

Keep it up!

Ocean Sky said on October 27, 2006

I think placing CSS declarations on one line is not the fastest way of searching for text; then again, it really depends on what type of editor you are using. Yea, the file may be 2kb smaller; then again if you are worred about 2kb, don't use images. No everybody uses a GUI for writing code, or for that matter code writing code full screen size. If you want to find something fast, learn regular expressions.

By the way this comment box is slow. You talk about functionality in your article. Create a comment box that is functional. Lag sucks.

Jonathan Snook said on October 27, 2006

holly: You read way too much into my words. Firstly, I specifically said that my recommendations were audience dependent. Next, I have little sympathy for those who choose to use heavily outdated browsers. They're more likely to get no styling than be concerned about pixel size restrictions. Modern browsers have the ability to resize the text on a page and therefore using pixel measurements is lower on the list of concerns.

Ocean Sky: I write everything on one line because it makes it easier for ME to read. It's not about size (although that's a bonus) and I know regular expressions fine enough. Using my approach, I can find the element I need to work on and the property I need to edit faster than I could pop open a dialog box.

As to the comment box, people using Camino have mentioned some slowness. One of these days I'll have a preview that works well for all browsers.

Jonathan Nicol said on October 28, 2006

Nice article, it's always great to get an insight into someone else's working methods.

As a few others have mentioned, I'm not a fan of pixel sizing for text (IE7 *doesn't* allow resizing of pixel sized type, but it does have page zooming). I wrote an article outlining my method for font sizing, which is pretty much the same as Clagnut's I think, and I find to be as accurate as using pixels.

Your technique for indenting rules looks promising. I find deciding how to group rules is always a challenge.

Luke S. said on October 28, 2006

Nice tips Jonathan, and I'm with you on the declarations on one line thing! I find it much easier to scroll and scan documents like this, scanning up/down for the (neatly grouped) selector, and then left/right for the declaration.

Gabriel said on October 28, 2006

I agree with alot that you have to say, however, when it comes to placing code on one line, I would have to disagree. One, if you are coding with a team, or coding knowing that someone else might need to sift through, it makes it slightly more difficult to read horizontally than vertically. Second, you are forgetting about a key feature in most good IDE's, and thats code folding. Most good IDE's code fold at the first "{" making it easier to find method names and in this case, element declarations.

Just my thoughts, anyway, good read.

Phil Wilks said on October 29, 2006

Great tip about blocking styles. I also use comments to delimit different "sections" of CSS files: /**** Header ****/

Ryan Cross said on October 30, 2006

Caught a typo:

Second paragraph in the 'Blocking the Styles' section:

"... or a callout would go hear..."

Should be "here" instead of "hear." Great article, by the way!! Thanks for passing these tips on to us.

Stevie D said on November 07, 2006

George ... On my website logs, IE 5.x accounts for less than 1% of users. That's current data from this month. In October, it was under 1.5%, less than half the figure for IE7

purusoth said on November 09, 2006

i would like to fine iframe height after loading one html

Dennis said on November 12, 2006

PX for text size?! I'll stick to ems for now, thanks. I won't allow IE to control how I code. I find that CSS declarations on one line is very difficult to read. I like that CSS blocking technique though.

Jonathan Snook said on November 12, 2006

Dennis: I figure most people use ems because of IE. I use px because it's consistent and I won't allow IE to control how I code. :)

Felipe said on November 22, 2006

Hey there, I was browsing your domain and I like it a lot, but hey, I can't do this kinda layout you have and I'm looking for it how to make and I don't find. Could you please help me doing this kinda things like the one in the footer?


John said on December 07, 2006

hi, Jonathan, thank you for the great tips.
I should try some CSS on my new sites.

Zoffix Znet said on December 25, 2006

I think the title of the page should be titled "Top 10 Things That You Should Avoid" ... What is wrong with you dude? Why are you confusing clueless readers and making them use bad practices????

Zoffix said on January 11, 2007

Zadar, yes it will, but that's not the point. If you visit in anything but IE you will see a style switcher above the menu. You can instantly change the outlook of the page. That is more to demostrate how easy it is to redesign the page with CSS. Also, tablebased designs are totally unaccessible for screenreader users. This site kind of lays it out: stupid table

Cory said on January 16, 2007

Great article Jonathan! I implement some of the same CSS procedures as you. I have recently been playing around with putting all of the declarations on one line. It is certainly easier to scan the code for certain elements, it is just taking a bit to get used to.

I have also started breaking down my style sheets into "blocks" which has greatly reduced time when going back to make changes, updates to code.

matzi said on January 17, 2007

That was very helpful, thank you!
Best Regard from Germany

Mr.brand said on January 19, 2007

Hello your site is graet

Shine India said on January 25, 2007

Good and useful tips ! Thanks

Koehly said on January 31, 2007

thank you for the great tips.
thx koehly

carl said on February 17, 2007

Nice tips! I these useful as well.

neat lookin said on February 26, 2007

some thoughts

Ken Laninga said on February 27, 2007

I sure do like what you said: "...put my entire declaration on one line."
I'm just learning how to use CSS and think that your way is MUCH nicer and more user-friendly.

Tom Blanks said on March 04, 2007

I always appreciate input about the structuring and organizing of stylesheets... sometimes it's really hard to get it right, but I think you do it best. Thanks.

aki said on March 05, 2007

Really good tips and your web page is completely perfect!!!

Niktus said on March 14, 2007

Great post and great page Jonathan... amazing design.
It´s a great source for knowledge and ideas.

Keep on good work!

Hardware Portal said on March 17, 2007

Great Tipps, i digg and bookmarked you.
Thanks for the Informations.

Michel said on April 02, 2007

I use CSS since a few years, and i use more then 1 CSS File too.

Max Cady said on April 10, 2007

yay! great to read somebody mentioning CSS shorthand, I could never understand why more ppl don't use it.

I find it easy to remember it with the mnemonic, trouble; or more specifically TRBL.
Top Right Bottom Left


Steffen said on April 16, 2007

Right you are.
I only use px too. Thanks a lot for the tips on this site. I will try a few of them.

gels said on April 18, 2007

lol - props to pixel sizes! Shame no more!! Here's my CSS "tip" (more accurately "exploit")

This way, I always get the same height boxes until the content exceeds the height, in which case it will expand perfectly. (Props to Diaz for this one).

Rudy said on May 04, 2007

Great post and article. Good to see I am doing some things right and learnt a few thigns as well.. thx

You are soooo right about Allow Block Elements to Fill Their Space Naturally and Avoid Unnecessary Selectors ... KISS ... keeo it simple stupid is my motto ...

I am sure you could add a blurb on Inheritance and css Scoping as well.

Webice said on May 06, 2007

Great article.

- I use only one css hack: !important for IE
- I use sperate stylesheet for IE7
- to hide from NN4 and IE4 and below I use @import url(style.css);
- I use font-size:62.5%; for resizable font sizes
- for top, footer menu items I use links with background image and text-indent:-5000px
- to remove dotted links outline: none;
- to check for css browser support I use this guide
- to minimize css size I used this shorthand guide
- for rollover images I use this tehnique

Keep up the good work!

Duncan said on May 11, 2007

Not wanting to be pedantic but you mean "fewer" not "less": ...Using *fewer* selectors will mean *fewer* selectors will be needed...
I think including the element name in front of the selector can be a good idea when working in a group.

Projektowanie stron said on May 29, 2007

I use px for body and then in other elements i use %
Interesting article. Regards

Dušan Smolnikar said on June 12, 2007

This is an old topic, so I wonder if you'll read this, but here it goes:

I used to use px for font-sizes too. Mainly because if a user sets his default font size to something other than 16px, things get ugly. But then I realized that if a user does so, he does it for a reason. Let's say I have a bad eyesight and I want fonts on all sites to be a bit bigger, without always pressing that "enlarge font size" button/keystroke. I set my default font-size to something more than 16px (let's say 20px). Now if the designer has been a good boy (did not set font-size in px), this will allow me to view the fonts on his page bigger than normally. But if he specifies the fonts in px, he is just ignoring my preference.

So nowadays, I start by doing something like "body { font-size:70%; }" and then put everything else in em. so for users with default font-size at 16px this would be the same as saying "body { font-size:11.2px; }".
And all the browsers I know of (except safari 3 beta for windows, which is buggy anyway) use 16px as the default font-size. So to the user that isn't aware of the setting, this won't make a difference. If it makes the site unreadable to someone who did change the setting, well, he'll probably know why.

Matthew Hunt said on July 16, 2007

YES! I love putting my css rules on one line! finally someone who agrees!

Matthew Hunt said on July 16, 2007

Adding to the tips:
I know it may add some bytes to the CSS , but I like to add the color codes in while I'm working on the css file, then if need be, remove that info after. like so:

/*Global Color Palette
#99a84f green
#586129 dark green
#34484d blue
#677c81 blue-light
#536c73 lighter blue
#8c9dea lightest blue

Aaron Saray said on July 29, 2007

I'd have to say that I don't agree with your CSS all on one line. I can understand your reason for it - but your reason seems to be only to be a personal preference - not an efficiency thing. I've tried to build all of my 'personal preferences' off of efficiency and not from 'this is how I feel right now...' I believe in multiple level CSS declarations because of the 1) ease of addition of new styles and 2) its easier to read in the case of a small width developing screen. However, the rest of the info is good - keep up the good work!

Jonathan Snook said on July 29, 2007

@Aaron: I made no mention of it being personal preference (although, it absolutely is). I do it because it's quicker for me to develop like that. I can find rulesets much faster. Most of the projects I work on, my stylesheet is rarely larger than two pages. In conjunction with how I block styles, I can find things in a second or two. Adding styles is just as easy for me as most declarations tend to be fairly short. If I've got 5 declarations, adding a 6th isn't going to take any time. Which is also why I disagree that troubleshooting is more difficult. It simply isn't.

Luckily, more people are sharing the gospel. :)

hello said on September 05, 2007

hello, cool site, i love your work this is my blog: - look at it now!

Willis Witze said on September 27, 2007

great tips, thank you! i love your design.

Safwan Ahmedmia said on September 30, 2008

top tips, many thanks

Deron Sizemore said on October 24, 2008

Hi Jonathan,

I'm jumping in on this post late, but I figure better late than never right? I've always written CSS on multiple lines instead of one. I think it's prettier and to be honest have never even thought of doing it on one line until reading this article. You said that you like one line because it's easier to scan, but then further down in the article you said "I also tend to just do a search to find where something is." So, if you tend to just search for a style (I most always search for styles myself) then why not have the code on multiple lines so it's prettier? You're searching anyway, not scanning, right? I imagine that the CSS file size is in fact smaller by having one line CSS, but the size difference is likely minimal wouldn't you say?

Also, I know this was wrote two years ago but I'm curious as to your thoughts today on px's for font size? After reading "Bulletproof Web Design" I got in a habit of setting font-size in the body to "small" and then styling everything else in the CSS with percentages and it's worked out OK I suppose but I still love the control px's give you in that your designs tend to look closer to the same cross browser. I was just reading the other day on SitePoint about px's for font size and I believe it was Tommy Olson (forgive me if that's incorrect) that said something to the effect that px's should never, ever, ever be used to size text. As much as I love the control, I would hate to be thrown in CSS prison for breaking that rule. ;)


Anand said on November 24, 2008

Good tips for beginners. Thanks !

Jack F said on December 08, 2008

Great tips, nice to learn from the master!!!

Rik Weber said on February 04, 2009

I was also one of those who advocated using ems for font size, but a lot of my recent work has seen me slowly revert to pixels.

Tom said on February 18, 2009

This article really hits on all of the best practices for CSS writers. I just started the one-liner CSS recently and it really helps in readability.

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.