Setting your own standards; Keeping your mark-up consistent

October 30, 2006 | Published in: Accessibility, Standards & SEO | Tags: , , 8

Indenting your codeWebsite coders often find themselves working on a variety of web sites, and when starting out, and learning new methods and techniques everyday, the mark-up used can often be messy, random, and inconsistent.

When working with someone else on a project the problem can be even larger, especially when you both have unique ways of doing things, which can cause confusion, drastically increasing project development time.

But how can this be avoided? This article focuses on setting you own standards, creating re-usable snippets of code and web documents, and the benefits of doing so.

Why set your own standards?

These days almost everything is affected by some sort of standard, and all have a common goal; quality.
This also applies to websites, as quality is important to have good, semantic, easy to read mark-up.

The benefits can really be noticed, for instance, if you code a site messy, with elements all over the place with poorly formatted lines, your just going to make it harder for anyone; including yourself, to understand and make changes to what you have written.

And the changes you could make to improve on this don’t have to be too taxing either, indenting your mark-up and choosing consistent class and ID names can really help people to understand your mark-up, and if you ever want to redo or add to it, it won’t take as long to do so.


Formatting your web pages

When setting your own standards for formatting pages just do what ever your comfortable with!
No-one can tell you how to structure your page, so as long as its readable and easy to follow then your on to a winner.
Things to consider include:

  • How will you indent your mark-up?
  • What ID and class names will you chose?
  • How will you style the elements?

By choosing these. and sticking to them, will really help you improve the quality of your pages.
This also applies to your CSS documents, as well as your web page mark-up. In fact it can apply to anything you end up coding, it really will make life easier.

Choosing class and ID names


When choosing names, give them meaning, and keep them consistent.
If making a container div what will you call it? How will you capitalise the names of classes, Camel type? (e.g subContent) with underscores? (e.g sub_content) with capitals first (SUBcontent) What will you use ID’s and classes for, ID’s for main elements?

There is no correct way to choose and format names, so pick what your most comfortable with, but remember:

  • Keep them formatted consistently
  • Make the names descriptive
  • Choose names that describe their function: not their presentation (e.g use mainContent not leftContent, since what would happen if you moved the main contents position? It would be wrong if called leftContent so you would have to recode!)

Indenting and commenting your mark-up

When writing, good indented code and mark-up can really help when revisiting it at a later date, or just reading through it. Take this for example:

<div id="container"><div id="content"><p>I am a poorly formatted and poorly
Indented snippet of HTML!</p>
</div><div id="footer">This code looks <span>nasty!</span></div></div>
<div id="container">
        <div id="content">
                <p>I am a formatted and properly Indented snippet of HTML!</p>
        </div><!--end content-->

        <div id="footer">
                <p>This code looks <span>nice!</span></p>
        </div><!--end footer-->
</div><!--end container-->

If you were reading the above snippets of code, which would you find easier to follow? It only takes a small amount of effort to indent and comment your markup, and as shown, it can really improve readability.

CSS file formating

If you have coded your site well, and semantically, the CSS file will be the main file you edit to make visual changes to your sites theme. Therefore it is imperative you format it so it is clear and easy to read and modify. It is a good idea to always:

  • Comment your code
  • Indent your file
  • Divide it into sections e.g paragraphs, headings, anchors
  • Keep any hacks separate

So set your standards, decide how you will write your files and stick to it.
So for me, I always have a quick overview at the top of the file, then I have clearly marked sections with different element types in them. I also use tab to indent, and start { and } on newlines to keep it tidy. Example:

/*---[body / universal]---------------------------------------------------------*/
body
{
        text-align: center;
        background: #36444C url(images/wide_tile.gif) repeat top left;
        color: #333;
        font: 62.5% "trebuchet ms",Verdana,Arial,Helvetica,sans-serif;
        border-top: 4px solid #fff;
}

Making yourself templates to use again and again

As you make more and more sites, you’ll find yourself doing the same things over and over from project to project. Why do everything again? Why not make a template which as all the basics inside it, and then reuse it.

I find this extremely useful, I always have a CSS template handy for example, which contains just the basic structure but with no actual styles.

You can download my blank template here if you wish. (right click > save as)

Going live

So you’ve made your pretty code, and its all ready to go live? Hold on! It may be easy for you to edit now, but, if you want, you could optimise the file size of your files.

You can optimise by removing all white space for a reduction in file size, some tools are available to do this for you. A good one for optimising css is at flumpcakes.co.uk.
Just as an example, my blank style sheet (download-able above) was reduced in size by 82%, quite a difference.

Just remember when you do this:

  • Keep a backup
  • Watch out if using hacks – comments are removed by the flumpcakes tool.
  • Keep a pretty indented version for editing on your machine
  • Only optimise when its ready to be deployed

Closing statement

I hope I have outlined a few useful pointers for making your life easier when coding, you may thank me in the future if you ever have to edit your site!

Found this post useful? Why not buy me a coffee!

Related Entries

8 Responses to “Setting your own standards; Keeping your mark-up consistent”

RSS feed for comments on this post.

  1. Mike Cherim says:

    As you know from our last project together I certainly agree with you feel strongly about maintaining a consistent method of writing stuff. Very good advice, Mike.

    Comment made on February 12, 2007 at 9:51 am

  2. David Zemens says:

    It’s easy to get involved in a project and become more concerned about how the output *looks* than how the code *looks*. This article is a nice reminder that they both need to *look* good. In the long run, we are all winners when the code *looks* as good as the site itself!

    Comment made on February 12, 2007 at 9:54 am

  3. Mike J says:

    You hit the nail on the head David :)

    And @Mike, we did good, even though I sometimes get carried away with PHP because I code so fast lol

    Comment made on February 12, 2007 at 9:55 am

  4. Mike Cherim says:

    You did good, Mike. You impressed me with your knowledge of WordPress.

    Comment made on February 12, 2007 at 9:56 am

  5. Will says:

    Good article. Since i found CSS and started to care more about my mark-up i always try to organise it. Its just so much easier when you come back and try to make changes.

    Comment made on February 12, 2007 at 9:57 am

  6. Mike J says:

    Agreed, when I started, my markup was such as mess, and im glad I changed ;)

    Comment made on February 12, 2007 at 9:57 am

  7. http://www.cere.be/ says:

    Very good stuff. I’m feeling very concerned with it in my daily worklife and tend to apply those principles as much as I can.
    Deserves a stumble ;) http://www.stumbleupon.com/url/www.blue-anvil.com/archives/setting-your-own-standards-keeping-your-mark-up-consistent

    Comment made on February 12, 2007 at 9:58 am

  8. Anthony says:

    You have just reminded me to take out the commments n my CSS files, It especially makes a difference when you have multiple CSS sheets due to IE inconsistencies. Great Article!

    Comment made on February 12, 2007 at 9:59 am

The comments are closed.

About this site

Blue Anvil is the online web design journal & portfolio of , a web designer from Norfolk, England. Read More »
ThemeSlice
  • Featured work - More

    • Beefjack
    • Integrity
    • theotaku.com
  • Latest Tweet - More

    • New blog post: MiniCard 1.1.7 Update http://blue-anvil.com/archives/minicard-1-1-7-update/
  • Out of the blue - More

    • MiniCard 1.1.7 Update

      I have just uploaded 1.1.7 of MiniCard here and to the WordPress theme directory. This updates includes:

      • New networks; xing, gowalla, yelp, foursquare, mobileme, google buzz
      • A way to change link text and define multiple links of the same network
      • A way to define your own custom links + icons
      • Improved admin panel

      Hope you like it, and don’t forget you can show your support by purchasing the premium pack from here.

    • Switched: From Shared to VPS

      It’s been about two weeks now since I made the transition from a shared reseller hosting account to a VPS (Virtual Private Server) account – impressions so far, excellent performance but fiddly to configure.

      The reason I wanted to change from shared hosting was the fact the server was always being hacked (even though ALL my scripts were secure), there was frequent downtime, support blamed me for problems every time, and it was slow as hell.

      Those used to a shared hosting environment would probably not know where to start when faced with configuring a VPS. Luckily, a lot of it was pre-configured when I received my account – certainly some of the major security holes were patched. I was not satisfied with those however. As a victim of hacking in the past (previous host swears it was not there fault, something I don’t believe) I took extra care to secure it as a much I could – configuring brute force detection, the firewall, installing mod security (excellent rules for that here: http://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules) and going though multiple guides (like this one: http://www.webhostingtalk.com/showthread.php?t=468168) with a fine-tooth comb.

      The result? My pages are loading at least 6 times faster, I have had no down time (or at least have not noticed any), and I feel in control and happy. No longer am I at the mercy of shared hosts :)

      If your interested, I chose ServInt as my provider as they offered a great deal, as well as being a managed service (so I’m not on my own if I screw things up). I was tempted by the bells and whistles of Media Temple, but felt the ServInt service was better value.

    • Download Monitor 3.2.2 Maintenance Release

      Download Monitor has received some more love and has been updated. Here’s the change log from the new version:

      • Small bugfix in uploader.php – cat ID
      • Changed stats graph calculation – thanks lggemini
      • Changes to headers in download.php to avoid caching
      • File Browser fixes – $root was clashing with something….
      • exclude_cat works in all sections of download_page now
      • Removed hardcoding of /uploads/
      • Added action to download.php – should be able to use it to stop a download if you want – maybe limiting downloads per day or something? Whatever you want…
      • Made it so if you post new file on ‘edit’ screen, the post date is updated.
      • Fixed the ‘blank meta’ section which blanks out custom field values when nothing is set.
      • Moved ‘allow_url_fopen’ check.
      • Someone said downloads don’t work with spaces in the name. They do! Wasting my time sonny…
      • All work and no play make jolley a dull boy
      • Had to rename capabilities so they work. Apologies if you have to set this up again! Cheers to Mark Dingemanse.
      • {category_ID} custom format tag added. Useful if you want to send someone to its category on the DL page I guess. Also added {category_other} so when no category is set “other” is shown – this is because the download page can show an ‘other’ section if you want it to.
      • You can now manually edit the post date on the edit download screen.

      If you have edited capabilities for download monitor user permissions, you’ll have to again sorry! This is because I named them too long. Also, you should check your forced downloads still work because there was a logic error meaning they may not have been forced after-all…

      Enjoy.

    • Mahousive update to Download Monitor (3.2)

      Today I completed the update for the Wordpress Download Monitor Plugin – many tweaks, fixes, and features added. There were no changes to the database structure so people upgrading should be fine. Here is the list from the change log:

      • {user} tag added for custom formats
      • ‘autop’ option fix
      • Download page buttons applied with CSS so they are easier to customise/translate.
      • Fix for pagination bug after editing a download
      • Category output fix on edit downloads screen
      • Category urls on download page use ID rather than name to prevent errors when cats have the same names.
      • exclude_cat added to download_page shortcode
      • Localised ‘hits’ ‘date’ ‘title’ on download page
      • Option to disable the download logging
      • Read file ‘chunked’ some people found large files were corrupted so this should help (fingers crossed)
      • Added show_tags option to download page – displays x amount of tags on the download page.
      • File Browser root setting and download.php logic/mime types modified thanks to Jim Isaacs (jidd.jimisaacs.com)
      • Interface Improvements
      • Bulk edit categories, custom fields, tags, member only downloads
      • Added roles for download monitor admin – should be able to use with a role manager plugin if you want anyone other than admin to access the admin section e.g. http://wordpress.org/extend/plugins/capsman/
      • Change redirect after add
      • Edit Cat names/parents
      • Dedicated tags and thumbnails fields (they still use meta table though)

      And yes, those category link bugs are fixed at long last, and you can edit category names finally. Phew!