Skip to content

WebPatterns and WebSemantics

WebSemantics 1.0

Over the last few years, we’ve seen a growing awareness of the importance of semantics in HTML. Perhaps Dan Cederholm’s rightly lauded Simplequiz was the coming of age of this idea, which while there at the very beginning of HTML, had been overlooked for a long time by the great majority of web developers. We could consider this “first generation semantics” or, in current parlance “WebSemantics 1.0”.

But it’s clear that the semantic expressiveness of HTML, even with HTML compounds is reasonably limited. And developers are voting with their feet, using class and id to create their own ad hoc semantics for HTML.

Even XHTML 2, while somewhat more semantically rich than the current generation of XHTML/HTML, will fall far short of the semantic complexity which developers are currently cooking up, or which is found in even the first generation of microformats (and who knows what we might see from microformats.org in the next year or two).

So, it seems that developers want/need the semantic richness that is only available through the use of class and id values in HTML/XHTML. My recent semi-random survey of around 1300 sites, found well over 5000 distinct class values, and almost 5000 distinct id values, which surely demonstrates that this is something developers are doing in significant numbers.

It’s also something that has been talked about for some time by the likes of Tantek Çelik and Andy Clark (and of course many others).

But my recent survey also showed that there is very little consistency in the use of class and id values – no conventions, no accepted set of values, and so none of the potential benefits which might flow from that.


In the comments which followed that post, the overwhelming consensus was that some kind of standardization would be a good thing. This echoes my conversations with developers, some very well known, many in the trenches, in organizations big and small, on this issue over the last year or so.

The temptation is (as evidenced by a number of comments), that having identified the need for some kind of standardized class and id values, we should roll up the sleeves, jump in, and start a convention, any convention, before its too late.

But standardized (or “conventionalized”, it’s not necessary that this be some kind of formal standard or W3C recommendation) class and id values will only be adopted if they clearly meet the needs of developers. It’s also worth noting that we don’t need a “big bang” approach – we don’t need to agree on every possible semantic value for class or id at once. But given how long it takes to develop standards, like XHTML2 and CSS3, how on earth could this be done in a reasonable amount of time, in an unstructured way?

Let’s start by trying to understand the problem well, before rushing to an implementation (in my experience, that’s the cause of a lot of bad decisions and bad solutions).

What’s the problem?

As I am fond of asking, “what is the problem”?
When developers use class and id values, what problem are they trying to solve?

One of a couple of things.

Often, developers are creating hooks for styling with CSS. “Classitis”, aka “divitis” is a common malady on the web, as we all know. But when developers are using class and id in a more structural or semantic way, what are they trying to achieve? Commonly, developers use id and class to identify structural, or architectural components of a page. For example, the most common id and class values in my survey were things like header, footer, content and navigation.

I used the term “architectural” deliberately, because originating in the field of architecture (as in buildings), and having taken strong hold in many areas of computer science (object oriented analysis and design, Human Computer Interfaces, and more) is the idea of patterns, and pattern languages.

What I think web developers are doing instinctively is using patterns in web page and web site architecture. A small number of people, most notably Martijn van Welie have done work on patterns and web design, but it’s a surprisingly under-researched area, given how powerful and valuable a patterns approach to web development could be.

So what are patterns?

But hang on, what are “patterns”?

On the web you’ll find a considerable amount of information about patterns and pattern languages, in architecture, computer science, and other fields. I’ve got some links to resources at the end of this post, but here are just a few introductory notes.

In 1977, Christopher Alexander, Sara Ishikawa and Murray Silverstein published “A Pattern Language“, which formalized their pattern based approach to architecture.

In a nutshell, a pattern describes a problem which occurs over and over again … and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice (my emphasis).

The essence of a pattern is that it articulates a problem, then considers how that problem might be solved.It does not dictate a single solution, rather, a strategy for solving the problem.

The idea has been taken up in a number of computer related fields, most famously in object oriented analysis and design, the seminal work there being Design Patterns Elements of Reusable Object-Oriented Software, by “the gang of four” – Gamma, Helm, Johnson and Vlissides. In this context, Brad Appleton observed, Fundamental to any science or engineering discipline is a common vocabulary for expressing its concepts, and a language for relating them together.
This really struck a chord with me. Can web design and development today rightly be called a discipline? Or is it, as I suspect, a practice in the process of becoming a discipline. If we consider Appleton’s observation, do we have a
common vocabulary for expressing [our] concepts, and a language for relating them together
 ? We certainly have technologies like HTML and CSS (though we still struggle to even use the terms “tag”, “attribute” and “element” correctly – I’m still hearing “alt tag” frequently in my travels). But what about higher order, more complex structures and strategies? What do we call the parts of a page we use over and over again? What names do we have for particular navigation strategies (such as hierarchical trees, linear progressions through sections, and so on)? My survey, as well as a more detailed, though much more narrowly focussed one by François Briatte suggest that while it’s clear that there are many structures we use over and over again, we lack that common vocabulary to talk about these structures, and to relate them to one another.

In short, we lack a pattern language for the web.

But is our discipline mature enough to develop this vocabulary and language? Only trying to do just that will tell.

If we return to the issue which began this post, of id and class values, how does that relate to the issue of patterns? Earlier I asked – when developers use class and id values, what problem are they trying to solve?
 .
My answer is that we are struggling to find a vocabulary to talk about these common constructs and concepts.
But before we quickly run out and invent a vocabulary, let’s stop for a moment and think about what these patterns are. Not all of them right away, just the most common ones. I think this could help us determine what id and class values, what kinds of HTML element, and so on, to use when translating these patterns into HTML.

But how to go about this?

A couple of years back, Dan Cederholm published his very popular and helpful “SimpleQuiz“. This sought to understand best semantic coding practices by asking developers what they thought the most semantic way of marking up various commonly used constructs were. In fact what Dan was doing was trying to understand patterns, particularly as they are implemented using semantic HTML, constructs like headings, lists, linking, and paragraphs. SimpleQuiz even touched on some patterns which go beyond straight HTML, such as how to markup a page header. But (and this is not a criticism) SimpleQuiz took the patterns for granted, and looked for solutions, while I’m interested in discovering and cataloguing the patterns developers currently use themselves. How these patterns are implemented is an issue for subsequent investigation and discussion.

Over the coming weeks, I’ll be running (with Dan Cederholm’s blessing) “PatternQuiz”. The goal is to begin collectively understanding, naming and cataloguing the patterns which have already emerged in web development, and which we all use commonly. In Appleton’s terms, to develop a “common vocabulary for expressing its concepts, and a language for relating them together”. Or in Alexander’s terms a pattern language for the web. Once the conversation is flowing, I hope it can be formalized in a wiki, which I am setting up at WebPatterns.org, a site I’ve established to promote the use of patterns in web development, similar in some way to Microformats.org

What makes a good pattern?

Others have done a lot of work in the area of patterns in many different fields over a long period of time. It’s important to stand on their shoulders, rather than having to relearn from scratch the lessons they have learned.

James Coplien (often referred to as “Cope”), has this observation about what makes a good pattern, which might help think about webpatterns. A good pattern, says Cope,

  • solves a problem: Patterns capture solutions, not just abstract principles or strategies.

  • is a proven concept: Patterns capture solutions with a track record, not theories or speculation.

  • describes a relationship: Patterns don’t just describe modules, but describe deeper system structures and mechanisms.

  • The pattern has a significant human component …. All software serves human comfort or quality of life; the best patterns explicitly appeal to aesthetics and utility.

Who are patterns for?

Cope’s final point is one particularly worth emphasizing. The purpose of identifying patterns is to use them in our work as designers, information architects, and so on. But why should we go to all that effort? Who benefits if we do so?

Usually, the focus is on the benefits of patterns for the developers who use them. Now using patterns certainly has its benefits for developers – it helps solve complex design problems in better ways, more efficiently, while avoiding potential pitfalls, based on our own and others’ previous work. Patterns help to facilitate larger development teams, which will become more common as the practice of designing and developing for the web continues to mature, by providing a common vocabulary and language to aid communication. They help site maintenance, where page and site logic and structure are much clearer when captured explicitly as a pattern. Compare reading the HTML for a WordPress (or other) blog with an identical looking table based design (such as a Geeklog page). While the patterns used in each are very similar, in a standards based, semantically marked up page they are explicit, making the code much more readable and maintainable.

But, there is another significant, often overlooked group who would benefit from a pattern based approach to web development – users. Users are often overlooked when it comes to patterns, perhaps because the most common and well developed work in patterns is in the area of object oriented analysis and design. Using design patterns in this field produces good outcomes for users, but users don’t see or interact directly with the patterns which OO designers develop. These patterns lie behind the scenes, in the code.

But in web development, users benefit from the consistency, the learnability, the familiarity which comes from using patterns. Take blogs. When you visit a blog you can generally readily, without much conscious thought, work out how to get to the main page, how to contact the writer, how to leave a comment, all because the patterns in blogging are so well established. This is true regardless of whether the site is developed using Moveable Type, Blogger, WordPress or by hand. This is not nearly so true for many other common types of site. In part that’s due to their greater complexity of many kinds of site – a newspaper site has possibly dozens of sections, and, many many different kinds of content, as compared with a blog’s much more limited set of patterns. But in part it’s true because there are very strong patterns in common use by blogging tool developers and bloggers.

This doesn’t mean users will be consciously aware of the patterns which comprise a site they are visiting, or even that all of those patterns are directly accessible to the user. But patterns in web development benefit not only developers, but also site visitors, maybe even more so.

There’s a final entity for whom a pattern language, and the standardization of semantics, could bring significant benefits – machines. Today, software discovery of information on the web is largely limited to plain text indexing, and very simple metadata like tags (as in technorati, not bold), and some other microformats like XFN, hCard and hCalendar. Imagine the kinds of data mining possible if much more of the content of the web was marked up in a semantically rich, standardized way. Understanding and cataloguing the current patterns in web development is an important first step in the development of robust, rich standardized semantics, for today’s web, using todays technology, without waiting for The Semantic Web.

What can you do right now?

Think about patterns

Start thinking about patterns in your work, and in the sites you visit. Particularly start thinking about types of pattern. Immediately the following come to mind

  • different types of site – e.g. blogs, newspaper sites, search engines

  • different navigation strategies, like hierarchical trees, linear paths, or indexes

  • different kinds of pages within sites – front page, contact page, search page

  • different navigational page sub parts (like, site level navigation, site subsection navigation, page level navigation)

  • different page content sub parts – main text, pullout quotes, “side bars” and so on

and of course many many others. The fun part is finding them.

Notice I haven’t talked about things in terms of appearance. I think a basic rule is to avoid any kind of presentational name to begin with (although header and footer are so commonly used that it would be perhaps counter productive to not continue using those terms).

Overall, looking at the list above, there seems to be a number of different categories of pattern. A number of the above patterns relate to page architecture. But that’s not the case for sites, or for navigation strategies.
As this work continues, I imagine several categories of web pattern will emerge and become clearer.


It’s important to note that patterns aren’t just restricted to pages and parts of pages. A site, for instance, is an open collection of pages, while a navigation strategy (or mode, or whatever we might call that kind of pattern) is even more ephemeral – it’s a concept which the designer creates in the mind of the user by the use of other architectural patterns, like breadcrumb trails, tables of contents, next and previous links and so on. This is an example of the powerful concept of generative patterns, patterns which work together to build more complex patterns. It’s this which makes a collection of patterns a language, rather than simply a catalogue.

When thinking about patterns, here are some ideas of things to think about

  • What name should we call the pattern? Do good names already exist for the pattern (perhaps from outside the web)

  • What is the problem which the pattern captures?

  • What solutions exist which attempt to address the problem? Remember Cope’s observation that a pattern is a proven concept, not speculation.

  • How might you implement the solution (what concrete examples of the solution can you think of)?

  • What other patterns work with this pattern? What patterns does it play a part in? What other patterns form a part of it?

  • What category of pattern does it belong to?

What’s next?

As mentioned, I’ll very soon start my PatternQuiz, so subscribe to the RSS feed for this site, and get ready for that quiz. Soon too, the WebPattern Wiki should be up at webpatterns.org. In time I hope that can become a collaborative catalogue of patterns for the web.

Footnote: Martijn van Welie’s Web Design Patterns

It’s very important for me to acknowledge the work that Martijn van Welie has done in this area, which in my experience is the most significant in the field. Martijn’s site catalogues dozens of patterns, with several categories of pattern, including site types, navigation, page parts, page types and more. He also includes visual design patterns, such as liquid layout and alternating row colours, and interaction patterns, like stepping and wizard.

So, if Martijn has done all this work, why am I proposing to essentially start it all over again? While Martijn’s work is significant, it is not without some significant shortcomings.

  • It is the work of an individual. As such it will always be to an extent idiosyncratic, and limited by the amount of work an individual can do. Even a moment’s reflection will show that the number of patterns which have already emerged in web development is simply enormous. No individual can catalogue all these. The WebPatterns project I will outline in more detail shortly, aims to harness the collective knowledge and experience of many many web developers (in effect, anyone who cares to be involved).

  • It lacks a systematic structure. Each category of pattern, and in turn, each individual pattern is isolated. For example there is a category, “Page Elements”, and yet other categories, such as “Navigation” contain page elements as well. My sense is that web patterns probably have both a hierarchical nature (so Navigation elements would be a subset of Page elements), and a compositional nature – patterns both comprise other patterns, and help make up larger patterns. This aspect of the relationship between patterns is strongly emphasized in most major pattern work, particularly that of Alexander et. al. and the Gang of Four.

  • Closely related to this is the idea that a pattern language should be generative, that is, taking a particular pattern within the language as a starting point, related patterns are explicitly referred to by the language itself, helping to identify more complex solutions more efficiently. Because van Welie’s work lacks a strong structure, and explicitly articulated relationships, it is much less generative than other pattern languages.

Martijn himself identifies the importance of these second and third aspects in Generative Pattern Languages for Interaction Design [PDF] where he writes


When Alexander wrote his book on architecture design patterns, it did not just contain patterns; the patterns formed a language. His language was hierarchical and started out on the level of cities, then neighborhoods, houses until the level of windows or seats was reached. In Alexander’s idea, the language actually “generated” the design by traversing from high level patterns to the lowest level of patterns. From the design of cities down to the design of window seats, a hierarchy of scale.

I hope Martijn’s detailed understanding of web patterns specifically, and expertise in pattern languages more generally will play the important role they should in the further development of our understanding of webpatterns.

Technorati Tags


I’ve taken the liberty of coining two as yet unused technorati tags for this post – webpatterns and websemantics. While the tags Semantics and Pattern are both reasonably well used (with a little over 100 and 1000 results on Technorati respectively) they are each applied to many completely unrelated concepts, and so I suggest these more specialized tag is warranted to help facilitate finding posts specifically about these issues.