Have you ever wanted to say something like ‘There are three things to look out for:’ and then follow with a numbered list with the three things in?

I’m pretty sure we all have, and that we’d all normally use an <ol> to get the numbers, right? That’s how you get numbers next to list items after all…

Well the problem here is that the numbering defines an amount, not an order. The order is usually irrelevant in this scenario.

To make more sense I’ve drawn up a small fiddle of examples and the reasoning in each.

Here we can see that, although we want numbers, we don’t always want order.

The trick I’ve started employing is is to have a .numbered class which I can apply to a <ul> to make it mimic the appearance of an ordered list, without semantically carrying the ordered weight. This is how I do it:

ul,
ol{
  margin-bottom:1.5em;
}
li ul,
li ol{
  margin-bottom:0;
}
ul{
  list-style:square outside;
}
ol,
.numbered{
  list-style:decimal outside;
}

There. As simple as that. These are pretty much my default list styles now, and all I’m really doing is making an unordered list with a class of numbered look the same as an <ol>.

The techniques I’m going to cover can be found on my recently launched hub site hry.rbrts.me, but for the sake of clarity I have isolated them in a jsFiddle here.

So, if we know a logo needs to be an <img /> that’s easy enough, but what if we want hover styles on this image? Simple.

We’ll be wrapping the logo in an <a> so as to link back to the homepage, a common and good practice:

<a href="/" id="logo">
  <img src="/img/logo.png" alt="Company logo">
</a>

What we can do here is utilise this <a> and apply a sprited background image to it to provide our on/off hover states, thus:

#logo{
  display:block;
  width:100px; /* Width of logo */
  height:100px; /* Height of logo */
  background:url(/img/css/sprite.png);
}

So now we have a background on the <a> surrounding our <img /> that we now need to git rid of.

We could do this by using a simple display:none; or more accessibly using:

#logo img{
  position:absolute;
  left:-9999px;
}

Now we can no longer see the <img /> but we can see the background on the <a> behind it.

Now all we need is to move the sprite on :hover, thus:

#logo:hover{
  background-position:0 -100px;
}

So here we have a semantically sound logo, using (as we should be) an <img /> with the added benefit of being able to use sprites to give the logo hover effects.

There’s more…

There’s another little thing I’ve started doing which I really like. We have an image in the page semantically, but not functionally. Right clicking the logo won’t yield a view image context menu, instead it’ll just focus on the <a>.

What I like to do, which is a nice little touch, is to unhide the <img /> (i.e. get rid of the absolute positioning above) and instead just hide it with opacity:0; (or filter:alpha(opacity = 0); for IE). This means that the user can still right click the logo and be interacting with an image, but they still get your nice sprites on hover.

So we have an <a> with a background sprite which contains an invisible image that a user can still interact with; see it in situ or look at an isolated case. Try hovering and right clicking…

At first I thought this was awesome because, well, how cool is that?! But then I realised that neither of these are any use in CSS:

#foo:bar{ /* Looks for an element with an ID of foo and a pseudo-selector(class/element) of bar */ }
#foo.bar{ /* Looks for an element with an ID of foo and a class of bar */ }

So, whilst these are perfectly valid in HTML, they’re useless in CSS they can be styled with CSS. Kinda sucks, huh? But! If we know they’re okay in HTML and totally pointless in CSS, can we use that to our advantage?

Answer: yes!

Fragment identifiers

This is just the fancy name for when you link to an element with an ID on it, e.g. <a href="#content">Skip to content</a>.

I regularly use fragment identifiers when writing long articles with certain sections in them. The best and most relevant example I have is my epic on web type on Smashing Magazine.

Here I have a list of links to sections in the article, but you should notice I prefix each ID (and therefore its corresponding link’s href) with #tt-. This is so that I know that my sections will (almost definitely) not be picked up by Smashing’s CSS. If I had a section called #face and, for whatever crazy reason, Vitaly had a huge photo of himself with an ID of #face there would have been conflicts.

This was a situation where I needed IDs for no styling whatsoever, but rather to be used as fragment identifiers. And, to circumvent any of these potential hiccups, I namespaced all my fragment identifiers with #tt-, standing for technical type.

Here enters my little discovery…

If we want an ID that won’t be styled with CSS because we only want to link to it then we can use a colon or a period in there to:

1. Ensure that CSS cannot touch the element even if it wanted to.
2. Namespace the fragment identifier to show that it is meant as a link hook and give it some more human-friendly semantics.

Demo

I’ve made a demo page of this to a) prove that it works and b) show you how it works in situ.

Run it through the validator, see, it works!

I’ve also tested it in IE7+, Chrome and Firefox Mac and Win.

Problems?

Not that I can think of right away, but bear in mind that these elements cannot be styled via that ID.

For the most part the elements will be styled on an element-level basis (e.g. table{}, pre{} and so on) so styling them explicitly should not be too important.

If you do find you need to style them individually you could:

• Use a class.
• Revert to the tried and tested non-colon-or-period syntax.

A standard

I’ve never ever seen this anywhere before but I am already thinking it will be incredibly useful to me and any others who write documentation, articles or anything else with sections.

I propose a (loose) standard whereby you namespace your fragment identifiers with relevant information, so if you’re linking to a table in a document give the table an ID of #table:sales-figures, a figure showing a technical drawing an ID of #figure:engine-section, a section of an article an ID of #section:intro and so on.

I have created a GitHub repo with an initial list of potential namespacing values there could be. I encourage and appreciate your contributions!

Any thoughts and feedback on this would be great!

Addendum

Ben ‘Cowboy‘ Alman points out that escaping the colon will allow you to style the ID via CSS, as will escaping the period:

#foo\:bar{ /* Works! */ }
#foo\.bar{ /* Works! */ }

Basically, we all know HTML5 has given us some pretty awesome new elements to toy with and some of the more humble ones are <figure> and <figcaption>:

<figure>
  <img src="/img.jpg" alt="" />
  <figcaption>Caption for above image</figcaption>
</figure>

In this post I’ll show you how to turn that into an image-map style annotated image using really really semantic markup.

Demo

You’re probably familiar with Flickr’s notes which are shown upon hovering an image. Well functionally this is exactly like that (I’ve never actually looked at their markup but I imagine it’s nigh on identical). Where this differs is that it uses some super-rich and semantic markup and it can be used as a CSS plugin! Simply paste the CSS into your site’s stylesheet and start using HTML5 <figure> annotations.

The code

This technique is a really good example of layers of code. Perfect HTML that works absolutely great on its own, totally semantic and well structured. It doesn’t need the CSS at all to function, the CSS just enhances it.

The HTML

The HTML is lovely and simple. Before we go any further go back to the demo page and disable styles. Seeing this without styles should show you just how semantic and sensible the markup really is. It’s a perfect HTML layer that doesn’t even need CSS to make sense or work.

I’ve not included the whole page as all we really want to look at is this:

<figure class="annotated">

  <img src="img/photo.jpg" alt="Photograph of me on my bike" />

  <figcaption>

    <b>Things to note:</b>

    <ul>
      <!-- Positions of the list-items. These need defining inline. -->
      <li style="top:255px; left:150px;">Helmet.</li>
      <li style="top:420px; left:140px;">Ruptured ligaments in my ankle.</li>
      <li style="top:480px; left:130px;">Low pressures.</li>
      <li style="top:390px; left:325px;">The trailer I just jumped from.</li>
    </ul>

    <i><a href="http://www.flickr.com/photos/suzannahaworth/4707464578/">Photo</a> by <a href="http://twitter.com/suzehaworth">@suzehaworth</a>.</i>

  </figcaption>

</figure>

All we have here is a <figure> and <figcaption> with an image, a title and a list. The image is the subject of our figure and the list makes points about it. To associate these points with the image we simply have a <b> which we use to textually make the connection.

The CSS

/*------------------------------------*\
  ANNOTATIONS
\*------------------------------------*/
/*
Apply a class of annotated to any figure you would like, well, annotated!
*/
.annotated{
  position:relative;
  /*display:inline-block; If you do not need to support IE7 and below uncomment this line and remove the inline width and height styles on the <figure> in your markup. */
}
.annotated img{ /* Set this to stop white-space appearing under the image. */
  display:block;
}
.annotated b{ /* Hide the figcaption's title. */
  position:absolute;
  left:-99999px;
}
.annotated ul{ /* Set up the canvas for the annotations to sit on. */
  list-style:none;
  position:absolute;
  top:0;
  right:0;
  bottom:0;
  left:0;
}
.annotated li{
  display:block;
  padding:0 5px;
  /* Give them a width and a line-height suitable for your kind of images. I chose 50px. */
  width:40px; /* 40px + 5px padding-right  + 5px padding-left = 50px */
  line-height:50px;
  position:absolute;
  text-indent:-99999px; /* Hide the text off-screen. */
  white-space:nowrap; /* Stop the annotations breaking onto several lines. */
  cursor:default;
}
.annotated:hover li{ /* When we hover the figure show us where the annotations are. */
  border:1px solid #fff;
}
.annotated li:hover { /* Show the text on hover. */
  background:#fff;
  background:rgba(255,255,255,0.75);
  z-index:2; /* Bring current annotation above others. */
  /* Remove the width and text-indent to show us our text! */
  width:auto;
  text-indent:0;

  /* A bit o' progressive enhancement */
  -moz-box-shadow:0 0 5px rgba(0,0,0,0.25);
  -webkit-box-shadow:0 0 5px rgba(0,0,0,0.25);
  box-shadow:0 0 5px rgba(0,0,0,0.25);
}

The CSS is fairly well commented but basically what we do is:

• Hide the <b> title.
• Absolutely position and stretch the <ul> over the image.
• Give the <li>s a width and (line-)height and hide the text off-screen.
• Add borders to the list items when we hover the <figure>.
• Remove the width from and give a border to the <li>s on hover, and reveal the text.

A couple of things to note

Firstly, the list items need positioning with inline styles in the markup. This is far more pragmatic than giving each <li> an ID and doing each one through an external CSS file.

Secondly, and more in depth, how do we get the the <figure> to wrap around and hug the image? We have four options.

• Leave it as-is, like I have here. This means that if you hover to the right of the image you are technically still inside the (block-level) <figure> and this will display the list item borders when your cursor isn’t actually over the image. This isn’t too bad, but a little unexpected…
• Float the <figure> left, which will force it to hug up to its largest child. The problem here is that you would have to clear:both; the subsequent element.
• Give the <figure> display:inline-block;, but this won’t work in IE7 and below.
• The final and, in my opinion, most pragmatic solution would be to simply add an inline width and height to the <figure> which is identical to the dimensions of your image, thus: <figure style="width:427px;height:640px;">.

Decide which of those will suit your project best and put it to work. Simply pasting the CSS into your stylesheet and obeying the markup structure will allow you to annotate your figures in a much nicer fashion.

I have just put this on GitHub in a CSS plugin type fashion. Please feel free to download and poke through the code.

After Séan shared the Financial Times’ timeline I got to wondering how I’d code my own (albeit massively more simple) timeline.

This is what I came up with: HTML/CSS timeline.

The markup

The markup is amazingly simple. Semantically I used an <ol>. This was quite an obvious choice as this is an ordered list of events. I used one id="" and some supporting datetime attributes where known (some exact dates are unknown, therefore not included (hopefully you’ll know your exact dates!)), and then that’s it:

<ol id="timeline">

  <li>
    <time datetime="1990-07-04">July 1990</time>
    <p>Born</p>
  </li>

  <li>
    <time>September 1994</time>
    <p>Started first school</p>
  </li>

  <li>
    <time>September 1999</time>
    <p>Started middle school</p>
  </li>

  <li>
    <time>September 2003</time>
    <p>Started high school</p>
  </li>

  <li>
    <time>September 2006</time>
    <p>Started 6th Form</p>
  </li>

  <li>
    <time datetime="2007-11-19">November 2007</time>
    <p>Registered csswizardry.com</p>
  </li>

  <li>
    <time datetime="2008-07-14">July 2008</time>
    <p>Joined Sense Internet as Web Developer</p>
  </li>

  <li>
    <time datetime="2009-03-16">March 2009</time>
    <p>Joined Twitter</p>
  </li>

  <li>
    <time datetime="2010-01-11">January 2010</time>
    <p>Joined Venturelab as Web Developer</p>
  </li>

  <li>
    <time>January 2011</time>
    <p>Became a member of the Smashing Magazine Experts Panel</p>
  </li>

  <li>
    <time datetime="2011-03-21">March 2011</time>
    <p>Joined Sky as Senior UI Developer</p>
  </li>

</ol>

I was initially marking the dates up as <b>s but as Mark pointed out I could use the new HTML5 <time> element.

The CSS

As far as basic styling goes, I won’t insult your intelligence; I merely set some type styles and background colours on the list items.

The really interesting bits are the odd/even styling, the ’spine’, the dot and arrow ‘images’ and the branches off the centre of the timeline. I put images in quotes because they’re not actually images at all, they’re :before and :after pseudo-elements.

The spine

The spine running down the timeline is actually an image and is applied as a background using the fantastic Dummy Image:

#timeline{
  background:url(http://dummyimage.com/1x1/f43059/f43059.gif) top center repeat-y;
  width:820px;
  padding:50px 0;
  margin:0 auto 50px auto;
  overflow:hidden;
  list-style:none;
  position:relative;
}

The arrow and dot

The arrow and dot, as mentioned above, are actually pseudo-elements. Their CSS is:

#timeline:before, /* The dot */
#timeline:after{ /* The arrow */
  content:" ";
  width:10px;
  height:10px;
  display:block;
  background:#f43059;
  position:absolute;
  top:0;
  left:50%;
  margin-left:-5px;

  -moz-border-radius:20px;
  -webkit-border-radius:20px;
  border-radius:20px;
}
#timeline:after{
  margin-left:-7px;
  background:none;
  border:7px solid #f43059;
  border-color:#f43059 transparent transparent transparent;
  width:0;
  height:0;
  top:auto;
  bottom:-7px;

  -moz-border-radius:0;
  -webkit-border-radius:0;
  border-radius:0;
}

Here we’ve created two empty pseudo-elements that are shaped like an arrow and a dot and then absolutely position them at the top and bottom of the ordered list. They sit over the top of the spine, giving the illusion of all being connected.

It’s worth saying that I’m not actually a fan of the border-arrow behaviour, but this is an experimental piece.

The branches

The branches that span between the list items and the spine are, again, pseudo elements. They are 70px wide and 1px high and have a gradient background which transitions from the colour of the spine to the colour of the list items. The CSS powering those is:

#timeline li:before,
#timeline li:after{
  content:" ";
  width:70px;
  height:1px;
  background:#f43059;
  position:absolute;
  left:100%;
  top:50%;
  background:-moz-linear-gradient(0,#d8d566,#f43059);
  background:-webkit-gradient(linear,left top,right top,from(#d8d566),to(#f43059));
}

So by now we’ve added start and end points, a spine and branches to our timeline with no extra markup whatsoever. Lean!

Odd/even styling

The odd/even styling of each list item is achieved, as you might expect, using nth-of-type() selectors. What we do is move every even list item over the right of the <ol> and move its branch to attach to the spine accordingly:

#timeline li:nth-of-type(even){
  float:right;
  text-align:left;
}
#timeline li:nth-of-type(even):after{ /* Move branches */
  background:-moz-linear-gradient(0,#f43059,#d8d566);
  background:-webkit-gradient(linear,left top,right top,from(#f43059),to(#d8d566));
  left:auto;
  right:100%;
}

CSS feature detection?

This next bit I found quite cool, though a little unorthodox. I set the <li>s to have a negative margin-top so that they had a slightly overlapped effect on the timeline, so either side is not below the previous one, rather next to and slightly along-side it.

The problem I had here is that, in browsers that don’t support nth-of-type() selectors, the list items bunched up, each one slightly covering the previous one.

What I did was use this:

#timeline li:nth-of-type(odd),
#timeline li:nth-of-type(even){
  margin:-10px 0 0 0;
}

Which basically says if the browser supports nth-of-type() selectors then give the list items a negative margin-top.

Any browsers that don’t support nth-of-type() selectors get the previously defined margin value for the list items, set here:

#timeline li{
  position:relative;
  clear:both;
  float:left;
  width:318px;
  padding:10px;
  background:#fef8c4;
  border:1px solid #d8d566;
  text-align:right;
  margin:0 0 10px 0;

  -moz-border-radius:2px;
  -webkit-border-radius:2px;
  border-radius:2px;
  -moz-box-shadow:0 1px #fff inset;
  -webkit-box-shadow:0 1px #fff inset;
  box-shadow:0 1px #fff inset;
}

I guess you could call that a small kind of feature detection…?

However, whatever you call it, it means that IE8 users still get a pretty good experience, a linear, one column timeline with no nth-of-type() styling:

IE7 however doesn’t support pseudo-elements or nth-of-type() selectors, so they just get a single column list with no branches or dots/arrows but they do get a lonely spine…

Final word

So there we have it, a super lean, semantic and progressively styled timeline in HTML and CSS and one image. No doubt you could make a completely imageless solution, but I’m personally not one for this ‘never use images’ phase that the industry seems to be going through…

The best way to explain them is probably to take a look at the following excerpt:

Hi there, I’m Harry Roberts, I am a web developer at BSkyB. I specialise in web standards, accessibility, Ruby, design and build, mobile development, typography and more. I have been in the industry for three four years.

Please note: I am not a programmer.

Above: A photo of me.

I write at my personal blog CSS Wizardry and tweet at @csswizardry. I love the uppercase R in Helvetica. My motto on web development is ‘Always code like you’re working in a team, even when you’re not.’ I absolutely love the web.

I am also an advocate of clearing floats the clean way. Please note the width and overflow properties in the code below:

.wrapper{
  width:940px;
  margin:0 auto;
  padding:10px;
  overflow:hidden;
}

This is, admittedly, a very forced bit of writing, but I had to write in such a way as to properly, and in context, use a large set of semantic text-level elements. These are, in order of appearance:

1. The <del> element
2. The <s> element
3. The <ins> element
4. The <strong> element
5. The <small> element
6. The <b> element
7. The <cite> element
8. The <i> element
9. The <q> element
10. The <em> element
11. The <code> element
12. The <mark> element

The <del> element

...I specialise in web standards, accessibility, <del datetime="2011-01-23T10:07:25+00:00">Ruby,</del> design and build, mobile development, typography

The <del> element indicates a removal from a document; this shows that the text inside it has no place in the document. You could actually physically remove the text, but you can—for the sake of transparency— leave it in and show that it does not belong. It also has an attribute to show when it was deleted.

In this case, I do not know Ruby and as such it has no place in the text. I used the <del> element to show this.

The <s> element

I have been in the industry for <s>three</s> four years.

This element is very similar to the <del> element and their differences are very subtle. Where the <del> shows incorrect information that should not be in the document, the <s> element represents information that is no longer accurate or relevant (e.g. out of date). Here, it used to be true that I had been industry for three years, but that has been replaced by four. The information is not incorrect per se, merely no longer relevant.

The <ins> element

<ins datetime="2011-01-23T10:07:25+00:00"><strong>Please note:</strong> I am not a programmer.</ins>

The <ins> element represents text that has been inserted into the document after it has been published. Here I am inserting content as a result of the Ruby mistake earlier. Here I am inserting text to explain why the previous text was removed. Note the same attributes as used on the <del> element.

This isn’t its only use, however. I frequently use the <ins> element in articles to show addenda and updates.

The <strong> element

<ins datetime="2011-01-23T10:07:25+00:00"><strong>Please note:</strong> I am not a programmer.</ins>

We should all be familiar with the <strong> element. It represents strong importance; where the content is more important than its surroundings. Here is is important because I am saying it is important that you know that I am not a programmer as was accidentally stated above.

The <small> element

<small><b>Above:</b> A photo of me.</small>

The <small> element has been redefined to represent small print and side comments. Here it is used to describe the picture above it. It’s usage is, luckily, fairly obvious. Any time you have supporting information for a larger piece, mark it up as a <small>.

The <b> element

<small><b>Above:</b> A photo of me.</small>

The once loathed <b> element has been redefined in HTML5 to represent any text whose appearance is offset from its surroundings, often by means of bolding. There are occasions when you’d want bold text but without any extra importance, such as <strong> would add. I also use the <b> element for marking up the origins of quotes, e.g.:

<blockquote>
  <p>&ldquo;
    A lie gets halfway around the world before the truth has a chance to get its pants on.&rdquo;
    <b>Sir Winston Churchill</b>
  </p>
</blockquote>

The <cite> element

I write at my personal blog <a href="/"><cite>CSS Wizardry</cite></a> and

The <cite> element is used to represent a mention of or reference to a body of work, such as a book, an article, a painting and more. It is not, according to the HTML spec, used for marking up the names of sources of quotes (as above, I use the <b> element).

So whenever you reference a name of a film or song or website or sculpture or article, mark it up with the <cite> element.

The <i> element

I love the uppercase <i>R</i> in Helvetica.

The newly redefined <i> element is another slightly confusing one. The usage is any piece of text that may be spoken with a slightly different inflection but bears no extra importance. The best way to tell whether you need the <i> element or not is to say it aloud.

Here I’m marking up a single letter, because if I were to speak that sentence aloud the R would have a slightly different tone applied. The <i> element can also be applied to full words and phrases.

The <q> element

My motto on web development is <q>&lsquo;Always code like you&rsquo;re working in a team, even when you&rsquo;re not.&rsquo;</q>

The <q> element is simply used to mark up inline quotations; quotes that are in the context of surrounding copy.

The <em> element

I absolutely <em>love</em> the web.

Again, the <em> element is one we should all be familiar with. It denotes stressed importance. If you read the example aloud you can see how the <em> element adds inflection on the word love with importance.

The <code> element

Please note the <code>width</code> and <code>overflow</code> properties in the code below:

The <code> element is very self-explanatory, it simply represents pieces of code.

N.B. There is a much larger array of elements used to denote code, inputs and outputs too detailed to go into here. Please refer to the HTML spec for these.

The <mark> element

<pre><code>.wrapper{
  <mark>width:940px;</mark>
  margin:0 auto;
  padding:10px;
  <mark>overflow:hidden;</mark>
}</code></pre>

The <mark> element is a really nice new element introduced in HTML5. Its purpose is simply to highlight. You could highlight each occurrence of a search term in a search-results page as HTML5 Doctor do or—as I like to do—highlight specific references to code that is in a larger block. This allows me to give the code context, but also highlight the relevant snippet that I am talking about.

So there we have an array of highly semantic and really nifty text-level elements to use in your work; some old, some new, some modified but all useful.

There are more than I’ve outlined here, I may revisit the blog post and add them, but the ones I’ve covered are the ones I find most commonly occurring. In the meantime, why not give the HTML spec a quick read?

And in doing so we will cover:

• Design and build a semantic, accessible and sensible progress bar.
• Utilise the much underused method of styling page-specific elements based on their IDs.
• Style the numbers in an ordered list!
• Progressively enhance it with some CSS3.
• Optimise it for mobile.

N.B. This article isn’t so much about a progress bar, but more an illustration that best practices and more advanced techniques can be applied to even the most insignificant aspects of a build to create something awesome!

Design and build

Let us assume the brief is this:

We require a numbered progress bar to indicate user location (past, current and future) during a checkout path on the OurService™ website. It must:

• Be fully accessible.
• Provide a section title with supporting information.
• Highlight the user’s current location in the process.
• Be navigable.
• Work on mobile devices.

The design, let’s assume, is predefined. It looks as above, purely because it has to. The design is not the major focus of this article, the code and techniques are.

“Code what you consume, not what you see.”

Design

The progress bar shall be a linear, left to right series of linked labels. Current location shall be indicated by a change in colour, progression onto the next step shall be indicated by an arrow.

Build

For the purposes of this tutorial we shall assume the current page is the payment page.

One school of though I find invaluable when it comes to sensible and semantic builds is code what you consume, not what you see. This is a very broad generalisation but works for the most part. Code content independently of (and before you consider) coding any styles. Web development basics, but fundamental to web standards and progressive enhancement.

So, what are we consuming? It’s an ordered list of steps which indicate location in a process.

Okay so first off we know we need an <ol> as this list has fixed and definite order. We also require titles and supporting copy for each item. As the titles and supporting copy require separation from one another we are going to wrap the titles in a <span>; a generic inline container. This leaves us with:

<body id="payment-page">

  <ol id="progress">

    <li class="details-step">
      <a href="#">
        <span>Your details</span>
        Name, email, address.
      </a>
    </li>

    <li class="account-step">
      <a href="#">
        <span>Create account</span>
        Username and custom URL.
      </a>
    </li>

    <li class="products-step">
      <a href="#">
        <span>Product options</span>
        Choose your package.
      </a>
    </li>

    <li class="payment-step">
      <a href="#">
        <strong>
          <span>Payment</span>
          PayPal, or credit card.
        </strong>
      </a>
    </li>

    <li class="go-step">
      <a href="#">
        <span>Go!</span>
        Start using OurService™
      </a>
    </li>

  </ol>

</body>

There are a few things in this code which I’ve not yet mentioned, one is the ID on the <body>, another being the class on each <li> and the last being the <strong> wrapped around the payment page’s text. I shall explain these next.

<body> ID and list item classes

A combination of an ID on the <body> and a class on a list item can allow you to know what the current page is. The CSS #payment-page .payment-step{} will target the payment section of the progress bar when it is on the payment page in the process. Similarly, #go-page .go-step{} will target the go item on the go page. I wrote a much more in-depth article on this over at Venturelab.

The <strong> around the payment step’s text

If you’re determining current page programatically, one could argue inserting a class="current" on the relevant item. This is doable, but avoiding such a class name is far nicer.

As stated earlier we are assuming the current page to be the payment page. Now, we can style the current step on any page using CSS, as outlined above, however how would a user with styles disabled be able to tell what the current page is? How can we highlight this for those users?

Well the solution would be to programatically wrap a <strong> around the text on that page, undo the bolding effects with CSS for browsers with styles enabled, and allow people viewing unstyled content to see that the bolded item is the current page. This gives us:

As you can see, users with styles disabled can clearly see the current link is the bolded one, this makes the progress bar that little bit more accessible to those who might need it.

So there we have it, the markup that powers the whole thing.

Styling

Now to style this thing up. First off we’ll look at the very basic CSS, and that alone:

/*------------------------------------*\
  MAIN
\*------------------------------------*/
html{
  height:101%;
}
body{
  font-family:Calibri, Arial, Verdana, sans-serif;
  background:#fff;
  color:#88979e;
  width:940px;
  padding:10px;
  margin:0 auto;
}

/*------------------------------------*\
  PROGRESS
\*------------------------------------*/
#progress{
  list-style:none; /* Remove the bullets */
  float:left; /* Make its width equal to the combined width of the items inside it */
  margin-bottom:20px;
}
#progress li{
  float:left; /* Stack them all up left */
  font-size:0.75em; /* Make the entire item smaller */
  font-style:italic; /* Make the entire item italic */
}
#progress a{
  display:block;
  text-decoration:none;
  padding:10px 25px 10px 10px; /* Padding to accomodate background image */
  background:#7b8d77;
  color:#fff;
}
#progress span{
  font-size:1.333em; /* Bring the size of the title only back up */
  font-weight:bold;
  display:block;
  font-style:normal; /* Undo the italics */
}
#progress strong{
  font-weight:normal; /* Remove the bolding for CSS enabled browsers */
}
#progress a:hover{
  text-decoration:none;
}
#progress a:hover span{
  text-decoration:underline; /* Underline the title on hover */
}
#details-page .details-step a,
#account-page .account-step a,
#products-page .products-step a,
#payment-page .payment-step a{
  background:url(../img/css/splitter.gif) right center no-repeat #a49d4d; /* Arrow image on the current step */
}
#go-page .go-step a{
  background:#a49d4d; /* Arrow image not needed on final step, colour only */
}

All of the above is very obvious, it is essentially just like creating a normal navigational menu, and gives us this:

Styling numbers in ordered lists

Next up we style the numbers in the ordered list by using the very very useful and much unknown CSS counter module. Because you have such limited control over the appearance of your bullets in (ordered) lists they can be a pain to style. This pain is alleviated somewhat when using an unordered list as you can simply use a background image. It is an altogether different story when you’re using an ordered list as the bullet needs to change with each list item.

What we do here is use CSS to do a very prog-like job; we get it to loop through each item in a parent container and then increment a user-defined value each time it encounters a specified child. Sounds Greek? Read this.

Once we have this number available to us we use the CSS :before pseudo-element and the content:; property to insert the number before each item. How cool is that?!

/*------------------------------------*\
  PROGRESS
\*------------------------------------*/
#progress{
  list-style:none;
  float:left;
  margin-bottom:20px;
  counter-reset:step; /* Set up name of increment on parent */
}
#progress li{
  float:left;
  font-size:0.75em;
  font-style:italic;
}
#progress a{
  display:block;
  text-decoration:none;
  padding:10px 25px 10px 30px; /* Padding changed to 30px to accomodate number */
  background:#7b8d77;
  color:#fff;
  position:relative; /* Relative position to allow absolute positioning later on */
}
#progress span{
  font-size:1.333em;
  font-weight:bold;
  display:block;
  font-style:normal;
}
#progress strong{
  font-weight:normal
}
#progress a:hover{
  text-decoration:none;
}
#progress a:hover span{
  text-decoration:underline;
}
#progress li a:before{
  counter-increment:step; /* Increment the step on each occurance of this (pesudo) element */
  content:counter(step); /* Write out value of the increment */
  text-align:center;
  font-weight:bold;
  position:absolute; /* Position number */
  top:50%;
  left:5px;
  margin-top:-8px;
}
#details-page .details-step a,
#account-page .account-step a,
#products-page .products-step a,
#payment-page .payment-step a{
  background:url(../img/css/splitter.gif) right center no-repeat #a49d4d;
}
#go-page .go-step a{
  background:#a49d4d;
}

This then gives us this:

Progressively enhancing

Now for the CSS3 progressive bits:

/*------------------------------------*\
  PROGRESS
\*------------------------------------*/
#progress{
  background:#7b8d77; /* Give the ol a background to prevent white showing through behind the items' round corners (change value to #f00 to see what I mean) */
}
#progress{
  -moz-border-radius:5px;/* Round all corners of the progress bar */
  -webkit-border-radius:5px;
  border-radius:5px;
}
#progress a{
  text-shadow:1px 1px 1px rgba(0,0,0,0.25); /* A small text-shadow */
  -moz-border-radius:5px 0 0 5px; /* Round the top- and bottom-left corners */
  -webkit-border-radius:5px 0 0 5px;
  border-radius:5px 0 0 5px;
}
#details-page .details-step a,
#account-page .account-step a,
#products-page .products-step a,
#payment-page .payment-step a{
  background:url(../img/css/splitter.gif) right center no-repeat #a49d4d;
}
#progress .go-step a{
  -moz-border-radius:5px; /* Round all corners of the final step */
  -webkit-border-radius:5px;
  border-radius:5px;
}

The full, combined CSS for the progress bar so far is:

/*------------------------------------*\
  MAIN
\*------------------------------------*/
html{
  height:101%;
}
body{
  font-family:Calibri, Arial, Verdana, sans-serif;
  background:#fff;
  color:#88979e;
  width:940px;
  padding:10px;
  margin:0 auto;
}

/*------------------------------------*\
  PROGRESS
\*------------------------------------*/
#progress{
  list-style:none;
  background:#7b8d77;
  float:left;
  margin-bottom:20px;
  counter-reset:step;
  -moz-border-radius:5px;
  -webkit-border-radius:5px;
  border-radius:5px;
}
#progress li{
  float:left;
  font-size:0.75em;
  font-style:italic;
}
#progress a{
  display:block;
  text-decoration:none;
  padding:10px 25px 10px 30px;
  background:#7b8d77;
  color:#fff;
  text-shadow:1px 1px 1px rgba(0,0,0,0.25);
  position:relative;
  -moz-border-radius:5px 0 0 5px;
  -webkit-border-radius:5px 0 0 5px;
  border-radius:5px 0 0 5px;
}
#progress span{
  font-size:1.333em;
  font-weight:bold;
  display:block;
  font-style:normal;
}
#progress strong{
  font-weight:normal
}
#progress a:hover{
  text-decoration:none;
}
#progress a:hover span{
  text-decoration:underline;
}

#progress li a:before{
  counter-increment:step;
  content:counter(step);
  text-align:center;
  font-weight:bold;
  position:absolute;
  top:50%;
  left:5px;
  margin-top:-8px;
  padding:2px 6px;
  background:rgba(0,0,0,0.25);

  -moz-border-radius:20px;
  -webkit-border-radius:20px;
  border-radius:20px;
}
#details-page .details-step a,
#account-page .account-step a,
#products-page .products-step a,
#payment-page .payment-step a{
  background:url(../img/css/splitter.gif) right center no-repeat #a49d4d;
}
#go-page .go-step a{
  background:#a49d4d;
}
#progress .go-step a{
  -moz-border-radius:5px;
  -webkit-border-radius:5px;
  border-radius:5px;
}

Which, when coupled with the markup, gives this:

Recap

So, let’s cover what we’ve done so far. We’ve:

• Coded up a semantic progress bar (using an ordered list and correct generic elements).
• Made it accessible (addition of the strong around the content for non-CSS browsers).
• Styled it all up.
• Made use of the body ID trick to mark the current page.
• Used CSS counters to style the numbers of an ordered list
• Progressively enhanced it all to make it a little easier on the eyes.

Mobile optimisation

For more information on mobile/iPhone optimised sites please see my associated article.

Next up we need to optimise this thing for mobile. This couldn’t be simpler. The key to optimising sites for mobile is linearise. Linearise everything.

In your markup, add this line to the <head> section, thus:

<head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <title>Progress</title>
  <meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" />
  <link rel="stylesheet" type="text/css" href="css/new-style.css" />
</head>

This tells the user agent that the viewport should be the same as the device’s own screen-size, that it should be initially set to a scale of 1 (i.e. no scale), its maximum scale is set to 1, and that users can’t scale themselves.

Now, add the following to the very end of your CSS file:

/*------------------------------------*\
	MOBILE
\*------------------------------------*/
@media (max-width: 480px){ /* In any browser narrower that 480px... */
body{
	width:auto; /* Give the body a fluid width... */
	padding:5px; /* And a slight padding */
}
#progress{
	width:auto; /* Give the list a fluid width */
	background:none; /* Remove the list's background... */
	float:none; /* ...and float */
}
#progress li{
	float:none; /* Remove list item float, causing them to stack */
	margin-bottom:1px; /* Space them slightly */
}
#progress a{
	margin:0 10px; /* Indent the left and right of each item by 10px */
	-moz-border-radius:5px; /* Round all corners */
	-webkit-border-radius:5px;
	border-radius:5px;
}
#details-page .details-step a,
#account-page .account-step a,
#products-page .products-step a,
#payment-page .payment-step a,
#go-page .go-step a{
	background:#a49d4d; /* Set the background of the current item */
	margin:0 auto; /* Remove the 10px indent to show that the step is current */
}
}

Now, if you want to test this and don’t have a smartphone, or haven’t got this hosted in a live environment, simply resize your browser window right down until you see the change. I tend to use the Firefox Web Developer Toolbar addon to resize the window to 480×800px.

On the iPhone this now looks like:

Demo

For the full working demo head to http://csswizardry.com/demos/progress-bar/. For the complete CSS (with reset) please see http://csswizardry.com/demos/progress-bar/css/style.css. Also, try using Firebug to change the <body>’s ID to go-page.

Final words

As I stated previously, this article isn’t so much about the progress bar itself. What I hope this article has shown is how something as small and trivial as a progress bar has a wealth of little nooks and crannies in which to immerse yourself. Semantics, accessibility, using <body> IDs to style current states without a class="current", how to use CSS counters to style the numbers in an ordered list, how to progressively enhance lean markup, and how to optimise things for mobile in a flash.

All of the above skills are easily and quickly transferable. It might be a progress bar today, but what could it be tomorrow? Skills like the ones covered here give you the potential to make something great, out of something very very simple.

A brief example of each

Using an image:

<a href="/" title="Return to the homepage" id="logo">
  <img src="/images/logo.gif" alt="Nike logo" />
</a>

Using a <h1>:

<h1><a href="/" title="Return to the homepage">Nike</a></h1>

h1 a{
  width:;
  height:;
  display:block;
  text-indent:-9999px;
  background:url(/images/logo.gif);
}

Your logo is content

Your logo is content, not style. Style vs. content, in the web standards sense of the term, pertains to information and content that is required to be present/accessible irrespective of the presence of styles (in other words, CSS).

A logo is content. Let’s use Nike as an example throughout. Regardless of whether Nike’s site is blue, red or green, their logo will always be ‘that’ swoosh. The logo is totally independent of the site’s surrounding styles as the logo is content.

Imagine you were to visit Nike’s site in a browser that doesn’t support styles. It only makes sense that that logo is still there. It’s Nike’s brand, and it’ll be their brand whether their site is styled or not.

So your logo is content; it’s a visual representation of a brand that is defined long before that company’s site can be brought into consideration. Nike is admittedly a very big brand, but a brand nonetheless. Transport that way of thinking to any build and it’s becomes pretty obvious that a logo is indeed content.

Content = markup

So if a logo is content, a logo is markup, right? Right. You’d probably want to mark up your logo as follows:

<a href="/" title="Return to the homepage" id="logo">
  <img src="/images/logo.gif" alt="Nike logo" />
</a>

As simple as that. Regardless of styles your content—and therefore logo—persist. Use the id="logo" to style anything such as positioning, and that’s it.

Your logo isn’t a <h1>

So we’ve proved that a logo is content, but let’s now prove that it isn’t a <h1>, a commonly held practice for marking up logos.

“To have the <h1> being the logo would be like having your name being a photo. They both represent the same thing, but are separate entities…”

The <h1> element is defined as being the uppermost, all-encompassing title of a page. Now, for a homepage this is something of a grey area. The chances are that your site is the site which the logo represents, i.e. Nike’s logo appearing on Nike’s site. On the homepage the <h1> may well be whatever the logo says; it may well be <h1>Nike</h1>. This is a case where the logo and the <h1> share the same meaning. But, as discussed, the content of the two is different. The logo is still branding, and the <h1> is still a textual element. To have the <h1> being the logo would be like having your name being a photo. They both represent the same thing, but are separate entities in themselves. A coded example might be:

<a href="/" title="Return to the homepage" id="logo">
  <img src="/images/logo.gif" alt="Nike logo" />
</a>
...
<h1>Welcome to Nike's international website</h1>

Sometimes a homepage doesn’t even require a <h1> to be visible. The logo alone is enough, but your page still needs that <h1> in the markup somewhere. It needs the logo to be an image but also needs a level one heading. Here you might want to have an ‘invisible’ <h1> like I have here on CSS Wizardry. This means that semantically you’re marking up your logo as an image, as it should be, and providing a <h1> to screen-readers.

What if you don’t have a logo?

Some sites, CSS Wizardry included, don’t have a logo as such. I use a bit of browser text as a logo, but even though this is textual content I do not mark this up as a <h1>. I mark it up using an <em>. This is still a text-module element, and to my mind is semantically sound.

Problems with using a <h1> to mark up a logo

Although I did admit that the logo’s text might also be the title (<h1>) of the homepage, there’s a very good reason why you should not mark the logo up as one. What about your ‘about page’? The title of that page is undoubtedly ‘About me’, and the <h1> is a page’s title. It only stands to reason, then, that the page’s <h1> reads <h1>About me</h1>.

If however I had marked up my logo as a <h1>, the about page’s title would also be the same as the homepage, and a <h2> would have to take place as the page’s actual title. This is wrong; obviously and unarguably wrong. And, by this token, your contact and portfolio and services pages’ titles would all also be the same. This is the problem with marking logos up as <h1>s.

More practical reasons

And if you weren’t convinced enough already, using an inline image will actually make your life easier.

As previously mentioned, using an inline image allows the logo to persist regardless of styles. This means that print stylesheets will have a logo embedded in the page as an image which they can print. Most printers, to conserve ink, will not print backgrounds, which means that any logos applied by means of a background image will be lost at print. Not great that your branding will be lost as soon as your site is printed, really.

Furthermore, an inline image can have its dimensions altered. A background image on a <h1> can’t. You can alter the size of the <h1>, but not its background (unless you’re using some CSS3 background magic). This means that you cannot easily adapt the logo to different sizes through CSS alone; think about optimising for mobile. A useful CSS snippet for any mobile site is:

img{
  width:100%
  max-width:100%;
}

This means that all images will fill, but not break out of, the mobile screen. If your logo is applied as a background image it’ll get ignored here. What might happen is that your <h1> will render narrower that its background image’s dimensions (i.e. the background image is wider in pixels than the device’s screen is) on a mobile device, giving the impression of clipping the logo off. Conversely, the <h1> might not fill the width of the page leaving it, and therefore its logo background, spanning only a percentage of the page.

You can manipulate a logo as an <img /> far easier than you can as a background.

Stop applying logos as backgrounds

This really is semantics and web standards basics. A logo is content, not style. Just because your site is named the same as your logo reads does not make them the same thing. A logo should not be applied as backgrounds, and especially not to <h1>s. Some of the industry’s ‘best’ flaunt this lack of standards openly, and it’s just plain incorrect.

A logo is an image, a <h1> is a title. Your logo is never a background image, it’s never secondary content to anything. It is content in its own right and should be treated as such. Your logo is an image.

If you take only one thing from this article, let it be that your logo is content, therefore an image.

Insemantic code

The following code is just plain wrong, it’s insemantic, using the wrong elements for the wrong job:

<div class="nav-link"><a href="/">Home</a></div>
<div class="nav-link"><a href="/about/">About</a></div>
<div class="page-title">About</div>
<div>This is some page text about some stuff...</div>

Insensible code

This code is perfectly semantic, it just uses some silly classes:

<div class="border">
  <h2 class="red">This is a heading</h2>
</div>

Semantics concerns itself with elements…

…and not the names assigned to them. Using the correct element for the correct job is as far as semantics goes. Standards concerning naming of those elements is all about sensibility.

Semantics sets a standard from which it is very difficult to stray. Headings are marked up with a <h1–6>, a list with <ul/ol/dl> and so on. You cannot, however, define a convention for naming the IDs and classes of these. <div id="contact">, <div id="kontact"> and <div id="contact-info"> all bear different names, but are all equally as semantic. All three are examples of semantic and sensible code.

However, take the following examples: <div id="bottom">, <div id="lower-area"> and <div id="b">. These examples exhibit semantic code, but with insensible namings.

Be sensible, for our sake

Semantics should be adhered no matter what—web standards are good. Naming however is totally down to you, you can call your elements whatever you wish. <div id="a">, <div id="b"> and <div id="c"> are all possible, but not sensible.

“Always code like you’re working in a team, even when you’re not.”

I have actually seen markup like this, and the developer’s reasoning was ‘I like to keep my markup as lean as possible, and I know what a, b and c do’.

While this is all correct, and passable, it’s not really very sensible. He might know what a, b and c do, but what about the person who inherits the project? For all his justification of code bloat was somewhat advanced (really decreasing markup size), the impression the next guy to see his code will have will be ‘WTF was this guy thinking?!’ Always code like you’re working in a team, even when you’re not.

Final word

“An ID/class should be as short as possible but as long as necessary.—Jens Meiert

Semantics and sensibility are not the same. Anyone who tells you that class="left" is insemantic is wrong. Be semantic and be sensible. Pick names which are descriptive. An ID/class should be as short as possible but as long as necessary.

Using a combination of more advanced selectors such as sibling and nth-of-type you can target elements based on their position in the markup rather than a given name. The practical upshot of this is that your markup is much leaner and cleaner, removing class and ID names has a notable impact.

Using advanced selectors

For a complete list please see http://www.w3.org/TR/css3-selectors/

The more advanced selectors take information about an element to determine whether it matches a certain criteria, for example body>div will target a div that is a direct and immediate descendant of the body; p+p will target a paragraph immediately preceded by a paragraph.

On this basis, you could select (for example) your main content div by knowing that it’s the second div in your content wrapper: body>div div:nth-of-type(2). Broken down we have:

• body—sets the root
• >div—the first div inside the body (the wrapper div)
• div:nth-of-type(2)—the second div in the wrapper (just after the header div).

Why I think this won’t catch on

For the time being, let’s completely disregard that Internet Explorer completely disregards these selectors…

As you can see from the above example, targeting the single, lone, unique content div has taken two advanced selectors and 27 bytes. The selectors are fixed, the content div will always have to be the second div in the div that is an immediate child of the body. This is incredibly restrictive. Surely #content{…} is far better than body>div div:nth-of-type(2){…}…?

For the sake of ease, instead of rambling about pros and cons, I’ve simply drawn up a list of advantages and disadvantages:

Advantages:

• Leaner markup.
• Promotes more sensible structuring of code.
• Promotes semantics.

Disadvantages:

• Difficult syntaxes to remember.
• Extremely restrictive—elements are styled based on their location meaning that any moving/restructuring means all styles tied to an element are lost. This leads me on to…
• The CSS is no longer just describing style, it also describes structure. CSS is a styling language, not a markup one.
• Arbitrary elements such as images and divs that change depending on page content (blog posts for example) aren’t fixed enough to be styled based on their structure. This means that any variable content will require IDs and classes anyway, so you might as well us them across the board as opposed to a mix of with and without.
• Difficult to understand. I wrote the CSS for the demo page and I’m having a hard enough time doing the calculations to work out what does what. Imagine inheriting that!
• Jenga. As soon as you alter your markup, the structure dependent CSS will come falling down too, what might be the first child might become the second, making the second child the third and so on, creating a domino effect.

Final word

While the more advanced CSS(3) selectors are impressive, and incredibly powerful, they aren’t flexible enough to allow any large dependency upon them. That, and they’re more awkward to understand than the tried and tested ID/class ‘hooks’ we know and use. There are far too many downsides to make cleaner markup a big enough plus-side in my opinion… Oh, and Internet Explorer doesn’t seem to honour any of them, but that can’t have come as much of a surprise.