In case you were wondering, I’ve got two more posts after this one and then I’m moving onto CSS and JavaScript. I’ve got a post on forms (which I’ve been avoiding because forms feel like work) and then a post on the new HTML5 elements and then that’s it.

Writing about CSS and JavaScript will be fun. I’m excited. More excited than I am to write about forms at least. Which isn’t to say I won’t kick ass when writing about forms. It’ll be great.

Ignore me.

On with the show:

B, Strong, Em, I

From the just in case you were wondering what’s up with strong and em and why people use them over b and i department:

The b (bold) and i (italic) tags have been in HTML forever. I haven’t figured out when they first appeared, but they were promised as part of the documentation to the fist web site in August 1991 and later codified as part of the unofficial HTML1 spec in 1993, so 1992 is as good a bet as any.

Later on the concept of “phrase elements” was introduced. They were meant to add “structural information to text fragments” Two of those, strong and em are basically new versions of good old b and i minus the typographic baggage.

Fast forward to 2000. The W3C publishes the Web Content Accessibility Guidelines. In the section on emphasis they state:

Checkpoints in this section:

* 3.3 Use style sheets to control layout and presentation. [Priority 2]

The proper HTML elements should be used to mark up emphasis: EM and STRONG. The B and I elements should not be used; they are used to create a visual presentation effect. The EM and STRONG elements were designed to indicate structural emphasis that may be rendered in a variety of ways (font style changes, speech inflection changes, etc.)

This recommendation stuck. A lot of code has been written with strong andem and all good IDEs use them when you press the b and i buttons on the toolbar. They’re pretty standard now.

And that’s how we got to strong and em.

And now you know.

Interestingly, b and i are making a comeback in HTML5, having been given a new semantic lease on life. More on that in a couple of weeks.

The Lang attribute

As we saw way back in the third entry in this series, your HTML document should signify its language on the opening html tag. Simple enough. So, what happens if you need to use some text from another language? You pull out the lang attribute and mark up your text accordingly. Here’s a block of text which will illustrate what I’m talking about.

I’m a big fan of movies. For a few examples of the genres I like, check out my writing on French crime drama (Du rififi chez les hommes), Hong Kong martial arts (精武英雄/Fist of Legend), and Japanese samurai cinema (座頭市物語/Zatoichi)

Here’s what that little snippet looks like marked up:

I'm a big fan of movies. For a few examples of the genres I like, check out my writing on French crime drama 
(<a href="http://www.drunkenfist.com/movies/indy-foreign/rififi.php" lang="fr">Du rififi chez les hommes</a>), 
Hong Kong martial arts (<a href="http://www.drunkenfist.com/movies/hong-kong/fist-of-legend.php"><span lang="zh">
精武英雄</span>/Fist of Legend</a>), and Japanese samurai cinema 
(<a href="http://www.drunkenfist.com/movies/japan/tale-of-zatoichi.php"><span lang="ja">座頭市物語</span>/Zatoichi</a>)

See the several instances of lang, with the appropriate language code? It’s a simple enough pattern, but it’s also very important. It gives computers and screen readers clue that the language contained therein should be handled differently than the surrounding text. That’s a positive.

Span

I used a couple of spans in the above example. That’s one of handful of cases where I use them. I’ve got nothing against a span or two. I just don’t use them very often.

There’s a point to this little aside- To my mind, if you can find a pattern that describes your content better and allows you to execute your design, go with the semantic pattern and skip the span (or divs.) Training yourself to think that way will (hopefully) lead you to writing HTML that is richer in meaning and easier for other authors to understand.

Use Structural Elements Wherever Possible

There are several structural elements I try to use where applicable:

ABBR

Indicates an abbreviated form. Use the title attribute to indicate the full or expanded form.

Acronym

Indicates an acronym. Use the title attribute to indicate the full or expanded form.

Cite

Contains a citation or a reference to other sources.

Code

Designates a fragment of computer code.

Blockquote

Designates a quoted passage. Use the cite attribute to indicate the source.

There are a few more that I’ve literally never used. The above come up pretty regularly, at least in the content I deal with. Of those, I use blockquote and code most regularly. I feel a bit guilty at not using the other ones more often.

Such is my life.

That’ll do it for now. I might get a bolt of inspiration and tack onto this post from time to time, but for now…. done.

Next week. FORMS.