BlogmyQuery – BMQ

Whatever you call them — blocks, boxes, areas, regions — we’ve been dividing our Web pages into visible sections for well over a decade. The problem is, we’ve never had the right tools to do so. While our interfaces look all the world like grids, the underlying structure has been cobbled together from numbered headings and unsemantic helper elements; an unbridled stream of content at odds with its own box-like appearance.

Because we can make our <div>s look but not behave like sections, the experience for assistive technology (AT) users and data-mining software is quite different from the experience enjoyed by those gifted with sight.

Now that HTML5 has finally made sectioning elements available, many of us greet them with great reluctance. Why? Partly, because we’re a community which is deceptively resistant to change, but also because of some perceived discrepancies regarding advice in the specification. In truth, the advice is sound and the algorithm for sectioning is actually easier to use than previous implementations. Some dev’s are just very married to their old workflow, and they think you should be too. There’s no good reason why.

Make no mistake: Sectioning elements help you improve document structure, and they’re in the spec’ to stay. Once and for all, I will be exploring the problems these elements solve, the opportunities they offer and their important but misunderstood contribution to the semantic Web. If you’re unfamiliar with the concept of the “semantic Web,â€� this video is a great introduction.

Making Websites

My introduction to Web design was via a university course module called something like “2.1: Dreamweaver,� and I recall my first website well. I remember my deliberately garish choice of Web-safe colors. I remember it looking right only in Netscape Navigator. Most of all, I remember hours of frustration from tugging at the perimeter of a visual layout tool named “table.� I had no idea at the time that this layout tool represented a type of annotation called an HTML tag. Furthermore, no one told me that this annotation invited my patchwork of primary colors and compressed JPEGs to be computed as a sort of demented Excel spreadsheet. In other words, I had no idea I was doing it wrong.

*Bites tongue*

The fundamental failure of most graphic, product, architectural, and even urban design is its insistence on serving the God of Looking-Good rather than the God of Being-Good.

Macromedia’s Dreamweaver didn’t make the creation of valid documents impossible, but it was one of a number of emerging GUI editors that pandered to our desire for visual expression more than it encouraged informational clarity. Dreamweaver, and other editors classified under the misnomer “WYSIWYG,� helped transform a standardized information system into a home for graphic design and enabled a legion of insufferable Nathan Barleys to flypost the World Wide Web with their vapid eye candy. I was one of many.

Web Standards

By the time I made my first website, the Web standards movement, promoting compliance, uniformity and inclusion, was burgeoning. I just wasn’t aware of it until much later. I didn’t have to be: Agency-based Web design was still mainly graphic design with a reluctant programming department clumsily bolted on. If you’re doubtful of the grip that this culture has had on the World Wide Web, look no further than the fact it took until 2010 (2010!) for us to concede that Web browsers are not really made of paper.

When I finally became familiar with Web standards and the practice of “doing things right,â€� it was as someone who still worked primarily as a visual designer. Inevitably, my first forays into standards-based design revolved around mastering “CSS layout,â€� the practice of visually arranging content without relying on the semantically incorrect <table> element. We’ve held up <div>-based layout as a mark of quality for a number of years now. You might even say that it has become a time-honored rite of passage for graphic designers who are moving into “properâ€� HTML coding.

As I shall demonstrate, the <div> is the ultimate Graphic Design tool. By affecting only appearance, it licenses poor document structure and overengineered interfaces; all without making your document technically invalid. As such, it sanctions the worst kind of hacks.

The Problem With <div>

Every day, thousands of Web developers invoke the almighty <div> to divide, partition and ring-fence their Web pages’ content. We use the <div> to police content, to prevent disparate chunks of information from collapsing into each other. In truth, the <div> has no such power.

Consider the following example:

In this basic layout, I have included a body of text and an adjacent “sidebar.â€� To make it absolutely clear to the reader that the sidebar is tangential and does not belong to the main content, I’ve drawn a fat line around it using the border property. For those of you screaming, “That sidebar heading should be an <h3>!â€�, I’ll get to that shortly. All of my design decisions (the adjacent position, the border and the reduced font size) are facilitated by CSS alone. So, when I take the CSS away, I get this:

Not only is switching off CSS the quickest way to make a Web page responsive, but it’s a great way to see how HTML4 documents (which lack sectioning elements) are actually computed. In this case, our so-called “sidebar� is revealed to be just another raft of information in the linear flow of the document.

Why Is This So?

The reason for this is that the <div> is, and always has been, a flow content element. No matter how thick the <div>’s borders or how dark its background color, it does not stand apart in the structure of the document. Neither, therefore, does its content. With the CSS removed, the faux sidebar’s heading of “Resourcesâ€� now seems less a distinct component of the page and more a part of the main content. To a parser or screen reader, it would have seemed this way all along.

For reasons of clarity, let’s look at a further example using a snippet of HTML:

 
	<div class="parent">
	<h2>Heading</h2>
	<p>Some content...</p>
		<div class="child">
			<h2>Another heading</h2>
			<p>Some other content...</p>
		</div>
	</div> 

I’ve done something slightly different here by entering the two <div>s into a parent-child relationship: The div.child tag belongs to div.parent. We can certainly make it look that way with CSS, anyway. However, <div>s, to quote the specification, “have no special meaning.â€� Not only do they not mean anything semantically, but they have no impact on the computable structure of the page (sometimes called the “document outlineâ€�). The <div>s we’ve used may as well be invisible; so, to get a meaningful map of the structure we’ve created, we should remove them completely. That leaves just four elements and reveals the parent-child relationship to be an illusion:

 
	<h2>Heading</h2>
	<p>Some content...</p>
	<h2>Another heading</h2>
	<p>Some other content...</p> 

As HTML coders interested in sound structure, we should be interested that the above reduction — which omits all meaningless elements — is what we’ve actually made, and it’s not what we set out to do: By not really belonging to “parent,â€� “childâ€� has a different contextual status in the document than intended.

Heading Levels Don’t Really Help

It’s popular to believe that replacing the second <h2> with an <h3> would solve our problem. If we did so, we’d get the following, more dynamic outline:

• A Heading (h2)
  • Another Heading (h3)

This solution certainly seems more purposeful, but is it the right decision? Should the second heading be a subheading within the same topic (an <h3>) or be the introduction of an entirely new topic (an <h2>, as we had in the first place)? Headings alone can only show where a piece of content starts, not where it ends, which makes it difficult to tell what belongs to what. We have to simulate belonging by choosing the correct heading level for the context. Just think about that for a second: We’re defining the content’s structural status by labeling it retroactively. It’s just begging to go wrong.

Lets have a look at the homepage of accessibility experts The Paciello Group. Naturally, it’s a highly accessible and pretty well organized site, but could the structure be improved with HTML5 sections? You’ll notice their use of a <div> to collectively wrap the three <h2>s, Software Developers, Website Owners and Mike Paciello. Since the <div> doesn’t computably contain these three blocks, the last <h2> and the following <h3> are allowed to pair off in this relationship:

• Mike Paciello (h2)
  • Contact Us Now (h3)

Wait … so, “Contact Us Nowâ€� is a subtopic belonging to the larger theme of “Mike Pacielloâ€�. Can that be right? It certainly doesn’t look this way in the visual layout. It’s worth noting at this point that the <div> which fails to thematically group those three <h2> blocks has a class of class="region". Ironically, if this <div> had been a <section>, some screen readers would consider it a “region”. If a <section> had been used in place of the <div>, the observed relationship would not have emerged: The “region” would be self-contained. The class of “region”, however, is not taken into consideration in any meaningful way and does not affect the structure.

Okay, so that’s a weird one, but the situation only gets more confusing when we start to include items for which headings aren’t really even appropriate. Take this further example:

In my HTML4 page, I have an <h1> to introduce the document, an <h2> for the main content and an <h3> to mark the start of my “sidebarâ€� (which is just a wishy-washy <div>, as in previous examples). The page follows long-standing convention by having an untitled div#footer resting at the foot of the document for copyright information and other such necessary evils. (It has to be a <div> in HTML4, because the <footer> tag doesn’t exist yet.) The question is, to which heading does the footer belong?

Whose Footer Is This?

Most of us, based on appearances, would agree that the footer must belong to the document. That is what we’ve learned to expect. To the unsighted, it is a different story: Because there is no new introductory heading between the sidebar <h3> and the footer content, it could be extrapolated that these two components are as one (see image below left). By the same token, one could also argue that we’ve included the “sidebarâ€� as a mere “breakâ€� from the flow of the main content, before returning to that flow at the advent of the footer (see image below right). This would make the <h2> the footer’s heading.

The only decent chance we have of understanding the intended structure of the page is by inferring it from a reading of the content. Remembering that the whole point of a “markup language� is to make the structure of information easier to follow, I may as well have chucked the HTML and written my Web page on the back of a napkin.

Some accessibility gurus would suggest that you use a remedial <h2> to head the #footer and bring it back in line, marking up the end of the sidebar like so:

• h1 (page)
  • h2 (main)
    • h3 (sidebar)
  • h2 (footer)

This kind of works as a hack, but it’s not really sound. Do you really want to make a big announcement of the footer — an announcement as big and bold as the one used to summon the main content, not to mention bolder than the sidebar? No. If our Web page were a film, the footer wouldn’t be the titles — it would be the credits. In HTML5, the <footer> element “contains information about its section.â€� This is semantically superior: We don’t use footers to introduce topics; we use them to conclude them. Accordingly, footers — unlike their parent sections in HTML5 — do not require headings.

Just because the nesting level of headings is correct doesn’t necessarily make a page easy to read.

The closest thing we have to a “systemâ€� for structuring documents properly in HTML4 is numbered headings. Not only does this lead to ambiguity, as explained, but in practice we don’t really even use headings to define structure. We use <div>s to define structure and throw in some apologetic headings for accessibility’s sake. To make matters even worse, advice regarding the deployment of numbered headings isn’t even clear on whether we should use them in order (h1-h6) or not.

The loose coupling between headings and <div>s is inadequate. Now, with the introduction of sectioning elements, we still use boxes, of sorts, but boxes that actually say something on their own. We are making a move from merely implying sections (by labeling them) to letting them define themselves. Simultaneously, sighted readers and unsighted parsers can experience content that one has effortlessly divided into clear, manageable portions.

The HTML4 spec is very imprecise on what is a section and how its scope is defined. Automatic generation of outlines is important, especially for assistive technology, that are likely to adapt the way they present information to the users according to the structure of the document. HTML5 removes the need for <div> elements from the outlining algorithm by introducing a new element, <section>, the HTML Section Element.

Sectioning

Aware of our desire for legitimate elements to create computable sections, HTML5 offers <section>, <article>, <aside> and <nav>. Like some sort of obnoxious holiday rep’, I’ll introduce the topic of practical sectioning using these elements with a quick quiz. Study the following diagram. How many sections do you count?

Multiple-choice answers:

1. 1
2. 2
3. 3
4. 4

The correct answer is (a), 2. We have included just one of HTML5’s new sectioning elements in the form of an <aside>. Because <footer>s and <header>s are not sectioning elements, what does that leave us with? The <body> tag is the outermost element, making the document itself a kind of section (a supersection, to be precise). So, there you have it: We’ve been using “sectioningâ€� since HTML 1.0, just not with any subsections to speak of.

Some of you may have missed the clue earlier in this article and thought that <header> and <footer> were sectioning elements. Don’t fret; it’s not your fault. Whenever developers like myself try to explain HTML5 page structure, they usually brandish a diagram like the one I used above. In these diagrams, the boxes marked “header,â€� “asideâ€� and “footerâ€� exist in the same visual paradigm and occupy a similar area. They seem alike, you might say. The other culprit for this endemic confusion is the way the specification is written. Believe it or not, the document structure of some pages in the specification that refer to document structure is structurally unclear! This sort of thing sometimes happens when a standard is constantly evolving. The navigation tree for “4.4 Sectionsâ€� found in this draft is laid out like so:

• 4.4 Sections
  • 4.4.1 body
  • 4.4.2 nav
  • 4.4.3 article
  • 4.4.4 aside
  • 4.4.5 h1, h2, h3, h4, h5 and h6
  • 4.4.6 hgroup
  • 4.4.7 header
  • 4.4.8 footer
  • 4.4.9 address

You’d be forgiven for thinking that anything in this list qualifies as a sectioning element, absurd as some of them (<address>?) may sound. It’s only when you navigate to 4.4 Sections > 4.4.8 Footer that you’re told that “the footer element is not sectioning content; it doesn’t introduce a new section.â€� Thanks!

Despite these ambiguities in the spec’ itself, as well as in the surrounding publicity for HTML5, sectioning in practice just works. The following three axioms are probably all you’ll need to understand the algorithm:

1. <body> is the first section;
2. <article>, <section>, <nav> and <aside> make subsections;
3. Subsections may contain more sections (subsections)

Aside from a few trifling details, that’s it. In a little while I’ll cover the completely unnecessary worry that is had over headings combined with sections. For now, let’s take another look at that example from before about footer ownership. This time, I’ll make a few HTML5 substitutions:

Note the lack of illustrated headings. Wherever a section is opened, it assumes responsibility for nesting: The heading type is unimportant. More on this soon …

The outline for this example looks like this:

• Document
  • Article
    • Aside

Now that we’ve implemented sections, the boundaries are clear. Our document contains an article, which, in turn, contains an aside. There are three sections, each belonging to the last, and the depth of each section is reflected in the outline. Importantly, because sectioning elements wrap their contents, we know perfectly well where they end, as well as where they begin. And yes — screen readers like JAWS actually announce the end of sections like these! We know what content belongs to what, which makes deducing the purpose of the footer much easier. Because it exists outside the bounds of both the <article> and its <aside>, it must be the document’s footer. Here’s the same diagram again, with subsections faded out:

The power of sectioning lies in its ability to prescribe clearly defined boundaries, resulting in a more modular document hierarchy. The footer unequivocally belongs within the immediate scope of the highest-level section, giving assistive technologies and indexing parsers a good idea of its scope, which helps to make sense of the page’s overall structure.

Headings And Accessibility

When Sir Tim Berners-Lee conceived the <section> element all the way back in 1991, he envisioned the obsolescence of ranked heading levels. The thrust of the idea was that headings should act as mere labels for blocks of content, and the nature (i.e. the importance, scope, etc.) of the content would be calculated automatically based on the content’s standing in the document.

I would in fact prefer, instead of <h1>, <h2> etc for headings [those come from the AAP DTD] to have a nestable <section>..</section> element, and a generic <h>..</h> which at any level within the sections would produce the required level of heading.

Why is this preferable? Determining heading level systemically, based on nesting level, is much more dependable because it removes a layer of decision-making: By “producingâ€� the required heading level automatically, we no longer have to decide separately which numbered heading we should include. It effectively prevents us from choosing the wrong heading level, which would be bad for parsable structure. A subsection must be subject to its parent section. Because this relationship between sections determines “level,â€� numbered headings are made redundant — hence, the proposed <h>.

A lot of fuss over nothing

Now, this is the supposedly tricky part; the part that causes all the consternation and gnashing of teeth. This is the part that caused Luke Stevens to write this diatribe, and prompted Roger Johansson into a state of uncharacteristic apoplexy, asking, “are you confused too?�. Ready?

In the WHATWG specification (in the same place where <footer>s were ostensibly classified as sectioning elements!), we are “strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section’s nesting level.â€� On first appearance, this seems contrary. Surely only one of these courses of action can possibly be right? What do you do? I’m thinking maybe the first option. Or the second. Who am I?

It certainly confused me, so I spoke with HTML Editor, Ian Hickson. He explained the outline to me in detail and I’m convinced it is perfectly robust. I’m going to do my best to explain it to you here.

Okay. As it turns out, we didn’t get the generic <h> element. This wouldn’t be backwards compatible because older browsers wouldn’t recognise it. However, headings that introduce sections are — regardless of their numbered level — treated as a generic <h>. Quite correctly, it is the section itself that takes responsibility for nesting in these situations — not the heading — and whenever you introduce a new section, you introduce a new nesting level without fail. What does this mean in practice? It means that we can introduce and benefit from the structural clarification offered by sections without abandoning heading levels. Take the following example:

<h4>Page heading</h4>
<p>Introductory paragraph...</p>
<section>
    <h3>Section heading</h3>
    <p>some content...</p>
    <h2>Subheading</h2>
    <p>content following subheading...</p>
    <section>
        <h1>Sub-subheading</h1>
        <p>content two levels deep...</p>
    </section>
</section>
<h5>Another heading</h5>
<p>Continued content...</p>

Our heading levels are all over the place. This is not recommended by the specification, but it helps demonstrate just how robust the HTML5 outlining algorithm really is. If we replace all the headings that open sections with a generic (“wildcard”, if you prefer) <h>, things become clearer:

<h>Page heading</h>
<p>Introductory paragraph...</p>
<section>
    <h>Section heading</h>
    <p>some content...</p>
    <h2>Subheading</h2>
    <p>content following subheading...</p>
    <section>
        <h>Sub-subheading</h>
        <p>content two levels deep...</p>
    </section>
</section>
<h5>Another heading</h5>
<p>Continued content...</p>

It’s important to note that the only errors revealed in the computed outline are ones relating to badly ordered numbered headings within the same section. In the original example, you’ll see that I’ve followed an <h3> with an <h2>. Because they are in the wrong order, the outline interprets them as being on the same level. Had I encapsulated the <h2> in <section>, this error would have been suppressed.

Well, how about that? If you’re not convinced, go ahead and paste my example into the test outliner and play around. It works just fine. In fact, it’s really difficult to break.

If you think there is a benefit to screen reader users, you may wish to adhere to the second of the two clauses from the specification and incorporate numbered headings that reflect nesting level. As demonstrated, this will have no effect on the outline, but since heading level (“Heading Level 2 – The Importance Of Sectionsâ€�) is announced, it gives a clearer impression of structure to those who can’t see boxes inside boxes.

The assertation that heading levels are perpetually indispensable to screen reader users comes under pressure when you consider advancements being made by screen reader vendors. Screen readers like JAWS mark the territory of sections more clearly than headings, by announcing the beginnings and ends of sections and the thematic regions they represent (“Article End!â€�). From this perspective, using more than one <h1>s in your document might sometimes be applicable. You’ll come up against some accessibility experts who are keen on their “there can only be one [h1]!â€� mantra, but research shows that even in HTML4 or XHTML, this is not necessarily case.

The approach you choose is yours to make; just employ some common sense and consistency. Bear in mind, though, that not all screen readers are able to announce the bounds of sectioned content. In these cases, there are measures you can take …

ARIA Enhancement

Transition to an HTML5 document structure is made smoother by incorporating some ARIA landmark roles, which are both relatively well supported and somewhat analogous to the section-based navigation we should expect later. ARIA offers many more accessibility-specific features than baseline HTML5 could ever withstand; so, including “bolt-on� ARIA enhancements is certainly polite. However, regarding ARIA roles as a substitute for semantic HTML would be a grave misconception.

Landmark roles, such as role="navigation" and role="banner", address accessibility only — not data mining — and each may be used only once per document. They are essentially shortcuts to parts of the page. HTML elements are more like building blocks, which are used in a repeated and modular fashion. So, while you can assist accessibility by placing role=�banner� into the <header> element closest to the document’s root, this does not preclude you from using <header> to introduce other sections:

Are Sections The New <div>s?

This is a common misconception.

If it wasn’t clear already, it should be clear to you now that <div>s are semantically inert elements — elements that don’t really do or say anything. If this is clear, then it should also be clear that, when building a structured document, relying heavily on “an element of last resortâ€� makes for a very poor foundation.

If the new <section> element, for example, was just <div> with a new name, adopting it would be a straightforward matter of search and replace. It wouldn’t exactly be progress, though. The truth is, <div> still has a rightful place in the spec’; we’ve just given its organizational responsibilities to a team of elements that are better qualified. Sorry, <div>, old mate. What do we use <div>s for, then? Precisely what they were good at from the beginning: as a tool for “stylistic applications… when extant meaningful elements have exhausted their purpose.â€�

For instance, you shouldn’t employ sections as box-model controlling measures like this…

	<section class="outer">
		<section class="inner">
			<h1>Section title</h1>
		</section>
	</section>

… because there’s nothing that the outer section does that the inner section doesn’t. We’ve created two sections for one piece of content. A quick run through our outliner throws the “Untitled Sectionâ€� warning:

• [Untitled Section]
  • Section title

The brilliance of <div> in this context is that it refuses to affect the outline, which is why we can use it without fear of reprisal. This…

	<section>
		<div>
			<h1&gtSection title</h1>
		</div>
	</section> 

… averts disaster and results in this unsullied, if simplistic, outline:

• Section title

Sections And Semantics

A lot of developers have trouble with the word “semantic.â€� You might even say that they don’t know what the word means, which (if you are familiar with the term) makes an interesting paradox. For instance, when Jeffrey Zeldman advocates for the “semanticâ€� application of the id attribute, he’s kind of missing the point. The main purpose of semantic HTML is for the automated extraction of meaning from content. Applying a private, non-standard id to a <div> would not improve the semantics of the element one iota: Visitors can’t see it and parsers will ignore it. So much for the semantic Web!

Sections are often characterized as the “semanticâ€� equivalent of <div>. This is a half-truth at best, and I apologize for throwing the term “semanticâ€� around so much — it’s become a bit of a shorthand. Some HTML elements are inherently semantic in that they prescribe specific meaning to their contents. The <address> element is a good example: When a parser reaches <address>, it knows that the contents should probably be interpreted as contact information. What it chooses to do with this knowledge is another matter, but it’s plausible that a screen reader could provide a shortcut to the address or a search engine could use it to refine its results pages.

Sectioning elements are not so much semantic as syntactic. All <section> tells us is that it is a part of a whole. However, the syntactic contribution of sectioning elements to document structure is not unimportant. Consider the following sentence: If sections you don’t websites your are use obsolete. A lot of recognizable words are in there, but the lack of sensible syntax makes the sentence difficult to unpick. So it is with sectioning: You are not creating meaning so much as assembling it. Meaning isn’t always about the “thing”; it’s sometimes about what that thing’s role is amongst other things.

Microdata

Efficient, syntactically sound data structures are worthless if they are semantically lacking. Fortunately, HTML5 has both angles covered and provides a mechanism for attaching semantic meta data, called “microdata,� to our structured content. Using microdata, and by consulting schema.org, you can define a page’s content as anything from a scholarly article to an exercise regimen. Unlike classes and IDs, this is information that can actually be interpreted usefully.

This microdata was found by Google and displayed in its “Structured Data Dashboard� for the WordPress theme Typical.

Conclusion

HTML isn’t just an SDK or a Graphic Designer’s palette. It is a metalanguage, a language that tells you special information about information. Sometimes we — or, more precisely, the parsers we employ — benefit from added information about the subject, timing, origin or popularity of content. This is what APIs such as microdata and RDFa are for. Other times, the context, hierarchy, relative importance and codependence of the information are what need to be determined. This is where appropriate syntax, facilitated by sectioning elements, can be employed.

Some people will tell you not to bother with sectioning. They say that it’s hard work or that it doesn’t make sense. This is hokum. Sure, if you’re lazy, don’t bother with sectioning, but don’t pretend you’re doing it on principle. Using sections demonstrably enhances HTML structure without breaking accessibility. We’ve covered this.

Still, there will always be people who will attack this aspect of the specification. Perhaps we’ll enjoy some of these objections in the comments:

1. They will point to bad implementations by specific vendors:
   “These are bugs and bugs get fixed!”
2. They will cite the actions of large websites who don’t use sectioning elements:
   “Just because large sites haven’t implemented sections doesn’t mean they wouldn’t like to. Since when does big mean ‘right’ anyway?”
3. They will flood you with examples of developers implementing sections badly:
   “Some developers do stupid things and their misuse of HTML doesn’t stop at sections. I include myself here, by the way.”
4. They will present you with anecdotal evidence about user behavior within specific groups:
   “It is expensive and impractical to address problems on a case-by-case basis. Fragmentation and complexity would also be inevitable: a loss for the majority, not a specific minority, of users.”

I don’t think anyone would advocate making badly structured Web documents any more than they’d suggest building a house by stuffing a bag full of bricks and throwing it into a ravine. The case has been made and the specification bears it out: Sections aren’t just good for document structure — they finally make proper structure attainable. Some browsers and screen readers have some catching up to do, that’s for sure, but the situation is improving rapidly. Any kind of change is a little turbulent, but this kind is worth it.

(al)

© Heydon Pickering for Smashing Magazine, 2013.

In this article, I’d like to reacquaint you with the humble workhorse of communication that is the paragraph. Paragraphs are everywhere. In fact, at the high risk of stating the obvious, you are reading one now. Despite their ubiquity, we frequently neglect their presentation. This is a mistake. Here, we’ll refer to some time-honored typesetting conventions, with an emphasis on readability, and offer guidance on adapting them effectively for devices and screens. We’ll see that the ability to embed fonts with @font-face is not by itself a solution to all of our typographic challenges.

A Web Of Words

In 1992, Tim Berners-Lee circulated a document titled “HTML Tags,� which outlined just 20 tags, many of which are now obsolete or have taken other forms. The first surviving tag to be defined in the document, after the crucial anchor tag, is the paragraph tag. It wasn’t until 1993 that a discussion emerged on the proposed image tag.

Bursting with imagery, motion, interaction and distraction though it is, today’s World Wide Web is still primarily a conduit for textual information. In HTML5, the focus on writing and authorship is more pronounced than ever. It’s evident in the very way that new elements such as article and aside are named. HTML5 asks us to treat the HTML document more as… well, a document.

It’s not just the specifications that are changing, either. Much has been made of permutations to Google’s algorithms, which are beginning to favor better written, more authoritative content (and making work for the growing content strategy industry). Google’s bots are now charged with asking questions like, “Was the article edited well, or does it appear sloppy or hastily produced?� and “Does this article provide a complete or comprehensive description of the topic?,� the sorts of questions one might expect to be posed by an earnest college professor.

This increased support for quality writing, allied with the book-like convenience and tactility of smartphones and tablets, means there has never been a better time for reading online. The remaining task is to make the writing itself a joy to read.

What Is The Perfect Paragraph?

As designers, we are frequently and incorrectly reminded that our job is to “make things pretty.â€� We are indeed designers — not artists — and there is no place for formalism in good design. Web design has a function, and that function is to communicate the message for which the Web page was conceived. The medium is not the message.

Never is this principle more pertinent than when dealing with type, the bread and butter of Web-borne communication. A well-set paragraph of text is not supposed to wow the reader; the wowing should be left to the idea or observation for which the paragraph is a vehicle. In fact, the perfect paragraph is unassuming to the point of near invisibility. That is not to say that the appearance of your text should have no appeal at all. On the contrary: well-balanced, comfortably read typography is a thing of beauty; it’s just not the arresting sort of beauty that might distract you from reading.

(Image: Marcin Wichary)

As a young industry that champions innovation and rates its practitioners based on their ability to apprehend (sorry, “grokâ€�) the continual emergence of new technologies, frameworks, protocols and data models, we are not particularly familiar with tradition. However, the practice of arranging type for optimal pleasure and comfort is a centuries-old discipline. As long ago as 1927, the noted typographer Jan Tschichold spoke of the typesetting “methods and rules upon which it is impossible to improveâ€� — a set of rules it would be foolish to ignore.

So, please put your canvas element and data visualization API to one side just for a short while. We are about to spend a little time brushing up on our typesetting skills. It’s called “hypertext,â€� after all.

Setting Your Paragraphs

The Typeface

Your choice of font is important, but the kind of “family� you choose is project-specific, and we won’t discuss it here except to make one point: the conventional wisdom among Web designers that only sans-serif fonts are suitable for body text is just a rule of thumb. Although serif fonts, with their greater complexity, may tend to be less effective at small sizes, there are many other factors to consider. A diminutive x-height, for example, could impair the readability of a font from either camp. Some serif fonts are highly legible and attractive for paragraph text if they are set properly. Matthew Carter’s screen-sympathetic Georgia is a case in point.

X-height is the distance between the baseline and midline — a measure of lowercase character height. (Image: adactio)

Having dispensed with the subject of preference, let’s cover some important technical issues relating to one’s choice of typeface.

The first thing to consider when choosing a Web font (read: @font-face font) is the breadth of the family. Does the font include all of the necessary bold, italic (or even better, semi-bold and bold-italic) styles? One style is fine for headings, but paragraphs need greater variety. Without these variations at your disposal, not only will your text look insipid, but the lack of proper emphasis will make your writing difficult to follow.

I personally don’t like Bitstream, but it is fully functional for paragraph text

With the full gamut of stylistic variations at your disposal, you will not have to rely on the unsatisfactory “fauxâ€� styles that are applied to a regular font when font-style: italic or font-weight: bold is called. Typefaces are not designed to be contorted in this way. Using the proper styles provided by a family like Bitstream (above) will make your typography not only more attractive but more accessible: dedicated italic glyphs have a much clearer intent than text that is simply “leaned over a bit.â€�

The trick is to make sure that the declaration of, for example, font-style: italic requests the italic resource rather than triggers the faux style. It should be as effortless as using a system font family such as Georgia. This is probably best explained, like so many things, in commented code. For brevity, we’ll set up just a regular font and an italic (not bold) style variation.

@font-face {
   font-family: 'MyWebfont';  /* Change this to whatever you like. */
   src: url('mywebfont-regular.ttf') format('truetype');  /* The "regular" font resource. */
   font-style: normal;  /* Associates values of "normal" with this resource. */
   font-weight: normal;  /* As above for weight. */
}

@font-face {
   font-family: 'MyWebfont';  /* Importantly, the same as in the above block; the family name. */
   src: url('mywebfont-italic.ttf') format('truetype');
   font-style: italic;  /* Associates values of "italic" with this resource. */
   font-weight: normal;  /* ... It's not a bold-italic font style. */
}

body {
   font-family:'MyWebfont', georgia, serif;  /* Provides a system font fallback. */
}

em {
   font-style: italic;  /* If @font-face is supported, the italic Web font is used. If not, the italic Georgia style is lifted from the user's computer. Either way, a faux style is not allowed to creep in. */
}

Our second typeface consideration relates to rendering. Some fonts, replete with beautiful glyphs and exceptional kerning as they may be, simply don’t render very well at small sizes. You will have noticed that embedded fonts are often reserved for headings, while system fonts (such as Verdana here) are relied on for body text.

One of the advantages of Verdana is that it is a “well-hinted� font. Delta hinting is the provision of information within a font that specifically enhances the way it renders at small sizes on screen. The smaller the font, the fewer the pixels that make up individual glyphs, requiring intelligent reconfiguration to keep the font legible. It’s an art that should be familiar to any Web designer who’s ever tried to make tiny icons comprehensible.

Hinting is a tricky and time-consuming process, and not many Web fonts are hinted comprehensively. Note the congealed upper portion of the bowl in the lowercase “b� in the otherwise impressive Crimson font, for instance. This small unfortunate glitch is distracting and slightly detracts from a comfortable reading experience. The effect is illustrated below and can be seen in context as a demo.

Slightly unsatisfactory hinting for the Crimson Roman style. I love Crimson all the same.

The good news is that, as font embedding becomes more commonplace, font designers are increasingly taking care of rendering and are supplying ever better hinting instructions. Typekit itself has even intervened by manually re-hinting popular fonts such as Museo. Your best bet is to view on-page demonstrations of the fonts you are considering, to see how well they turn out. Save time by avoiding, sight unseen, any fonts with the words “thin� or “narrow� in their names.

Font Size and Measure

As a recent Smashing Magazine article compellingly attests, you put serious pressure on readability by venturing below a 16-pixel font size for paragraph text. All popular browsers render text at 16 pixels by default. This is a good enough indication (given the notorious tendency among browser makers to disagree) that 16 pixels is a clear standard. What’s more, the standard is given credence by an equivalent convention in print typography, as the article points out.

We often express 16px as 100% in the declaration block for the body in our CSS reset style sheets. This makes perfect sense, because it is like saying, “100% the same as the browser would have chosen for you.â€� If you want the paragraph text to be bigger than 16 pixels, just edit this value in the body block using a percentage value that equates to a “whole pixel.â€� Why whole pixels? Two reasons. First, whole numbers are less ungainly and are easier to use as multipliers in style sheets. Secondly, browsers tend to round “sub-pixelâ€� values differently, giving inconsistent results. An 18-pixel font size expressed as a percentage is 112.5% (1.125 × 16).

Normalizing the size of default text (or “paragraph text,â€� if you’re being good and semantic) in such a way is extremely important because it sets us up to use ems as a multiplier for the size of surrounding headings and other textual elements. For instance, to render an h3 heading at 1.5 times the font size of the paragraph, we should give it the value of 1.5em. Because ems (pronounced as in “Emma,â€� not E.M. Forster) are relative units, they change according to the default font size. This makes it much easier to maintain style sheets and, more pertinently, ensures that the perceived importance of headings is not increased or diminished by adjusting the size of the paragraph text.

The “measureâ€� is the number of characters in a line of text. Choosing a comfortable measure is important for usability, because if lines are too long, then scanning back to find the start of the next line can be awkward. Without conscious effort, the reader might miss or reread lines. In The Elements of Typographic Style, Robert Bringhurst puts a good measure at somewhere between 45 and 75 characters. It is the main reason why we use the max-width property when designing elastic layouts.

Whatever your page’s ideal maximum width, it is likely much narrower than what you are used to seeing. According to an in-depth study of typographic design patterns published on Smashing Magazine, the average website exhibits a measure of 88.74 characters, far exceeding the optimal range.

Leading and Vertical Rhythm

(Image: andrechinn)

Leading (pronounced “ledding�) is the spacing between consecutive lines of text. Leading has a similar impact on readability as “measure,� because it helps to define and demarcate the rows of glyphs that one must traverse from left to right and back again. The trick with leading is to avoid adding too much: text with lines that are too far apart appears fragmented, and the intent of a judicious use of leading is undone by a negative result.

In mechanical typesetting, leading was set by inserting strips of lead metal (hence the pronunciation) between lines. In CSS, the line-height property is the tool we use, and exposure to it is much less likely to make you go mad.

Instead of accounting for space between lines, as with leading, line-height is a vertical measure of the whole line — including the text itself and any spacing to follow. There are three ways to set it: the wrong way, the redundant way and the right way.

The wrong way to set line-height is in pixels. By introducing an absolute value, we would undo all of the good work from the previous section. As the font-size increases (either in the style sheet or the user’s browser settings), the line-height would persist. This produces an interesting effect:

Absolute and relative values do not mix.

So, should we use the same em multipliers that we saw in the last section? This is the redundant way. Although the method would work, providing an em unit is not necessary. Rather, a value of 1.5 for the line-height that is 1.5 times that of the font size will suffice. The line-height property belongs to an exclusive club of CSS properties that accept unit-less numeric values.

p {
   font-size:; /* Silence is golden; implicity 1em. */
   line-height: 1.5;
}

The attentive among you will have noticed that so far I have only mentioned font sizes that are even numbers. The reason is that I favor a line height of 1.5. So, a font size of 18 pixels means lines with a height of 27 pixels or, if you prefer, lead strips that are 9 pixels thick. Using even numbers is another bid to maintain whole pixel values — I know that any even number multiplied by 1.5 will result in a whole number. A line-height stated in whole pixels is particularly important, because it is the key value used to achieve “vertical rhythm.â€�

All components on the page should have a height divisible by the height of one line of paragraph text.

Maintaining vertical rhythm (or composing to a baseline grid) is the practice of making sure that the height of each textual element on the page (including lists, headings and block quotes) is divisible by a common number. This common number (the single beat in a series of musical bars, if you will) is typically derived from the height of one paragraph line. You should be able to see by now why an impossible value like 26.5 pixels would be a mistake for such an integral measure.

The benefits of vertical rhythm to readability are much subtler than those of hinting, measure or leading, but they are still important. Vertical rhythm gives the page decorum. Because we have made sure so far that all of our measurements are co-dependent and relative, altering the font size for the body (all the way up at the top of the cascade) will not damage the page’s vertical rhythm.

It is worth noting that, although a line height of 1.5 is fairly dependable, not all fonts are made equal. Fonts with a tall x-height or long descenders might benefit from more generous, separative leading. When basic readability is at stake, adopting a more complex vertical rhythm algorithm is worth it.

Word Spacing and Justification

Without intervention, paragraph text on Web pages is set “ragged rightâ€� (text-align: left in CSS): the start of each line is flush with the left margin, but the lengths of the lines vary, giving an uneven “raggedâ€� effect on the right side. If you’re like me, you prefer the tidiness of full justification (illustrated below). But implementing justification without impairing readability is not as straightforward in HTML as it is by using desktop-publishing software.

Fully justified text necessitates, arguably, a narrower measure than text set ragged right.

The problem with justified text in HTML (text-align: justify) is word spacing. In print media (such as newspapers), hyphenation is used to break up long words. This results in more components (words or part words) per line, thus improving distribution and curbing aggressive word spacing. Browsers do not hyphenate automatically, and the soft hyphen (­) is implemented inconsistently. Besides, imagine having to manually insert ­ all the way through your copy. CSS3’s text-justify property, which aims to give us more control over text-align: justify, could ease the problem by enabling inter-character distribution. Bizarrely, it is currently available only with Internet Explorer.

Hyphenator.js

Thankfully, Firefox and Safari now support the CSS3 property hyphens, which can automatically insert hyphens much as you would manually with ­. In fact, you can revert to manual hyphenation in a document set to hyphens: auto by using the hyphens: manual override. Browser prefixes are required, but Lea Verou can help you with that.

Until the other browsers catch up, a consistent cross-browser solution is currently possible only with JavaScript. Hyphenator.js is a powerful tool that takes a library of syllabic patterns specific to each language and uses them to dynamically insert soft hyphens in the correct places. It is a bit pricey (two scripts at a total of 72 KB uncompressed just for the English implementation), but it does work. Its effect is shown in the first screenshot for this section.

Finishing Touches (Styling Contextually)

Now that we have dealt with the important business of sizing, setting and distributing our paragraphs compellingly, you may wish to apply a few small enhancements and decorations for the purpose of signposting the document. These nuances concern only certain paragraphs, and choosing which paragraphs to set off is a question of context. With the help of special selectors and combinators, we are able to target specific paragraphs depending on where they appear on the page, making sure that the difference in their design is consistent with their intended role and meaning.

Paragraphs separated with a margin (such as margin: 0 0 1.5em;) do not require indentation. With paragraphs, margins and indentation serve the same purpose.

Let’s use indentation as an introductory example. Although less common in Web typography than in print, indenting the first line of each paragraph is a conventional method of grouping paragraphs into chunks of information. In terms of rhythm, it is also a sort of punctuation: the reader is invited to pause briefly before each paragraph. Because no indentation is required for the first paragraph — why pause before we’ve even started? — we should exclude this paragraph from our CSS rule. Using the adjacent sibling combinator, we are able to target only paragraphs with a preceding paragraph, and so the convention that has been familiar to book typography over the centuries is ably reproduced.

p + p {
   text-indent: 1.5em  /* I like to keep the indentation length equal to the line height. */
}

In the next example, I have combined the adjacent sibling combinator with the :first-letter pseudo-class to create a pronounced introductory glyph or “elevated capâ€�:

h1 + p:first-letter {
   font-size: 2em;
   line-height: 0;  /* The line-height must be adjusted to compensate for the increased font size, otherwise the leading for the overall line is disrupted. I find that any values below 0.4 work. */
}

The beauty of adding these refinements (many more of which are demonstrated by Jon Tan, including “drop capsâ€� and “outdentsâ€�) contextually is that they are activated only when semantically meaningful and appropriate. For instance, our :first-letter style above is appropriate only for introductory copy. Because the introductory paragraph is always (in this particular schema) preceded by an h1 heading, we have a way to bind its style to its particular role in the document’s flow. In other words, we can honor its meaning through its design.

As long as we rigorously adhere to semantic HTML, we can employ many nuances that are impervious to both the rearrangement of the page itself and the introduction of dynamic content.

Conclusion

(Image: primatage)

Walking down an aisle in a library, I no more than glance at the vast majority of books shelved on either side of me. Only a madman would suggest that my disregard of these books should sanction their pages being torn out. Nonetheless, because research has shown that visitors don’t read the average Web page in full, and because the “success� of a page is more easily measured by user action than cognition, we are often encouraged to marginalize our writing in favor of visual signifiers or action cues.

Sure, most people will “bounce� your content, but if you really have something to say, don’t alienate the people who are willing to give your writing a chance. Good typography does justice to your words, and good wording does justice to your ideas. If readers are comfortable reading your type, then they will more likely be comfortable with what you are writing about.

© Heydon Pickering for Smashing Magazine, 2011.