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…

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.

What the facts state

<b> and <i> are still valid, and as XHTML is just an XML serialisation of HTML, pretty much all the elements apparent in the HTML spec are true of the XHTML spec too—it is, pretty much, just the way in which these elements are written that makes them different in XHTML.

Twitter

With the help of @smashingmag I turned to Twitter and my knowledgeable followers and asked the question:

“Using <i> and <b> in (valid) XHTML (strict)… your thoughts on this would be much appreciated. #upcomingBlogPost Cheers all!” @csswizardry

Most of the answers I got said petty much the same thing: use strong and em … b and i are deprecated. While this is largely true, there are some myths that need dispelling.

• strong and em are not the same as bold and italics. strong is strong emphasis and em is emphasis. It is purely through convention that these two elements happen to adopt either bold or italicised appearances.
• b and i are not deprecated in any way in HTML or XHTML. They are still in existence, still valid and still (in the right places) usable.

Some replies

A few choice replies I received which are, on the whole, representative of everyone’s thoughts:

“strong and em make more sense, especially when taking screen readers into account. @CreativeNotice

Or so you’d think, see below…

“I prefer <strong> </em> because of semantics . You want to put emphasis, not just make text italic.” @WeHelpDesign

True, if you do just want emphasis that is…

“Using <i> and <b> is just fine if it’s for visual bling without real semantic background.” @levito

Ah, this is more like it!

“<b> and <i> tags describe presentation, not structural semantics. Rather style <em> and <strong> tags.” @hornergraphic

A view that is seemingly shared by almost everyone else who responded.

What about strong and em?

The vast majority of people who replied were in favour of strong and em over b and i. Presuming all respondents were assuming the question was ‘What are your thoughts on using b and i to represent strong emphasis and emphasis, and thus replace strong and em?’ then they’d have all been spot on correct. However, b and i and strong and em are totally separate things. b and i assume no semantic value, meaning literally bold and italic respectively. strong and em however have nothing to do with bold or italics. As previously mentioned, it is through convention only that the default styling for each is so.

strong and em are ‘spoken word’ type elements, where they represent a change in tone only. This means that their styling is in no way linked to their naming, it is just that us, as people, are familiar with italicised prose sounding more stressed—or emphasised—than surrounding text. This is where the importance of aforementioned semantics and screenreaders come in. Or is it…?

The screenreader fallacy

Screenreaders don’t use strong and em!

The common belief is that strong and em’s semantic meaning is used by screenreaders to alter tonality when reading content aloud, thus letting the user know that the copy is in fact meant to be understood in a different manner to any neighbouring text. This was something I too believed until the wonderfully knowledgeable @pekingspring pointed me toward this article by @stevefaulkner—it turns out screenreaders don’t use strong and em to alter tonality!

This means that screenreaders see no semantic value in the strong and em element. However, they should be used unconditionally where a change in tone is implied, whether a screenreader will understand this or not.

Where to use <b> and <i> then?

One of my first thoughts was where to use these elements if indeed they are still usable. My initial idea was the use of i for markup up things that have to be italicised but the italics aren’t indicative of any tone. To quote the Penguin Guide to Punctuation:

“Another use of italics … is to cite titles of complete works…”

Initially I thought this was the ideal use for the i element—something that had to be in italics, yet implied no tone of voice. It was such a good fit! However, @pekingspring came to my aid again and reminded me that the cite element is for this exact purpose. That was that idea gone.

Another possible usage for the i element was gleaned from the Typography Manual iPhone app, which states:

“Italics should be used for single letters in a sentence referred to as letters. [for] example ‘The letter j appears too large.’”

An idea I had for using b was somewhat linked to the cite element anyway. A common mistake is to markup the ‘author’ of a quote in cite tags. This is of course incorrect, but what do you use? It’s not really a paragraph, so what is it? I did consider the b element for this, but I feel that such a piece of information does need a more semantic element to represent it.

Friend and colleague @simonwiffen has a very nicely written example usage for each, which I personally think are spot on. The following chunk of text is lifted directly from an internal document written by @simonwiffen:

1.4.3 Strong, emphasis, bold and italic

<strong> (strong emphasis) and <em> (emphasis) should be used as opposed to <b> (bold) and <i> (italic) unless the bold or italic is required without any semantic context (for example in a product name).

Examples

Remember you must check this box

<p>Remember <strong>you must</strong> check this box.</p>

You should really try to validate your pages

<p>You should <em>really</em> try to validate your pages</p>

Read more about Splashdown!™ below

<p>Read more about <b>Splash<i>down</i>!™</b> below</p>

Succinct and, in my opinion, pretty hard to argue with.

HTML5 has it sussed

I won’t be using HTML5 for a long while yet, but that’s another story altogether…

Ideally I’d like to retrofit the HTML5 specification’s definitions of each for use right now in XHTML, however I’m not sure I’d be comfortable going ahead with doing such a thing, coding to one spec whilst picking my favourite bits of another.

The <b> element in HTML5

“The b element represents a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as key words in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is boldened.”

HTML5

The <i> element in HTML5

“The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized.”

HTML5

A go-between in the meantime?

There will always be the argument that instead of using b and i you could or should use something like <span class="italics"> or <span class="bold"> so as to avoid using insemantic elements, however a class name like that is more insemantic than an in-spec HTML element. Not to mention the fact that a span with a class applied is far more cumbersome than a ‘pre-made’ piece of HTML.

The resolve?

So which is worse?

• Using i to mark up emphasised text
• Using em to mark up italicised and non-emphasised text
• Using i to mark up purely italicised text
• Using <span class="italics"> to mark up italicised text

Special thanks to the following for help with this article: @smashingmag, @pekingspring, @stevefaulkner, @simonwiffen and all my Twitter followers.

I think that the fact that b and i are still in the spec, are valid (even in strict) and are being carried over to HTML5 (albeit slightly redefined) indicates that there is still a very real place for them in web development right now. The frequency with which they’ll be used is slim at best, but they should not be ruled out, and at the very least not misunderstood. I’m not going to make the leap myself just yet, but they are there, they are usable, and one day I might just use them.

What are you going to do?