Christian Montoya

CSS techniques I use all the time

I'm always learning new things with CSS. It's interesting because I've thought of myself as a CSS expert for a while now (I'll challenge anyone to a competition, seriously) but I still keep learning and improving. I've come across some techniques lately that are extremely valuable and worth sharing. Have a look:

Initial Settings
Years ago I used the * selector as so in all my CSS: * { margin:0; padding:0; }. This eliminated all differences in padding and margin across browsers so I was free to go about styling my page. Unfortunately, this isn't a good practice. It's very heavy on the rendering agent to apply rules to every single element in the document, especially with large web pages, and this can also destroy a lot of good default styling, especially when you want to have default styled submit buttons. I learned from KuraFire Network that it's far better to have a complete list of default settings to apply from the beginning that targets the specific browser inconsistencies. I use something very similar to what is described at "Starting with CSS: revisited" site down: use my initial.css copy with the addition that I apply font-family:inherit; to inputs, textareas and buttons. It works great and there's no need for the * selector.
Text Readability
Ever since I read the "100% Easy to Read Standard," I have stuck to some basic but highly important initial settings for text; "line-height:1.4" for readable lines, reasonable line-lengths that avoid lines much longer than 10 words, and colors that provide contrast without being too far apart. For example, pure black on pure white is often too strong for bright CRT displays, so I try to go with an off-white (#fafafa is a good one) and a dark gray (#333333, another good one).
EM calculations
Sizing text is always an important part of making a usable design. I start all my CSS files with the following rules:
html { font-size:100.01%; }
body { font-size:1em; }
The explanation for this comes from "CSS: Getting Into Good Coding Habits:"
This odd 100.01% value for the font size compensates for several browser bugs. First, setting a default body font size in percent (instead of em) eliminates an IE/Win problem with growing or shrinking fonts out of proportion if they are later set in ems in other elements. Additionally, some versions of Opera will draw a default font-size of 100% too small compared to other browsers. Safari, on the other hand, has a problem with a font-size of 101%. The current "best" suggestion is to use the 100.01% value for this property.
Point taken, moving on. I like to keep my body copy at 1em for the main content; this fits the default text sizing that users have in their viewing agent. All browsers convert relative EM sizes to pixel sizes, and most users have browser defaults at 16px. Something I have been doing recently is actually calculating EM font size throughout my design to this base of 16px. Because browsers have to round fractional EM sizes to whole pixel values, it's very important to really think about what the final pixel value will be. In my most recent text-sizing work, I used the following calculation: 14px/16px = .875, 18px/16px = 1.125. So my default text at 1 em would translate to 16px for most users, and my small text I sized at .875em which I can trust to result in 14px for most users, while my large text I sized at 1.125em which I can trust to result in 18px. Note that I avoid going lower than 12px for default sizing at all costs; anything smaller than that is too small for me to read and I would be a hypocrite if I expected others to read that.
Safe Fluid-width Columns
I work with hybrid fluid layouts all the time, usually with max-width set at anywhere from 900 to 1000px. I usually have floated columns with percentage widths, and browsers will calculate these percentage widths to whole pixel values when rendering the columns. A typical problem is the following: when a user has the viewport at a size that makes the outer container 999 pixels wide, if the first column is 60% and the second is 40%, IE 6 will always calculate the two columns as 600 and 400 pixels and as a result, the two will not fit (600+400 = 1 more than 999) and it will drop the second column. This is obviously not intended behavior, and in a world where we still have to use floats for columns (I can't wait for display:table support across all browsers), it's important to work around this problem. I used to give my last column 1 less percent (in this example, it would have 39% instead of 40%, but this would usually result in columns that don't quite fill up the container. Of late I have been giving the last column .4 less percent (in this example, 39.6%), which seems to work perfectly. Browsers will calculate this width and round up, but it will still fit even with an odd container width like 999px and I won't have to worry about dropped columns.
Filtering for Old Browsers
To be honest, I barely support IE 6 nowadays. If there is something special about my layout that doesn't work in IE 6, I will simply filter it out of the CSS that IE 6 understands. One example would be max-width… a layout with a fluid width and pixel max-width is just plain fluid in IE 6, and therefore doesn't work at all. Because old browsers like IE 6 don't support the "first child" selector (right caret >), I can do the following to make sure that IE 6 only gets the basic setting and all the new-fangled browsers get the right result:
div#container { width:900px; }

html>body div#container {
  width:auto;
  max-width:900px;
}
/* This overrides the previous declaration 
   in new browsers only, 
   IE 6 simply ignores it. */
Alphabetical Properties
I don't know where I got the idea, but I have been alphabetizing my CSS properties for months now, and believe it or not, it makes specific properties much easier to find. Here's an example:
body {
  background:#fdfdfd;
  color:#333;
  font-size:1em;
  line-height:1.4; 
  margin:0;
  padding:0;
}

These are just things I do that have worked extremely well in my experiences; this isn't a definitive guide of everything one should do nor is it everything that I do. Hopefully you find this useful and by all means, share your own techniques too.

p.s.: Please, Digg this article.

Thank you for reading • Published on February 1st, 2007 • Please take a moment to share this with your friends