Separation of Concerns: The Importance of Structural Layout

I admit, I have been talking quite a lot about the Separation of Concerns principle -- in fact, this is the fourth post I've made about the topic (abbreviated SoC from this point on).The fact of the matter is that the issue needs to be addressed to its fullest extent, as the greater concept of web standards gains increasing importance on the web (many supporters of this claim exist; Microsoft is one of them).

In previous posts, I have talked about SoC in a historical context, the limitations of CSS, and the need to overlap the concern of dynamic presentation with JavaScript and CSS. In this post, we first address the concerns of "content" and "layout." We then distinguish between "structural" and "positional" layout, and elaborate on the tremenduous importance of the former as a first step in web design (search engine optimization, anyone?).

What is content, structural layout, and positional layout?

The web page visitor's goal can be distilled to one simple desire: to get certain information. Therefore, we define the content of a web page here as this specific collection of information.

Layout is defined here as the arrangement of web page content. We further break apart "layout" into two categories: "structural layout" and "positional layout." The former represents how certain parts of the content are related to other parts. For example, we may have a header title <h2>, followed by a paragraph <p>, inside a container <div>. This kind of structural layout specifies that the "paragraph" content is elaborating on the "header title" content.

Positional layout, on the other hand, is concerned with the visual representation of the content. In other words, it tells the browser how to position the content in the browser, and thus how it should be displayed to the user. For example, we probably want the header title to be placed above the paragraph that it relates to, and we want a gap between the header title and the paragraph, and we may even want the paragraph to be indented a little to the right.

Structural and positional layout: why do we need both?

So why would we even need to have positional layout? Doesn't a header title always go before a paragraph? Well, yes. It's true, we don't really "need" positional layout. Maybe it's because we want the web pages we visit to look pretty. Or maybe companies decided that we needed consistent brand exposure, and they needed to differentiate their brand image from their competitors. Whatever the reason, positional layout has become a requirement in designing a website, and there's no way around this.

With the advent of CSS2 and the flexibility of CSS-P, anything became possible. In embracing this capability, some web designers completely dismissed "oldschool" HTML elements such as header (<h1> to <h6>), list (<ol>, <ul>, and <dl>), and paragraph <p> tags in favour of <div> or <span> tags. Arguably, this makes things easier as the <div> and <span> tags have no pre-defined styles, so they're much easier to work with. We are also delegating the "layout" concern almost exclusively to the CSS, thus following the SoC principle as closely as possible. This is a good thing, isn't it? Let's have a look at an example.

Figure 1 demonstrates that both methodologies yield very similar, if not identical, results (additional CSS styles were defined for the <div> tags in column 1). So why not keep the HTML as simple as possible, and go with option 1? Actually, this is a potentially disastrous way of building a web page. Although a web page visitor may see the blocks of content positioned in a meaningful way (assuming they have an up-to-date browser), web crawler bots only see disjointed and semantically meaningless blocks of text. The result: your content-layout separated page is seen by no one, because the search engine ends up ranking it very low (due to the lack of structural layout).

Structural layout for machines, positional layout for humans

Basically, the web designer should be designing for search bots first and visitors second, since a visually perfect website is useless if no one ever sees it. Let's briefly go through the steps we should follow to avoid falling into this trap.

Start with structural layout first. This involves building an HTML page with more than just the use of <div> and <span> tags. Common sense is your best guide -- using <p> tags for paragraphs is an example of this. Lists (<ul> or <ol>) are suitable for site menus (note that you can have nested lists; here's a good tutorial). And if there's tabular data to display, use <table>, <tr>, and <td> tags to display it. Search engines seem to pay attention to header tags, so be sure to use these for the important bits. However, it's considered bad practice to have more than one <h1> tag per page, or to skip header levels (e.g. have an <h1> and an <h3> without an <h2> in between).

Only after the structural layout of the HTML page is completed should you start defining the positional layout. Usually, relative positioning will be sufficient, as the HTML page will typically have data arranged in the same order that the designer wants to display it on the page. Layering CSS definitions on top of a semantically-rich HTML page is an example of progressive enhancement, the successor to graceful degradation (a past web design methodology).

The SoC is dead. Long live the SoC

We have seen yet another possible compromise of the SoC principle here. Just as the term "presentation" is too vague to delegate to one language, so is the term "layout." This is why we defined "structural" and "positional" layout here. However, unlike "dynamic presentation," both "structural layout" and "positional layout" are delegated exclusively to one language each (HTML and CSS respectively). Not only have we managed to successfully apply the SoC principle to the "layout" concern, we were able to show the immense importance of an HTML file with rich structural layout defined. Figure 2 summarizes this conclusion.