This article is not about learning CSS. It’s about having a set architecture in a project when moving forward. One of the first things in beginning development is setting in place a best practice procedure when moving forward – it’s not saying “there is only one way”, it’s saying “for this project, this is how we are moving forward.”

Rule: Choose a Browser Reset Style Sheet

Choose one, or don’t use one.

This helps you on your cross-browser journey. If we reset all browsers to zero, it allows you to spend less time figuring out why margins are inconsistent amongst your unordered list elements (<ul>). This also sets you up to have a default font-family and consistent font-sizes, line-heights, etc. This is most important when cross-browser similarity is a high-concern.

CSS Resets are Bad, M’Kay?

Jonathan Snook stated that he “…okay if the various browsers show things slightly differently.” Jens Meiert also states CSS Resets are bad because they essentially add up to a defined style being overwritten repeatedly, adding to network latency due to the multiple requests for CSS. Then follows up with the comment of using * { margin: 0; padding: 0; } which itself is a bit of a hack and causes performance issues.

To be honest, the argument that CSS Resets/the * hack are a bit of a red-herring. For the majority of clients/sites I’ve worked on, this has been an incredibly minor concern. We’re talking milliseconds. Not even on the radar type performance hits. If you want to squeeze every millisecond (and I do) this is kind of an extreme (even for me) case.

Unfortunately, not all of us are as lucky as Snook and we work with clients/creatives that are not okay with things being a few pixels off sometimes. Personally, I’m with Snook.

Should You Choose To Reset

You have several to choose from:

• Toby Miller’s Equalizer
• Eric Meyer’s Reset
• YUI’s Reset

Rule: Link States

This is referred to as the “LoVe HaTe” rule. :link :visited :hover :active
This relates to CSS specificity, below.

Rule: CSS Specificity

Eric Meyer has a great article on CSS specificity in general that I find lame when sites try to duplicate his article with their own “twist.”
I fully admit, I suffer from over specificity. For good measure, you can read Google’s article about CSS specifity and the increase in performance by using effective CSS selectors.

To reiterate certain aspects, DON’T put a class and ID on everything.

div.imageHolder img#imageHolderImage /* this is BAD */
div.imageHolder img /* this is BETTER */
.imageholder img /* ding ding ding! we have a winner! */

As well, don’t code things inappropriately, i.e. use nested divs/p to generate what is essentially an unordered list.

Test
Test




Target the first item
General list item
Target the last item

Rule: Naming Convention

We won’t dwell on this. BE GENERIC. It’s better to have “.active” or “.select” and NOT “.greenActiveText” – what happens when green active text becomes orange? Now you have a poorly named class.
Also, pick a naming structure and STICK TO IT. camelCase? Dashes-instead? Hell_underscores_are_okay, AS LONG AS YOU ARE CONSISTENT. Do not change it up. This is extremely important walking on to a project. If you walk in and the prior developer is doing it different than you are used to, ADOPT THEIR STYLE, DO NOT REWRITE IT, ADD TO IT, OR MAKE IT MORE COMPLEX THAN NEED BE.

Rule: Shorthand

Use it. Know it. Love it.

div {
	background-image: url("to/some/image");
	background-repeat: repeat-x;
	border-width: unit;
	border-style: (solid dashed dotted double);
	border-color: color || #hex || (rgb / % || 0-255);
	color: #669900;
	margin-top: 10px;
	margin-right: 9px;
	margin-bottom: 8px;
	margin-left: 7px;
	padding-top: 10px;
	padding-right: 5px;
	padding-bottom: 10px;
	padding-left: 0px;
}
div {
	background: url(to/some/image) repeat-x;
	border:border-width border-style border-color;
	color: #690;
	margin: 10px 9px 8px 7px;
	padding: 10px 5px 10px 0;
}

Notice the “0″ has no identifier. It doesn’t need one. Notice 13 lines became 5. Love that. We also dropped the quotes to prevent any possible browser errors. Get to know your CSS shorthand.

Rule: Browser Targeting

For the love of God, they’re called hacks for a reason. They are hacky. They shouldn’t work, but do. You could fuck another browser down the line. You could introduce errors. DO NOT USE BROWSER HACKS This is a bigger sign that *you* are a hack and a not a proper developer. These are the “once in a lifetime” things that come up.

Except for IE.

Fortunately, IE has a nice, clean targeting system. Conditonal comments. If you target IE, use Conditional Comments.

Rule: CSS Behaviors Require JavaScript

If you’re writing CSS Behaviors, move it into JavaScript. Plain and simple. There is no reason to have CSS behaviors. At all.

Rule: Organize Your CSS

I know this one can be a bitch. The project can change. Your initial strucutre may not make sense. But try to organize it to prevent redundancy.

Alphabetize Yo’ Self

I alphabetize my CSS because I find it easy to read, search, and peruse. I also use a code highlighter in jEdit. Others group it by property (font styling, positioning, dimensions). I prefer my way, but that doesn’t make it right. Just when I’m leading the project.

Rule: Comment, Comment, Comment!

Comment the shit out of anything you are handing off. Eat the bytes. But don’t go crazy. /* this is a comment */ not /*——————– (several lines of this) CODE COMMENT (repeat several lines) ———-*/ Keep it simple. Keep it common sense. Break it up by section (however you organize your CSS).

Rule: The DO NOT Do List:

Don’t do these.

Don’t Use Inline Styles. Period.

Inline styles defeat the whole “separation of content and design.” Maintenance becomes a bitch, frankly. You also add to page weight, and can cause issues when a developer doesn’t realize you’ve done things inline and their properly coded external styles are not working properly.

But Keif, I do this all the time in development… – that’s fine, Timmy, but if you “accidentally” leave one in to production, or check it into SVN/CVS/Git and try to act like it’s not your fault, you’ve proven the point why you shouldn’t do this.

Reuse a “Standard” Set of Specific Styles

I don’t mean reset. I don’t mean element specific/font styling type items. I mean don’t use classes that are specific. #width100 .marginLeft25. This is representative of bad coding in general.

Now, this is a brief overview of many “best practices” I try to run with and improve upon. Google CSS Best Practices and you’ll find a slew of additional resources. Not all of them will agree with me – but that’s not the point. The point is understanding them, and recognizing that someone else’s preference may override your own, and my not be technically wrong. If you fail to recognize this, you need to reconsider your role and what you’re doing – you need to be both a team player that can adapt and evolve, and an innovator should you be charged with leading the effort.

What do you have? Send me your best (or worst you’ve seen!)

A constant debate is always “why support IE6? It’s expensive, it’s annoying.”

Now, I’m not disagreeing with that. I don’t like IE6. It’s old. It’s broken. I’d prefer it went away. Unfortunately, IE6 represents over 30% of all IE traffic (which represents roughly 64% of all internet browsers).

It’s not representative of my site.

If you pay attention to your browser metrics, you can see that IE6 is not representative of your site. At all. You can see this as a green light to ignore IE6 (particularly if it’s an intranet or members-only site, as you can dictate browser requirements as a “bare-minimum”). If you’re a blog, I’m all for ignoring IE6. I encourage more sites to do it.

Now there is one slight flaw with that argument. What if your site gets dugg? Slashdotted? Attached to a virus and spread? Date Is ay it – maybe an article you write goes viral?

Some Microsoft This Way Comes

Outside of a sudden surge in popularity, the other *very realistic* look is e-commerce sites. I don’t care who you are, a dollar is a dollar, and as such your e-commerce site better accommodate every visitor. No flash reliance, no JavaScript reliance. Period. I don’t care about it looking the same, but I better be able to make a purchase via Lynx. More importantly, any handicap should be accounted for (blind is the most often thought of). This is what we call Web Accessibility. All angles should be covered, within reason. And IE6, regardless of your metrics, is within reason.

AlphaImageLoader – Ye Olde Standard

I think anyone who is “in the biz” knows about AlphaImageLoader. We’ve all done the CSS replacement. I helped adjust and edit a MooTools Class that utilized it to account for all sorts of PNG situations. It was our “standard” because it was able to account for IE6 with a minimal amount of effort. Except…
AlphaImageLoader does not support background-repeat, or background-position. It requires set heights and widths. It requires one-off styling for images that are cropped. Plain and simple, it still sucked.

VML – The New Contender

I stumbled on a VML solution after researching a site to see how they were handling PNGs. It turns out they were utilizing DD_belatedPNG. I dug into VML vs. AlphaImageLoader and came across this article explaining the same thing – AlphaImageLoader or VML.

The obvious is pointed out: AlphaImageLoader eats memory. VML adds bad markup to a page. IE6 does *not* cache the image (according to the article, at least).

So, we’re stuck with a memory hog or a lot of image requests against a server, which can add to a lot of bandwidth costs if your traffic spikes (it happens).

Will The Real Slim Code Please Stand Up?

After reviewing DD_belatedPNG a second time, he claims to “mostly” have fixed the caching issue. To be honest, with as much grief I’ve had from AlphaImageLoader and changes in creative layouts that require PNG transparency, it seems like a real replacement for AlphaImageLoader, loaded using JavaScript and conditional comments so ONLY IE6 takes the hit.

The downfalls? No opacity on the VML. I haven’t looked into creating a container to wrap the VML and fading that, but call me crazy, it may not work. This means we may have to keep AlphaImageLoader around for a little while longer. I’m not sold that either solution will replace the other, but they both are going to be invaluable until IE6 goes the way of the dinosaur.

Performance Concerns? Not with VML.

Thank God someone else ran the numbers. Tests have been ran, and also Yahoo! provided some additional numbers to help showcase that VML is not the memory hog AlphaImageLoader is. Bonus!

There is the argument that a PNG 8-bit image is a better solution. No CSS hackery, no JavaScript intervention. However, it requires whomever the developer is, and also whomever the designer is cutting up your graphics to be familiar with proper image optimization techniques to insure an efficient, optimized experience.

The REAL Solution
The priority of the solutions seems evident. PNG 8-bits for most cases. VML through most others. AlphaImageLoader only as absolutely necessary. I do believe that a JavaScript solution is the best solution for IE6 AFTER 8-bit PNG images (ran through a PNG optimizer (like PNGCrush).

Unfortunately, such optimal solutions require trained developers and trained designers. Who has time for that? You should make time to insure success.

Enjoy.

As a web developer, you’re constantly approached with pulling off zany schemes. In the words of Ian Malcolm:

Yeah, but your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.

Replace “scientists” with “designers” and you see the dilemma. They know you can pull off some funky effects in flash, so they opt to flash. However, flash is still not quite as easilly accessible and searchable that we all would like – and please, you can try to argue this point, but the majority of flash efforts I’ve seen tend to bypass the accessibility and searchability because it’s just easier to do the cool animations/sounds/effects/transparencies in flash (or flex) than it is to do in javascript.

Internet Explorer be damned!

The unholy bastion of a front-end developers existence tends to fall on IE6 – which is at 24% and dropping in its market share. This is always the what I end up falling on when talking to a fellow developer, and it usually goes like this:

Me: We could totally pull off that flash effect! We can do multiple animations using mootools, and it’d be indexable and still be applicable without javascript if we code it right!

Him: You mean those large transparent PNG images that would be sliding into place?

Me: Right! We could..totally… pull it off… in everything except IE6….

Him: …

Me: …shit.

I mean, this isn’t too far from the truth, but the point is – accounting for IE6 is a bitch. I recently had to redo someone else’s code that used a PNG script I had rewrote because the alphapng filter was hitting multiple images on the page (dozens of images had a filter alpha opacity of 1). A quick audit of the code and reorganizing the javascript (ahhh… another blog post for the future, me thinks?) and suddenly IE6 was back in action, faster than ever!….not really, but it was at least usable.

So you see a lot of our ideas rely on javascript being utilized – or flash, which still will rely on javascript to be embedded – again, because of IE and other cross-browser issues – so we need to keep in mind that hankering feeling…

What if they don’t have javascript?

No doubt, some people with disabilities may still be able to use a site that utilizes javascript. It’s possible that they may have some ability to use a browser, but if they don’t turn off javascript, it may make it a more difficult browsing experience. Don’t forget, there are a plethora of mobile browsers that may/may not do javascript well, if at all.

This falls into a certain realm of uncertainty – and as I ran through a gamut of big e-tailers sites (American Eagle, Anthropologie, L.L. Bean, amongst others) L.L. Bean was the only one that I could purchase from (well, reach a point where they ask for payment).

The inherent problem of this, they rely on AJAX calls to do their server side form validation – so it’s possible that if you don’t have javascript, you could still enter bad data and find out your Christmas order is incorrect, maybe too late when they call to tell you why your credit card was declined, or that it was sent to a non-existant address.

Understandably – from a SEO perspective, they only need to index up to the product pages. If they’re smart, they don’t have any “highly relevant, high-traffic” content in their shopping cart pages or payment pages (it seems that those are generic, so it should be moot). The dilemma occurs in how they handle that percentage that is browsing without javascript. Maybe it’s a small percentage. Maybe it’s corporate users, or users from the large assortment of mobile devices. The point is – why should you neglect a sale just because they’re on webTV?

Enter the Dragon <noscript>

PPK on quirksmode wrote about the use of <noscript> and it’s use in helping point out (to the majority of browsers) that we can throw a little message stating that “hey – you need javascript.” I’ve looked at L.L. Bean’s source code, and they’re littered with <noscript>. But really, this shouldn’t be a concern as…
You shouldn’t be catering to a rich experience.

Really. You should be presenting a website that works – period. I should be able to hit it in lynx. In Safari. My iPhone. His blackberry. IE6. IE5. We shouldn’t be relying on javascript to pull off effects and basic, fundamental functionality. Javascript is an enhancement, not a requirement. If it’s required, you’ve failed.

I’m not saying I’ve got all the answers – but I do know that if we want to code in a way that no matter what crap happens in the near future, we need to focus on the basics and get them executed as cleanly, and simply as possible.

There may be a point that we finally say – okay, you’ll need javascript to get these cool “up to the minute” updates, live editing, in place context editing, etc. But that’s really at a point when you have to decide – who is this website for? Who am I catering to? Why do I care if the degraded expeience means things pop instead of fade in? More than likely, this same day will be when you say…

Shit, a fraction of a percent of people visit my site on IE6. I might want to tell them to upgrade.

Something I see brought up on occasion are people that do not understand the concept of addEvent:

• Custom Native to allow all of its methods to be used with any DOM element via the dollar function .
• These methods are also available on window and document.

And as shown on the new unofficial mootools mooforum -  people can get lost when we talk about mouseenter/mouseleave events – they are not Mootools Events, but generic javascript events with a slight tweak!

The difference between a Javascript Event and a Mootools Event

Instead of ‘onclick’ or ‘onsubmit’ or ‘onchange’ we do ‘click’, ’submit’, ‘change’ – it’s a little syntax difference that people forget sometimes.

Just to clarify: