10 Rules of Front End Coding
What follows here is a series of 10 things to remember and practice on each web development project. I have listed them here in order of importance as many of the steps build on each other. If you take nothing else away from the reading, please take Rules #1 and #2 to heart and practice them. I think solving those two problems will lead to better design and better implementation in websites across the Internet.
1. Charge Enough, and Then Some
Especially in hard economic times, business and individuals alike are trying to cut costs and keep projects down to a minimum. Due to this knowledge, we as web developers try to move through each phase as quickly as possible. Front end development, however, take a substantial amount of time if done properly. Not adequately charging for that time leads us as developers to skip over things we know are important just to keep the project within the budget. The rule is simple… you normally won’t take the time to do it right if you don’t have the time to take. The only way to get more “time” as a developer, is to guarantee the time we DO spend is properly compensated. At that point alone can our hearts and minds be fully plugged into our projects… and only then can we take the time to follow the remaining 9 rules.
2. Educate The Designer
For those who are a designer/developer all-in-one machine, this one should be easy. However, coders who work with or for a designer who creates an uncoded website have a unique responsibility. As many designers come from a print background, it is up to you, the developer, to educate them on the possibilities available to their designs. No… I didn’t say let them know about the 150+ jQuery plugins you use, or your thoughts on using a UL/LI combo vs a series of A tags. I said educate them to the possibilities. Help them understand how their design might display on different devices. Help them understand how to leverage repeating backgrounds and tiled patterns to achieve great designs with minimum file size.
Don’t leave the creativity solely to the designer either! This is your chance to prove you are creative as well by finding the perfect technology solutions to meet the needs of the designer. Telling them “it just isn’t done that way” for every request is a sure-fire way to cause frustrations on both sides. Put your mind to work finding ways around hurdles.
Note: Rules 3 through 10 build off these first two rules. Some of the following rules require additional graphic design service, and all the rules take time to follow. Make a commitment to rules 1 and 2, and the remaining rules will both make sense and make your finished product that much better.
3. Think in Layers, Not in Slices
Even today, we still use the phrase “cut up the design” to describe the process of moving a design from Illustrator or Photoshop into the finished HTML/CSS layout. While this is still largely accurate, its name belies the former concept of slicing a design into pieces and reassembling it (usually in a table) back on the HTML page.
That was the old web. The new web uses the concept of layering, stacking, and z-index to achieve designs with depth. As a coder, be sure to get layered PSD files or layered AI files from the designer vs. a flat design. This will allow you to have much more flexibility in how you put together a web site. Remember, when working in layers, consider the HTML elements that are essential to the structure before resorting to adding additional divs and spans. You can use a repeating vertical pattern on the html element, and a repeating horizontal background on the body element without bringing the dreaded div#wrapper in to solve your background woes.
4. Use the Best Image Format
What is the “Best Image Format” you ask? It’s the one that is best suited to the task at hand. PNG, GIF, and JPEG files all have different advantages. When there is no transparency in an image, test out which file size/image quality is best between PNG, GIF and JPEG. For large images, JPEG will almost always win for quality vs size. For small images without transparency, see which has a better file size PNG or GIF. If you decide on a GIF, be sure to play with the dither options and the lossy options (Did you even know Photoshop has a “lossy” option for GIF?). Often you can squeeze even smaller files out of Photoshop through adjusting the output settings even further.
For images that need to have transparency, make educated decisions on how they will be used. If they will be layered over a complex background, you may need to consider using a PNG file. If the background is consistent enough that the color matte of a GIF won’t stand out poorly, see if the GIF file is smaller. GIF has the advantage of not needing additional programming to make it work in IE6.
Regarding JPEG use: If you use JPEG as part of your user interface (and not just to display a photo, etc) be sure to leave off the ICC profiles when saving for web. Certain browsers will honor the profile and produce a color difference between GIF/PNG and JPEG files of the same color. This is a simple problem to avoid by just turning off the ICC profiles.
What if it is a lose-lose situation? There have been times where I need the full transparency of a PNG with the image complexity better suited for a JPEG. In these cases I often stack (remember, think in layers) two images: a PNG for the transparency, and a GIF for the complex image aspect. It is creative problem solving like this that will ensure your pages load quickly, and that the design retains its integrity.
5. Know When to Use Classes vs. Ids
I thought this was just common sense, but apparently it isn’t as I see many coders using class names where they should use ids. It may not seem like a big problem, but it will when you try to target an element using Javascript.
The concept is simple, if there will only be one element on a given page, use an id. If there will be multiple instances on a given page, use class names. Anytime an element is one-of-a-kind, use an id. Its that simple! Things like ul.navigation for the main navigation bar or div.site-logo make no sense. Each of those elements are distinct and should have and id.
Instead of adding another rule to our list, let me lump something else in here: don’t use too many classes! Take the following code for an extreme example (Notice that classes appear six times):
<div id="navigation"> <ul class="navigation-links"> <li class="nav-link-wrapper selected"><a class="nav-link" ... >Home</a></li> <li class="nav-link-wrapper"><a class="nav-link" ... >Contact</a></li> </ul> </div>
All that could be replaced with the following (A single id and a single class):
<ul id="navigation"> <li class="selected"><a ... > Home</a></li> <li><a ... > Contact</a></li> </ul>
For those who code frequently, you realize this is a ludicrous example, but it shows the fallacy of over-using classes. Use only what you need to correctly style and enhance (via Javascript) the HTML, nothing more.
6. Make Your Pages Responsive
Its important that the page responds correctly as the end user navigates through it. Using conventions like image rollover effects as well as :hover, :active and :focus states cannot be stressed enough. You don’t want to assault the user with too many interactions or styles but most people respond well to visual feedback. Here is an easy one for you: links should change state when the mouse hovers over them… period! It is not enough that the browser displays a little hand indicating a link. I can’t tell you how frustrating it is to search through a page with black text looking for the dark gray links and hoping and praying that the hand appears letting me know I found one!
Using conventions such as the “You are here” indicators or descriptive tool-tips all fall under this category. The more interaction and feedback that appears to the user while they navigate through a site, the better.
7. Always Use CSS Sprites for Rollovers
If you don’t know what CSS Sprites are, check out this article at Smashing Magazine or this one at A List Apart for details. For those who DO know what they are, why don’t you use them!!? If you tell me its due to a lack of time, I want to refer you to Rule #1 in this list. Past the time argument, I can’t really think of any benefit more important than using CSS Sprites for image rollovers. Check out the Starter for jQuery site. Almost all the user interface pieces are built using a single PNG file (pictured below). The interface loads all at once, and all the hover/active states are immediately available. No delay for a :hover image to load; One request to the server, not 10+. This a fantastic tool in the Front End Coding Toolkbox that developers need to use more frequently.
8. Understand the Difference Between Flash and Javascript
I think Javascript can do amazing things. I also love pushing the limits of what it can do. I love making widgets and plugins just as much as the next guy… but Javascript cannot solve all the problems in dynamic web development. Instead of spending 10 hours emulating a Flash feature that would take 1 hour to make in Flash, make the right choice and choose Flash. On the other hand, if you just need an image rotator… don’t you dare open Flash!
9. Test Your Site in Many Browsers (including IE6)
This one takes time, there is no doubt about it. I develop on a Mac, and have a PC (and multiple Virtual PC environments) that let me test is most of the normal browsers people use today. Unless you have Google Analytics reports that say no one uses IE or everyone uses Firefox, don’t make an assumption on how people will browse your site. I am not saying make the sites look identical, but make them work, function, and look nice (And certainly similar!) in most browsers.
Note: I mention IE6 specifically because my largest client is a corporation that still uses IE6. I have developed a coding style that allows me to build rapidly for modern browsers, and implement only a few style sheet and javascript fixes so the site looks right in IE6. I am sure I lose some edge by doing it this way, but it saves me from many embarrassing moments.
10. Always Keep Maintenance In Mind
As you are “cutting up” a Photoshop design, or preparing your CSS and Javascript, keep maintenance in mind. Some crazy-cool CSS hack you use today may come back to haunt you later. Dumping CSS rules wherever you please in a CSS file may seem fast at the moment (Guilty!), but will make changing and updating them later a nightmare.
An important step to remember occurs after you have prepped a designer’s file for export from Photoshop or Illustrator: Remember to save a version of the file just before export. That way if you need to re-export it later, add another button, change a line of text, etc., you will be able to export it again quickly. Photoshop normally saves Image Format choices, compression settings, and matte colors to make your job even easier.
Conclusion
There are a number of other things that are important for Front End Coders to keep in mind, but I think these are some of the most important. Many could argue that these aren’t rules, but I challenge you to think of them as such. Perhaps you will be less likely to break them in the interest of time or money on your next project. Remember, these rules still apply if you you’ve received a web design from an outsource web design service like DesignCrowd.
Doug Neiner is an Editor at Fuel Your Coding and an official member of the jQuery Team. He is addicted to new technology, and specifically loves spending time with WordPress, Ruby on Rails and jQuery. Learn more via twitter or his Google Profile.



Thanks Doug, inspiring stuff.
I feel guilty for all of these rules I regularly transgress – but as you wisely point out, it’s my own fault for not allocating enough time to doing things properly.
rules are there as a guide, sometimes you gotta be aware of them, but still continue breaking them ;-)
“For those who DO know what they are, why don’t you use them!!? ” See point #9.
I have the issue that many designs require some sort of alpha transparency for the rollover and then the requirement is to make it work in IE6… So CSS Sprites, while really nice for most projects, cause some problems with positioned backgrounds and IE6 png hacks.
This is a great writeup and things that front-end developers should be living by, for the most part.
I disagree with charging extra though, as it’s a really poor business model to have, if you’re charging by the hour; pad your hour estimate, and if it takes that long, you covered yourself – if not, don’t charge the client extra. It’s rude. If you think you aren’t being paid enough, or if it’s not worth the effort you put into it, raise your rate – but pay attention to your conscience. Also: making a page entirely responsive is not always possible – you just can’t dictate that as a “must do” for front-end developers. Not every site is a typical web 2.0 site, and not every site has as much freedom. I work with a team of designers, and we try to make things as interesting as possible – but depending on client demands or the overall design, making every input field change or every link change state may not be the best idea, or possible at all (without taking too many liberties outside of the creative direction of the site).
Just my thoughts. Aside from that, though, this is massively important.
I second the CSS sprites thing – don’t get me wrong, I LOVE CSS sprites and use them whenever possible. But IE6 in some instances totally chokes on CSS sprite rollover states, which means you have to create a whole second set of independent images for IE6 and code your stylesheet to not sure the sprite image.
Sadly IE6 is still prolific in offices across the world, so we’re not out of the IE6-woods yet…Once IE6 goes the way of the dinosaur (why won’t it die!?), then all will be right with the world.
@Dave Thanks! Don’t we all feel guilty for what we leave out…
@Bryce and @Jeff I agree that sometimes one rule “overrules” another. However, I put it in the list due to the number of designs I come across that are perfect candidates for CSS Sprites, yet they still aren’t used. Good points about IE6 Though!
@M Way I think we were both saying the same thing: Allow enough time to design the front-end correctly (Whether in hourly estimate or job price). Obviously, if you underestimate the project time, you shouldn’t charge more to do a good job… you should learn, and not make that mistake again! Sadly, the tendency is to rush through the parts of the project that go over budget which is why it is so important to quote correctly in the beginning.
Its true you can’t always add responsiveness to every part of a page… but I would advise that a developer be sure the lack of interaction is a conscious design decision and not just an oversight on what is available or what is the best practice. In your case, at an agency, I expect this would be less of a problem.
Thanks for the feedback guys!
Good article! I agreed with most of it, however change enough is a bit tough for now, beside as a web developer to designer should know, we have to educate our client to make them understand whats the important of front end design and how much thing we will take into consideration, is not so simple what they think of web design/HTML by using just Dreamweaver. Classes vs. Ids for this might have many designer still find a bit too technical to them. Of course whoever understand is a plus point.
Hi
I am a designer and developer both.
A very nice article overall. The first two points are very correct, especially the first one if you client is a non-tech person, which usually happens, for them what they see on the screen is the product, they are not interested how much coding you have done inside, how much complexity is involved just in making a drop down menu etc. So I think the Design/Interface is the only way to make your client understand how complex work you have done ;)
So make sure you charge good enough for the Front End (including the back end coding costs).
Thanks
Good article and sound advice for the most part. Gotta disagree with you about links changing state when the mouse hovers over them though. I totally agree that links need to be marked out from the rest of the content somehow, (nothing more annoying than people’s twitter pages when all text is the same color, inc all links) be it by underlining them or using a different color from main text, but I don’t think it’s essential that they change state. Look at the links on this page for example. They don’t change state but there’s no way your gonna miss em either.
I am a web designer and front-end developer for a while now and I must say – we should stop testing against IE6 and drop the support as soon as it’s possible. If developers and designers won’t have balls to do it, we will never get rid of it. And let’s face it – this browser is outdated (IE8 is stable now), not standards-compliant and should be rid of, just like NN4 was.
Good article Doug!
I’ve learned most of the things in here the hard way. Still most of these things sound logical now, and they are really great points to keep in mind.
This should be read by all people starting out in webdesign / webdev.
Great article, but I’d expand on your 5th item, Classes vs. Ids:
You’ve outlined the basic distinction between a class and an id, but your explanation about when to use each could use some refining, because it’s not as simple as “if it’s only used once on the page, use an id; otherwise use a class,” and doesn’t get to the heart of why people are (often) using them incorrectly.
The important distinction between classes and id’s is implied in the words themselves: an id is a specific identifier for a single individual; a class is the name of a more generalized group to which that individual belongs. To use myself as an example, my id would be “saraweythman,” and my class might be “obnoxious” or “tall” or “designer” (or even all three at once). The cascading specificity inherent to CSS means that you don’t have to have a different class for every element (in fact, you shouldn’t — that’s the whole point). IDs are there so you know what element you’re talking about; classes are there to tell you what that element should look like.
Let’s see if this example works:
person { arms:2; legs:2; head:1; }
person.designer { platform:linux; code-family: CSS, HTML, Ajax, PHP; geekiness: 100%; }
person#saraweythman { height:tall; eyes:hazel; voice:loud; nerd-variant:total-spaz; }
person#saraweythman.designer { platform:mac; code-family: CSS, HTML, PHP; }
If I could render that, person#saraweythman.designer would have 2 arms, 2 legs, and a head, be tall, hazel-eyed, loud, a total spaz, work on a mac, know CSS, HTML & PHP, and be 100 geeky.
Very interesting read and I hate to quibble on something like semantics, but you liberally abuse the term “coder”. As a coder what you are describing is not coding. Writing HTML & CSS is merely text markup, where coding would involve either client or server side languages like javascript or c#. Coder is synonymous with Programmer: http://en.wikipedia.org/wiki/Coder
The only reason I brought this up was because I was rather confused the first few times you used the term and it wasn’t until half way through that I realized you were using the term improperly. I know that designers like to call html “code” but it’s not and it can be rather disorienting to us engineers when the term is applied improperly.
Doug,
This was a great read! Keep up the good work!
Great article Doug! Plenty of good points and well laid out! Especically love the Classes vs ID’s example. Very important!
Great article. I’m looking forward to reading more of your stuff.
I have an exception to rule #5. I totally get it and practice it myself whenever possible. The problem is, I do a lot of work in C# .Net and the ID’s are typically reserved for the back-end processing hooks. There are workarounds to this, but I often find it easier and less error-prone to just use classes and reserve the ID’s for the processing language. Plus, some of the developers I work with don’t understand how CSS works and trying to explain why I am using an ID instead of a class often gets tedious.
Anyway, I agree with everything in the article (including #5) but just wanted to share when it might be “acceptable” to use classes over ID’s. I also agree that sprites are the way to go and getting them to work in IE6 is not that difficult and should definitely not deter anyone from using that approach. Although IE6 is still too prevalent to disregard, we do have to keep moving forward as designers and take advantage of what the newer browsers have to offer.
Same here. I don’t code .Net myself, but often work for a company that does. So whenever I do the HTML for them, I almost only use classes or else I’ll be having to redo my work because of the changes in ID’s.
Nice read. You’ve covered the topic well :)
Interesting article! And about IE6, sprites and PNG hacks, it’s working well when using the DD_belatedPNG hack, which doesn’t use filters but VML magic to display transparency, thus allowing background positioning and/or repeating.
Tried a LOT of png fixes which uses different approach and DD_belatedPNG has always been a favorite of mine. The VML thing is really wonderful isn’t it? Drew Diller is such a genuis :)
Css sprite is a technic used in alot fo great website, including google. The ie6 flikering bug is not much considering you would have to load your hover images in every browser instead , and would have flickering issues (unless you preload in JS which is actually worse).
Think for the future.
This is excellent. I would agree with Hugh though, on the links. I would say either change states on rollover OR standout from the regular text. Or both. But like he said, there are links on this page that don’t change states, however they are not at all hard to distinguish.
Second, I wish someone would write an article like this from the other perspective. 10 (or 1000+) rules of web design for print-only designers. Or something.
Verry Good article!
very nice article, thanks for putting this together
I think it’s time to stop supporting IE 6, if all websites stopped supporting IE 6, then it would force businesses to upgrade. Making the users happy (because once they get used to IE 7 they will be happier), and it will save the CSS designer a lot of time.
Some great tips to remember
Thanks!
Very good list. I am a designer + front-end developer so I have it much easier but this is a highly useful list anyhow.
Excelent article!
So, I’m doing very well my work!
Thank you!
Useful articel for my professional stuff.
Really good article thanks
very good reminders!
Great article – I use some of these, but there’s some that I’ve ‘overlooked’ (oops!). Still havent’ got round to using sprites – and I don’t know why!! it seems tricky, but I know it’s not!
Great tips! Coming from a traditional design background, #7 – Always Use CSS Sprites for Rollovers – was something I didn’t know about. Not sure I’ll utilize it since I work on smaller websites, but I can see the possibilities.
meredith had suggested “an article like this from the other perspective. 10 (or 1000+) rules of web design for print-only designers.” I couldn’t help but oblige. :)
Ten rules of web design for the transitioning print designer: http://bit.ly/BIvs3
I’d love any feedback, especially coming from front end developers.
Good sensible tips. When it comes to keeping maintenance in mind, it’s worth thinking about naming conventions (for both layout HTML and ongoing content). I also try to build a neat & tidy folder structure before I start so the client/web manager can figure things out once I’m done with the slicing.
I seriously believe every front-end web developer should be reading this. It disappoints me a lot when I see ‘aesthetically beautiful’ websites, which, upon code inspection, would prove to be pieces of junk. We should always be reminded that the beauty of a web page is not measured by ‘how it looks’ but by ‘how it works’. Semantic and structured HTML, clean CSS, informative and usable navigation and content, optimized images… the list goes on and on. Web design is not a ‘basic’ task, and every ‘genuine’ web designer/front-end coder knows that.
pretty useful stuff, overall I think this is worth a bookmark, thank you
great article, first of all. as you mentioned “thoughts on using a UL/LI combo vs a series of A tags”, do you know an article on this topic? cuz this is a debate i have had in my mind and with some other developers, i personally prefer just a serious of a tag cuz it’s simpler, cleaner, and it’s all that is really needed. the concept of a list is what we add to a navigation, which is not most intuitive and creates extra makrup and css work,
some really useful reminders out there !