Quick Tips—A series of quick web development tips from Harry Roberts of CSS Wizardry

I wrote the popular Web Design+ quite some time ago—it is a very extensive and quite long document that has been recognised throughout the industry. I decided however that there was a need for a more succinct guide to web development best practices on the web. Here it is… ‘Quick Tips’. Keep checking back as I will be constantly updating this resource.

CSS is not a programming language

There are several tools and frameworks out there at the moment which extend CSS to adopt a more programmatic syntax and function. It is in my opinion that these are only really of benefit to people who haven’t yet mastered writing CSS properly from the outset…

If you learn how to write your CSS sensibly, write more shared styling and utilise the cascade fully, you will see little if any need for things like SAAS et al.

Permalink | Tweet this tip
CSS alone is no good

“CSS is the steak to web standards’ steak dinner”

Harry Roberts

CSS is only of any use if it’s used in the right context. There’s no point nicely styling your table based layout with CSS—you need to go the whole distance.

Permalink | Tweet this tip
Don’t reinvent the wheel

There are set ways to do things when it comes to web development—as dynamic and fast-changing as the web is, there are tried and tested methods that just work.

The best example I’ve seen of this was a developer making a table using a <ul>. Why?! The <table> element was invented for just that reason. Although an experiment it was essentially pointless. I summed it up with this quote:

“It’s a pointless experiment though. It’d be like experimenting making a house out of tampons—doable but just plain wrong.”

Harry Roberts

Wisdump picked up on this and covered it in their article CSS Aid’s “Tables without Tables” misses the point…

No matter how amazing your idea may seem, there’s usually a reason that it’s not been done before.

Permalink | Tweet this tip
Bad code isn’t quicker

“Any developer who blames poor code on time constraints is talking out of their….”

Harry Roberts

If a developer is any good at what they do they will strive to turnaround the best code possible in a shorter time. Opting to code badly due to time constraints is the worst excuse ever.

You should be quicker at things you’re best at, no? So if bad code is quicker for you than proper code then there are some real problems. Tables are not quicker than proper markup and CSS*!

*unless of course you’re exporting HTML from Fireworks ;-)

Permalink | Tweet this tip
Stop images with negative margins getting ‘cropped’ in IE6

If you’ve ever had to pull an image out of a container using negative margins you will have no doubt found that IE6 clips the image at the edge of the parent container, regardless of its overflow state. The simplest and quickest way to combat this is to apply display:block; and position:relative; to the offending image.

Permalink | Tweet this tip
Hang punctuation

A tiny but significant typographical feature you should ideally add to your site is hung punctuation. This basically outdents things like quote marks, bringing them out of the vertical alignment of a body of text and neatening up the edges of the copy. Below is unhung (incorrect) punctuation:

“Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. Nulla consequat massa quis enim.”

An author’s name here

As you can see this creates an odd effect in the whitespace between the bottom of the opening quote mark and the top of the second line. A much nicer approach would be to hang the opening quote mark, thus:

“Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. Nulla consequat massa quis enim.”

An author’s name here

The CSS for this is simply blockquote p{ text-indent:-0.5em; }. Assuming you always use double opening quotes (&ldquo;) then -0.5em; will generally pull the quote out just the right amount.

Permalink | Tweet this tip
Make use of config files

Config files are more commonly used on larger sites, but they have huge benefits on smaller builds too. Take the following config.ini file for example (→ denotes line wrap):

;Define general site data
domain = "/index.html"
name =	CSS Wizardry
keywords = web standards, semantics, →
  accessibility, typography, web developer, →
  CSS, xHTML, HTML5, Harry Roberts →
  description = Semantic web →
  development, web standards, CSS Wizardry and →
  other stuff.
phone = "0800 000 000"

;Defnine critical paths
stylesheets = css/
images = images/
javascript = js/

This contains information about the website, information that gets shared across all pages but only really needs writing once. Now you have your data set up you need to interpret this file, thus config.php (→ denotes line wrap):

$iniConfig = parse_ini_file('/includes/ →
  config.ini', true);

define('ROOT', $iniConfig['SiteData']['domain']);
define('SITE_NAME', $iniConfig['SiteData'] →
define('KEYWORDS', $iniConfig['SiteData'] →
define('DESCRIPTION', $iniConfig['SiteData'] →
define('PHONE', $iniConfig['SiteData'] →

define('STYLESHEETS', ROOT.$iniConfig['Paths'] →
define('IMAGES', ROOT.$iniConfig['Paths'] →
define('JAVASCRIPT', ROOT.$iniConfig['Paths'] →

Now for each line beginning define you’re assigning a value to the uppercase word immediately after. Therefore define('ROOT', $iniConfig['SiteData']['domain']); gives ROOT the value assigned to domain that you set up in config.ini.

In each page that you want to use this set of data simply place <?php include("/includes/config.php"); ?> before the !DOCTYPE. To write out any of the data you simply need something like This site is called <?php echo ROOT; ?> and our number is <?php echo PHONE; ?> which would give ‘This site is called CSS Wizardry and our number is 0800 000 000’.

This might seem like a lot of effort to begin with but imagine you have a site with 20 pages and the client changes their phone number. Before the config files method that’s a lot of finding/replacing. With the config files you simply need to change it once in the config.ini file and the whole site gets updated with the new number automatically.

Place both the config.ini and config.php files in your includes directory.

Permalink | Tweet this tip
Create your own framework

One of the most important things you can do to make your life easier as a web developer is set up a small framework of your own upon which you build new sites. This could be as simple as a file structuring system, to a full MVC framework. One of the most basic may look like the following:

  • about/
    • index.php
  • css/
    • style.css
  • img/
    • css/
      • bg.gif
      • header.jpg
      • alert.gif
    • products/
      • product-01/
        • thumb.jpg
        • 01.jpg
        • 02.jpg
      • product-02/
        • thumb.jpg
        • 01.jpg
        • 02.jpg
    • logo.gif
  • includes/
    • config.ini
    • config.php
    • footer.php
    • header.php
    • nav.php
  • products/
    • product-01/
      • index.php
    • product-02/
      • index.php

If you start off every project like that then you instantly know what belongs where, making your life much simpler.

Furthermore—if you’re constantly flitting between client projects—a framework will make everything consistent across sites, making changes both quicker and easier.

Permalink | Tweet this tip
Beware z-index

“z-index is a twat”


Permalink | Tweet this tip
Keep stylesheets out of cache when developing/presenting websites

I once showed a client a dev site and they yelled told me that I wasn’t doing as they asked as they could see text changes but the old design. I soon realised that they just had their stylesheet cached, but it was a bad situation that arose from a simple misunderstanding.

A quick and failsafe solution to this is to keep the stylesheet out of cache by adding ?<?php echo time(); ?> to the end of the stylesheet’s <link /> element, thus: <link rel="stylesheet" type="text/css" href="css/style.css?<?php echo time(); ?>" /> which will resolve to something that looks like: <link rel="stylesheet" type="text/css" href="css/style.css?1348726534" />

This means the browser will load the stylesheet each time the page is refreshed, keeping it out of cache (as it’s essentially a different file to style.css). Remember to remove the PHP once the site goes live though.

Permalink | Tweet this tip
Always code so that you could do a full redesign touching only the CSS

By adhering to this you are doing a number of things. You are really really separating style from content—which is the cornerstone of CSS and web standards, you are most likely using some great semantics and writing some really sensible markup and you’re also saving money. If a client asks for a redesign of a site you’ve already built them, CSS changes are some of the cheapest changes to make.

Permalink | Tweet this tip
Use (PHP) includes

One of the most basic yet useful things to use when building any website are PHP includes. Any shared content is written once and placed in isolation in a file (usually with a .php extension) and then referenced where it is needed in other pages. Something like a navigational menu might look something like this: <?php include("/includes/nav.php"); ?> and might include a <ul>.

Permalink | Tweet this tip
Combine media types into one .css file

You can specify your screen and print (and more) styles all from the same stylesheet. All you need to do is include some separate @media rules.

For style information common across all media types, write it as you would normally. For print specific styles simply wrap any CSS in an @media print delaration, thus: @media print { body{ style-info:here; } } and so on for other media types.

You must remember however to make sure your <link /> in your HTML’s <head> allows your in-CSS media types to be effective by not sepcifying a media="" attribute, thus: <link rel="stylesheet" href="/css/style.css" type="text/css" />

Permalink | Tweet this tip
Clear floats the clean way

Using empty ‘clearing’ elements to clear floats is pretty ugly and insemantic— the best and cleanest way to clear elements that contain floats is the overflow:hidden; method: http://prdesign-studio.co.uk/floats/

Permalink | Tweet this tip
Pay attention to your typography

Even subtle type work goes along way. Take time to learn about web typography and apply it in your designs. After all, web design is 95% typography

Permalink | Tweet this tip
Use as little code as possible but as much code as necessary

Always try and reduce your code. There is nearly always a more lean approach to something. This includes things like not wrapping <ul>s in <div>s—a <ul> is a wrapping element in itself and therefore doesn’t usually require a <div> around it to place/style it.

Permalink | Tweet this tip
Don’t omit fragment identifiers

If you use a JavaScript smooth-scroll script to ‘slide’ between sections of a page, make sure the script doesn’t knock the fragment identifier off of the end of the URL. If you have a seperate about page you can link to it via http://site.com/about/ for example. If you have http://site.com/#about make sure you can actually get that URL from the address bar.

A good example of this: http://prdesign-studio.co.uk/web-design+/ (admittedly sans-smooth-scroll), and a poor example http://atomiccartoons.com/ (although it is a nice site).

Permalink | Tweet this tip
Use proper glyphs

There are countless intances where improper glyphs are used on the web. This is largely due to the fact that keyboards don’t have room for each and every glyph so a more generic catch-all is used. One example is the hyphen (-) which covers all manner of dashes (em: —; en: –). For a list of common/commonly misused glyphs see http://prdesign-studio.co.uk/toybox/punctuation-glyphs/

Permalink | Tweet this tip
Don’t type in capitals

All caps is classed as styling, rather than content. BBC is always capitals, so that should be typed in caps. THIS IS A SENTENCE is only in caps for stylistic purposes so CSS should be used to style that. Also, when copying and pasting something that is in caps it’s a bit annoying if it’s not actually meant to be in all uppercase as standard.

Basically, only type in caps if it has to be at all times (ie BBC, SCUBA, RADAR, ITV, RSPCA etc), and if it’s for stylistic/aesthetic/arbitrary purposes, use CSS to transform it: selector{ text-transform:uppercase; }.

Permalink | Tweet this tip
Remember this quote

“People are stupid and people are lazy.”

Mrs Bolland—my old English teacher

My English teacher used this phrase in passing when I was 12—we were making questionnaires in class and she was explaining how to make them easy to use. This phrase has stuck with me since that day and has helped me no end when considering website usability.

Permalink | Tweet this tip
Create an iPhone stylesheet

If you think your site may be visited by iPhone users, take a few minutes to create an iPhone stylesheet. They couldn’t be simpler and require very little new code to make them work.

This site uses a very simple yet hugely effective iPhone stylesheet (see the bottom) along with this code in the document <head>: <meta name="viewport" content="width=device-width, minimum-scale=1.0, maximum-scale=1.0" /> which ‘disables’ Mobile Safari’s pinch-zoom function.

Permalink | Tweet this tip
Ignore people who tell you how to structure your CSS files

Unless you really never have written any CSS before then ignore people/articles that tell you exactly how to lay out your CSS files down to the last indent. If it works for you and is easily understandable then carry on as you are. I’ve read resources that tell you you must write single line CSS as it’s easier to understand. Why should you change your preferences to suit theirs? This site doesn’t use single line CSS but I’m sure you’ll agree it’s all very tidy. Do what you feel most comfortable with.

Permalink | Tweet this tip
Use a Strict !DOCTYPE

For production code you should always use a Strict !DOCTYPE. This enforces better practices, and also forces browsers into standards mode. While the markup rules may initially be harder to adhere to, the benefits are soon noticed later on.

The Strict !DOCTYPE: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Permalink | Tweet this tip
Add CSS3/progressive enhancement last

Due to CSS3 and progressive enhancement’s inherent ‘bells-and-whistles’ nature it is imperative that your site can function without these. The best way to ensure this is to add these features last, after you’ve finished creating a site that works in all non-supportive browsers.

Permalink | Tweet this tip
You don’t always need a title attribute

If your link text is descriptive enough then there is no need to give it a title attribute. An example where a title attribute is not needed: Read more <a href="/about/" title="About Harry Roberts">about Harry Roberts</a> as a screen reader will read out ‘about Harry Roberts … about Harry Roberts’. As you see this makes the title attribute pretty redundant here and will probably get somewhat annoying for screen reader users.

A good time to use it would be: This document was created by <a href="http://prdesign-studio.co.uk/" title="CSS Wizardry&mdash;Personal website of Harry Roberts">Harry Roberts</a>.

Permalink | Tweet this tip
Ensure your website works with images disabled

Creating a site that relies too heavily on images is never a good idea. Although almost a thing of the past, there are still users who run at very low internet speeds. Also, if a user needs to—for whatever reason—disable images, can they still access all the content they need to?

Permalink | Tweet this tip
Avoid applying absolute width and height values

Whilst definite widths and heights do sometimes have their place it is always best to avoid these wherever possible. There are several reasonings behind this… What if a user needs to zoom their text-size? The text will most likely break out of the confines of its container and may cause some less than ideal legibility issues.

Another good example is what if the client decides they want to add a bit more copy to a certain area of the site? If that area has a fixed height you might be left with a bit of a headache recoding the area to accommodate additional text/elements. Invest the time in the first place to make a flexible layout and reap the benefits later.

Permalink | Tweet this tip

Created by @csswizardry, owner of CSS Wizardry, author of Web Design+. Tweet this resource.

Got an iPhone? We have a stylesheet just for you—why not visit on your mobile? Web standards on the move!

Why so skinny? Just optimal line length innit. The ideal line length for any body of text on the web is between 52–78 characters. This sits at a cosy 68.