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.

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?

When not to use it

You should never not use an alt attribute, rather leave it empty, thus: alt=""

The only time you can really get away with not having a complete alt attribute is if the image holds no context or information that the user needs to be aware of. This is usually the case when the image is purely decorational, though it may be argued that the image should therefore be added through CSS in the spirit of separating style and content. By that token it is fairly safe to say that there should never be an instance in which you leave an alt attribute empty.

You’re using it, but not quite right…

The next best scenario is that you are using images correctly, for their correct purpose and are using alt attributes, but they don’t really do as much as they should. A lot of the time I come across images that have less than ideal alt attributes.

Image sourced via Google Images—original author unknown.

One example might be the above image of a car. This, while technically correct, is not ideal: <img src="/img/car.jpg" alt="Car" />. All this tells the user is ‘Car’. It doesn’t say whether it’s a picture with the word car in it, or whether it’s a picture of a car. A much better alt attribute would be alt="A photograph of an abandoned car" (as used in my code).

Other poor uses

Another real-world example of poor alt attribute usage is actually on CNN’s website. On their home page today (26 January, 2010) they have a series of headlines with accompanying images. The code for such a pairing looks like this:

<img height="68" border="0" width="120" alt="Haiti's swanky club →
now home to misery" src="http://i.cdn.turner.com/cnn/2010/WORLD/ →
americas/01/26/haiti.camp/tzvids.haiti.aid.cnn.jpg"> →
… Haiti's swanky club now home to misery

This is wrong on two counts:

1. A screenreader will read out to the user Haiti’s swanky club now home to misery … Haiti’s swanky club now home to misery. Every image/headline pairing on the page is laid out like this, meaning in every instance a user using a screenreader will hear the headline twice. This will surely soon get annoying.
2. Secondly, the image was actually of earthquake survivors holding a large bag, nothing to do with clubs and, unfortunately, far from swanky.

Using the attribute properly

On the BBC’s home page however (on the same date) they are using alt attributes perfectly. They have an image of a woman wearing a veil, alongside the article’s headline France report back face veil ban. The image’s alt attribute: alt="A woman wears a full-length veil in Lyon, 25 January".

The biggest no-no of all

One thing which consistently winds me up is the ridiculously bad practice of stuffing alt attributes with keywords. alt attributes are an accessibility feature, end of. They are not a way of slipping in keywords out of sight, and any attempt to do so is irresponsible and incredibly bad practice. The only time ‘keywords’ may be validly placed in alt attributes is if it’s explicitly related to the image; for example: <img src="/img/product.jpg" alt="A photograph of Mike's Carpets' ProClean™ carpet cleaner" />.

How to do it properly

Writing proper alt text is incredibly simple, yet a little more time consuming than the ‘Car’ cop-out. All you need to do is write out in full exactly what the image shows. If it’s an elephant giving a donkey a piggy-back don’t be lazy and use alt="Elephant and a donkey". Instead, write out alt="A photograph of an African elephant giving a donkey a piggy back across a swamp".

Also, for any pages that use similar images repeatedly but are slightly different to one another, make sure your alt attributes reflect these differences. A good example would be my portfolio page. Instead of using alt="Screenshot" over and over again I used text like alt="Screenshot of Suzanna Haworth’s website" and alt="Screenshot of RAAMaudio UK Ltd." etc.

This is one of the most basic aspects of web development, but one that too many people are still getting wrong.

Typographic work planner markup:

The rich, semantic markup is as follows. Notice the use of the more semantic elements and attributes such as summary="", colgroup, scope="", caption and more…

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8" />

  <title>Typographic work planner</title>

  <link rel="stylesheet" type="text/css" href="css/style.css" />
</head>
<body id="home">
  <div id="wrapper">
    <table summary="An overview of upcoming and recently completed work ?
    by employees">
      <caption>Work schedule</caption>
      <colgroup>
        <col id="date" />
        <col id="user" />
        <col id="dec" />
      </colgroup>
      <thead>
        <tr>
          <th scope="col">Date</th>
          <th scope="col">User</th>
          <th scope="col">Description</th>
        </tr>
      </thead>
      <tfoot>
        <tr>
          <td colspan="3">Sense Internet Ltd work planner</td>
        </tr>
      </tfoot>
      <tbody>
        <tr>
          <td class="date">20 December, 2009</td>
          <td class="user">Harry Roberts</td>
          <td class="desc">Lorem ipsum dolor sit amet, elit. Nunc ?
          rhoncus dui et mauris. Nam augue felis, dapibus ut, condimentum ?
          in, ornare a, est. Proin sem risus, pretium ut, mattis nec.</td>
        </tr>
        <tr>
          <td class="date">20 December, 2009</td>
          <td class="user">Joe Whitley</td>
          <td class="desc">Suspendisse venenatis. Donec eleifend ?
          dignissim diam. Integer faucibus neque tempor pede. Maecenas at ?
          magna sed lectus adipiscing molestie. Pellentesque habitant morbi ?
          tristique senectus et netuset malesuada fames ac turpis egestas. ?
          Curabitur sodales gravida tellus.</td>
        </tr>
        <tr>
          <td class="date">21 December, 2009</td>
          <td class="user">Harry Roberts</td>
          <td class="desc">Lorem ipsum dolor sit amet, elit. Nunc ?
          rhoncus dui et mauris. Nam augue felis, dapibus ut, condimentum ?
          in, ornare a, est. Proin sem risus, pretium ut, mattis nec.</td>
        </tr>
        <tr>
          <td class="date">21 December, 2009</td>
          <td class="user">Joe Whitley</td>
          <td class="desc">Suspendisse venenatis. Donec eleifend ?
          dignissim diam. Integer faucibus neque tempor pede. Maecenas at ?
          magna sed lectus adipiscing molestie. Pellentesque habitant morbi ?
          tristique senectus et netuset malesuada fames ac turpis egestas. ?
          Curabitur sodales gravida tellus.</td>
        </tr>
        <tr>
          <td class="date">21 December, 2009</td>
          <td class="user">Sam Penrose</td>
          <td class="desc">Lorem ipsum dolor sit amet, elit. Nunc ?
          rhoncus dui et mauris. Nam augue felis, dapibus ut, condimentum ?
          in, ornare a, est. Proin sem risus, pretium ut, mattis nec.</td>
        </tr>
        <tr class="today">
          <td class="date">22 December, 2009</td>
          <td class="user">Joe Whitley</td>
          <td class="desc">Suspendisse venenatis. Donec eleifend ?
          dignissim diam. Integer faucibus neque tempor pede. Maecenas at ?
          magna sed lectus adipiscing molestie. Pellentesque habitant morbi ?
          tristique senectus et netuset malesuada fames ac turpis egestas. ?
          Curabitur sodales gravida tellus.</td>
        </tr>
        <tr class="today">
          <td class="date">22 December, 2009</td>
          <td class="user">Sam Penrose</td>
          <td class="desc">Lorem ipsum dolor sit amet, elit. Nunc ?
          rhoncus dui et mauris. Nam augue felis, dapibus ut, condimentum ?
          in, ornare a, est. Proin sem risus, pretium ut, mattis nec.</td>
        </tr>
        <tr class="today">
          <td class="date">22 December, 2009</td>
          <td class="user">Joe Whitley</td>
          <td class="desc">Suspendisse venenatis. Donec eleifend ?
          dignissim diam. Integer faucibus neque tempor pede. Maecenas at ?
          magna sed lectus adipiscing molestie. Pellentesque habitant morbi ?
          tristique senectus et netuset malesuada fames ac turpis egestas. ?
          Curabitur sodales gravida tellus.</td>
        </tr>
      </tbody>
    </table>
  </div>
  </body>
</html>

In detail…

There are a few things in the table you may not have seen before, briefly, they are:

• summary="": This is an attribute which provides a brief overview of the table and its contents/purpose.
• caption: This is a table specific caption, essentially a heading/title explicitly for the table.
• colgroup and col: This is an essentially invisible element that just adds semantic meaning to the table. It defines the columns and can—in some browsers—be used to style them.
• scope="col": This is an attribute which tells the browser whether the th is a title for a column or a row. This then obviously makes the other possible attribute value row.
• tfoot: This is a table footer and contain pretty much anything you like. It must however appear before the tbody.

Typographic work planner CSS:

The CSS used to create the work planner is pretty basic, with a dash or progressive enhancement added via some CSS3. View the full CSS file with reset etc.

table{
  margin-bottom:20px;
}
td,th{
  border-bottom:1px solid #ccc;
}
tbody tr{
  background:#fff;
}
tbody tr:nth-of-type(even){
  background:#ffc;
}
th,tfoot,caption{
  font-family:Helvetica, Arial, Verdana, sans-serif;
  font-size:1.6em;
  font-weight:bold;
}
th,td{
  padding:10px 0;
}
caption{
  font-size:2.4em;
  position:absolute;
  left:-9999px;
}
.date{
  width:160px;
  padding:10px 15px 10px 5px;
  font-family:Georgia, "Times New Roman", Times;
  font-size:1.6em;
  font-style:italic;
}
.user{
  width:460px;
  padding-right:20px;
  font-family:Helvetica, Arial, Verdana, sans-serif;
  font-size:4.8em;
  font-weight:bold;
}
.desc{
  width:280px;
  font-size:1.2em;
}
tbody tr.today{
  background:#ff8;

  text-shadow:1px 1px 1px rgba(0,0,0,0.3);
}
tfoot{
  color:#666;
}
tfoot td{
  padding:10px 5px;
}

Typographic work planner demo