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.

View demo

The trick here is to force the list to break at the right point. If you want two columns, you need to float the list items left and set them at 50% width, therefore the list items will only ever fit two side-by-side, then begin again on the row beneath. By that token, three columns would require a width of 33% and floated left, four would be 25% and so on.

The code

Both the markup and CSS for this is incredibly simple, nothing fancy, no CSS3, nothing progressive, just basic styling applied to lean markup.

The markup

The markup for this is just a simple ul, thus:

<ul id="double"> <!-- Alter ID accordingly -->
  <li>CSS</li>
  <li>XHTML</li>
  <li>Semantics</li>
  <li>Accessibility</li>
  <li>Usability</li>
  <li>Web Standards</li>
  <li>PHP</li>
  <li>Typography</li>
  <li>Grids</li>
  <li>CSS3</li>
  <li>HTML5</li>
  <li>UI</li>
</ul>

And to make this into a multiple column list:

ul{
  width:760px;
  margin-bottom:20px;
  overflow:hidden;
  border-top:1px solid #ccc;
}
li{
  line-height:1.5em;
  border-bottom:1px solid #ccc;
  float:left;
  display:inline;
}
#double li  { width:50%;} /* 2 col */
#triple li  { width:33.333%; } /* 3 col */
#quad li    { width:25%; } /* 4 col */
#six li     { width:16.666%; } /* 6 col */

When to use this

Use this wisely… It displays content in an ambiguous manner and should not be used where order of reading is imperative.

This method should only be used if the lists content doesn’t require any specific ordering as the markup is written linearly and the list is displayed in a matrix. As you can see, the way the content is displayed means it can be read across»down»across or down»up»down. This means that the way you write your content is not necessarily the way it will be read. In my example this isn’t an issue, as the content can safely be read in any order.

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?

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