StylizedWeb

Subscribe to our updates:

A Design, WordPress and Tutorials Blog.

Dedicated to helping you learn the art and science of the web.

8 methods to bring your front end coding to rockstar levels

There are a lot of good front end developers out their right now. If you fancy yourself as a front end editor then you really should be looking at how you can differentiate yourself from the rest. Yes there are lots of "good" front end developers, but there are not a whole lot of excellent front end developers.

1. Improve Your Semantic Names

If you work in a team or ever revisit your code and need to update it then you should think about the quality of your class and ID names. It is not uncommon for developers to use class names like "box", "wrapper", or "container." While you may think that these naming conventions or "semanitc enough" none of them describe the content that is inside them. Instead consider using HTML5 spec's such as "content-sub", "section", "content-aside" or "content-sup."

You and your team will have a much easier time sorting through code that describes the content than trying to remember the details of "box."

Read more about semantic naming from Andy Clarke and A List Apart.

2. Improve the Organization of Your Files

I think it is reasonable safe to assume that most developers have at least started to organize their files by type (ie: a folder for images, css, javascript, etc...). You can go a step further and improve the organization even more, particularly any folder that is going to have a lot of files (such as Images in particular and CSS as a secondary.)

I find it best to create sub folders with in images and separate images based on design structure, buttons, headlines, photos, etc...

There are plenty of other folders you may want to create to keep the updating and growth of a site easy and efficient, including:

  • Documents
  • Client files
  • Copy
  • Proofs
  • Staged/Development area (folder for a "clone of the site" where you can make changes and get sign off)
  • Downloads

The Elements CSS Framework does a great job of organizing files based on the normal client/provider workflow.

3. Use Commenting in Your XHTML

Any time you end up developing complex layouts you are bound to use a lot of <div>s in your markup. This can be particularly confusing to go back and edit as it becomes hard to figure out which div is being closed where. You may see three </div>s all in a row.

To combat this simply add some coments at each </div> (or any other closing element if you find that it will be helpful) to let you know what element was just closed.


     <div id="header" class="section">
          <div id="header-logo">
               <h1>HTMLiZER</h1>
          </div><!--/#header-logo-->
     </div><!--/#header-->

If you find it useful you can take it one step further and comment the primary area you would be editing (such as the main content area, sidebar, etc...)

4. Segment Your CSS

For small 4 - 5 page brochure sites your CSS will be pretty manageable even if you don't spend the time and effort you should into organizing and commenting. Once you start developing web applications or large sites with a vast array of design "modules" you should make sure that you organize your CSS in way that is easy to manage.

I recommend splitting your css into logical different files for better organization, such as:

  • reset.css
  • main.css
  • structure.css
  • typography.css
  • print.css
  • helpers.css

This way you don't have to sort through all of the typography styling to find the area where you defined the size of the header. Likewise if you want to adjust the headings it is pretty simple to find it through a small typography.css file rather than a huge file that has everything.

5. Create a TOC With Comments in Your CSS

Every CSS file you plan on editing and extending over time should have a table of contents at the begining and a headline seperator at every section. This will allow you to easily jump to a section using "find" rather than scrolling for that one area that had the CSS you are hoping to modify.

EX

/***********

TOC:

=1: Header
=2: Content
=3: Footer
=4: Navigation
=5: Portfolio

****************/

/* *********  =1: HEADER *********** */

#header { ... }

6. Compress and Combine Your CSS files

Even though it is easier to work on a site when you segment and organize your css into several different file names, it actually causes your site to load slower. The more calls the browser has to make to the server for additional files the slower it will load.

Before deploying your css files you should combine and compress them. Compressing them removes any uncessary whitespace, comments, etc... that is unnecissary when the site is live.

There are several handy tools to do this including this online version.

7. Create your own framework (or improve on another one)

As you get more experience under your belt you will find that you use the same methods and naming conventions over and over. This is helpful for several reasons and it should be encouraged. It has lots of benefits including:

  • More consistant rendering due to reusing ideal CSS techniques
  • Easier editing and maintenance as you can better recall what names mean
  • The start of code that can be saved and reused every time

Chances are that you end up rewriting the same type of code over and over again, simply because you don't have it stored somewhere. Some examples may be:

  • A class that floats an image left / right and gives it some margin
  • The structure for an unordered list navigation
  • The structure for a form
  • external link, pdf and download icons
  • clearfix
  • png fix
  • Typeography baselines and hierarchies
  • etc...

Rather than reusing these bits of codes write modules into your own CSS framework (or you could imrpove on another one). This way you can streamline the development process so it takes less time and improve the consistancy of your work.

8. Develop your CSS to be modular or "object oriented"

You could assign every bit of code an unique ID or adjust the margins and padding per instance. Lots of coders do this to try and get the CSS as close to the designers comp as possible. However this is inefficient in development time and file size. Establish a set rule for differnt types of content and how they should be styled, this should include basic things such as:

  • Font sizing (all normal text is 12px, featured text is 14px bold)
  • Margin's (normal margin is 10px between elements, margin between two content blocks is 40px, etc...)
  • All navigation tabs will have 15px height and 13px font
  • etc...

This way you don't have to rewrite the code for every new item added to the site. Additionally it will keep the site feeling consistant and well balanced visually. If all elements and every page follows the same rhythm it will feel more unified as a whole.

Some call this object oriented css, it is worth looking into for rockstar like front end coding.

Leave a comment on Stylized Web Have some feedback? Leave a comment

31 Comments So Far

  1. Pingback: 8 methods to bring your front end coding to rockstar levels : Design Newz

  2. Very good article. All front end developers should read this. I think you got a little lost with the ‘modular’ and ‘object orientated’ terms for number 8 though. ‘Cascading’ would have been enough. That is the whole point to CSS.

  3. Some very good points here.

    Sometimes HTML comments can produce unwanted extra content in IE6 so if you’re randomly getting a few characters of text seemingly repeating on the page – it may be the comment that’s to blame.

  4. Pingback: popurls.com // popular today

  5. Pingback: 8 methods to bring your front end coding to rockstar levels « Ideas | Ideas collected from the world of excellent design

  6. Object oriented is more relevant in programming languages such as C# and C++. But I get what you is meant in this article.

  7. By wasser posted on March 31, 2009 at 2:48 am

    I don’t really agree with #4. Too many http requests. Good commenting should suffice.

  8. By wasser posted on March 31, 2009 at 2:50 am

    ok, sorry. i guess #4 and #6 are contradictory? or do you mean, develop with separate files and combine when deploying? because that would make sense :)

  9. Yeah. Its mostly common sense and you know to do this but, you get sloppy and don’t

  10. You can never learn too much. This is something I have been really looking for. Great compilation. Thanks for posting!

  11. Pingback: ITキヲスク | 2009年3/30~4/5の週間ブックマーク

  12. By Tony posted on April 8, 2009 at 3:46 am

    Uhmm.. #9 Stop using XHTML when it’s not necessary.. A mistake everyone makes. Your XHTML validates? bravo.. it probably doesn’t work when served as the proper mime type.

  13. musical sites thanks.

  14. Great article. I am enlighted about css.

  15. By Blake posted on May 6, 2009 at 4:10 pm

    #4 is actually quite silly. Not only is it too many HTTP requests, but it actually makes it harder to find the style that you need. If all of your styles are in one CSS file, a simple ctrl+f will help you find the style you need in less than a second. That way, you don’t have to have 6 different CSS files open during development.

  16. Play Free Online Games, sports games, massive multiplayer games, action games, puzzle games, flash games and more, casual games.

  17. By Tony posted on May 15, 2009 at 7:46 pm

    @Blake, I agree. I always have just one big honking CSS file. Separating only css files for particular browser fixes..

  18. This is a really informative article. With regards to point 4 would it just not be easier to use comments in your CSS to help you manage it better then creating individual CSS files. This way you would not need point 6 as your CSS will be nicely organised.

  19. fenerbahçe’nin 12. gücü
    tenks admin

  20. fenerbahçe forum
    tenks admin

  21. Html % PHP on numara kodlama dillerinden kendisi
    Windows 2003 server filan filan işte İngilizcde (Engish) bilmiyoruz sallıyoruz :D

  22. Thanks for the post. Hopefully soon I’ll be at Rockstar level.

  23. That is a good article for css thank you admin

  24. Pingback: A DIY Web Design Education - Noupe

  25. Pingback: A DIY Web Design Education | SeanBurdick

  26. you say first to segment the CSS files and right after to combine the CSS files.

    Using names such: “content-sub”, “section”, “content-aside” or “content-sup.” is a wrong method. What if you want to use these classes in other places?

  27. @ken the tech – The combination is a pre-launch step that reduces load time. Keeping them segmented before launch is an organizational step. Both are valuable techniques.

    Regarding naming conventions, if you are using the names properly such as “content-aside” , sup, etc… you are defining specific regions and areas on the page. Why would you ever want to use them in another place? You are going to be defining, width, position, etc… there would rarely be a reason to reuse them in other places as they would contain location unique coding.

  28. Pingback: A DIY Web Design Education » Shai Perednik.com

  29. %100 Doğal ve hiç bir yan etkisi olmayan Uzamax’ı keşfedin
    UZAMAX içeriğinde mineral ve vitaminler barındıran, doğal bitkielerden üretilmiş gıda desteğidir. İçeriğinde herhangi bir kimyasal ürün bulunmamakla birlikte tamamen doğal kurutulmuş bitkisel bir karışımdır. Sadece birkaç aylık kullanım kürü sonrasında bile uzamax’ın etkisini hissedeceksiniz.

    Uzamax kullanarak doğal yollarla bünyenize gerekli olan tüm besin, vitamin ve mineralleri vücudunuza almanızı sağlar.izlanda yosun hapı

  30. Hi there! This post could not be written any better! Reading through this post reminds me of my previous room mate! He always kept talking about this. I will forward this article to him. Pretty sure he will have a good read. Thank you for sharing!

  31. you say first to segment the CSS files and right after to combine the CSS files.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>