Every developer has their own unique  way of building sites and setting up their styles. Every time I build a new site, the process and the styles change a little bit, to reflect changes in modern development practices. New techniques, scripts, and browsers show up every month. There are a 1000 ways to set up a WordPress theme. For me, it’s about a search for greater efficiency and sustainability.

When I say sustainability, I am talking about how easy it is to add to and modify the site and its stylesheet. Was that button you thought was only used once made into a re-useable class so you can put another one on a different page? What if an element needs to be moved to a new location in the layout? Can the person whose website was built in WordPress change all their content or are they sometimes presented with a foreign block of HTML code?

While managing a few projects that were built by freelancers, I came up with a list of guidelines for the build and for WordPress used as a CMS. I’ve added reminders to it based upon the mistakes that fly in the face of what I consider a “good” build. Note that some of this is a matter of preference and opinion. I thought I would put this out there as a starting point for anyone trying to put together their own guidelines. I am still modifying and adding to this; especially for WordPress.

General Build Guidelines

• Semantic coding without excess markup. Use h1, h2, h3, p, ul, ol, etc. Also avoid putting a class on everything by styling through a parent (shouldn’t need to be said!)
• As pixel perfect as possible. (try the firefox plugin PixelPerfect for overlaying design on build, or overlay a screenshot in photoshop)
• Cross-browser – IE7, IE8, IE9, Firefox, Chrome, Safari
• Validates at http://validator.w3.org/
• For IE fixes, use a class on the html element along with conditional comments, as used on HTML5 Boilerplate (e.g. html.ie6, html.ie7)
• Use CSS3 box-shadow and border-radius where necessary; use CSS3pie for IE support.
• XHTML transitional or HTML5 + modernizr
• Start with a CSS reset such as Eric Meyer’s
• Separate CSS rules clearly with comments for each section (header, main nav, footer, etc)
• JavaScript – We use the jquery library. Custom scripts should not be inline. But them in a single file before the closing body tag. We typically name this “custom.js”.
• Buttons with text on top should have HTML text where possible, so they can be re-used and edited. They should be styled to expand if there is longer text.
• Image buttons and their hovers should be on the same image, as a sprite, to avoid flicker on hover.
• Optimize images. Use 8-bit PNGs where you can, and JPGs should be around 70 to 88 quality. Use your best judgment to maintain quality and keep file sizes low. No one wants to see artifacts on overly compressed JPEGs.
• If @font-face is needed, include from Google fonts or grab from Font Squirrel. Either web-safe fonts or freely available fonts should have been used on the design.
• Don’t forget any CSS text-shadows that may be used (It is okay if these aren’t in IE7, as they often have issues).
• p,h1,h2 etc should be styled globally, and not individually per page that is “sliced”. Example:
  p {margin: 1.0em 0 1.0em 0} instead of .page1 p {margin: 1.0em 0 1.0em 0}
• Preferably, margins and font sizes should be in EMs (or REMs + px fallback)
• Containers/content areas, in general, should be built to accommodate longer content

General WordPress Theme Requirements

• Make sure theme is in its own directory, named, and set up correctly. Follow this official guide:
  http://codex.wordpress.org/Theme_Development
• CSS should have relative paths to images. Don’t use the testing link. For example: background: url(images/some-image.png) left top no-repeat;
• All paths to new images/css/js/etc in the templates should use bloginfo(‘template_url’) to start the URL, not a static URL.
• Please make different PSD designs as different templates. For example, here are the templates I would use for one of our typical builds where WordPress is the CMS and the blog is a sub-page:
  • page.php (Default sub page)
  • page-home.php (home page)
  • page-contact.php (contact page)
  • index.php (blog page, default)
  • single.php (individual blog post page, default)
• Include 404 page
• The site should be reflected as pages. The site structure will be at the top of the content document. Posts are only used for blog posts, if there is a blog.
• If there is a blog, include category and archive templates in the default way, with the same style as the blog
• Site-wide navigations (main nav, footer, etc) should be pulled in using the function wp_nav_menu. This means creating those menus in Appearance -> Menus and passing their name to the function.
• Sidebar navigations listing child pages, should dynamically generate the list of all child pages. So if a new page is added under the parent in WordPress, it will automatically show up.
• Make body text links root relative and make sure they are all clickable and linked up as necessary
• Avoid putting custom HTML/classes/IDs in the wordpress page content. If a client edits in Visual view, they should not be able to accidentally mess everything up and delete elements and styles. Put structurally different sections in the template itself, styled through the parent element. Shortcodes or a custom post type for editable areas may also be used.
• For photo areas used on sub-page, use the featured image in wordpress
• Blog index – typical behavior should be to show excerpt if it exists, otherwise display the full post.