XHTML Design Patterns
The key concept that underlies the modern web is the separation of presentation and structure, and recently, there has been a lot of interest in documenting the synthesis of human friendly and semantically rich approaches to web design. My first thoughts on the subject of design patterns for XHTML were quite confused, mainly because I was focusing too much on the specifics of actual identifiers and attribute syntax. I have come to understand that in XHTML, design patterns actually apply at a higher level.
Taking the generalization of what a design pattern is from Alexander, and the GoF, we have: “a solution to a problem in context”. So, in documenting design patterns, we need to think first about the problem to solve, and the context in which it arises. An important focus is not attempting to solve each new problem from first principles, but rather, reuse a solution that has already proven successful.
Some of the common problems that XHTML design patterns have to solve are:
- Providing reusable blocks for commonly used structures. Time and time again, designers and authors face the situation of adding common design idioms to their markup structure, and it becomes frustrating and time consuming to have to reinvent custom markup for each specific case. Examples of such common structures are citations and quotes, contact details, drop down menu lists, search results, blog entries, related links lists, and so-forth. The need for such structures leads to an increasing importance for designers to find ways to make particular blocks of markup reusable, both in the context of an individual site, and across multiple sites.
- Allowing designers to have precise control over typographic and visual formatting of granular information, while not compromising the information with presentation specific attributes. CSS is only half of the story here; vanilla HTML is often difficult to style directly without the addition of wrappers and attribute hooks for adding style properties such as background icons and alternating colour schemes. In a perfect world, CSS would provide powerful enough selectors to apply this formatting to even the most stripped down markup, but in practice, legacy browser support leads to a requirement for many sites not to go too far beyond CSS Level 1, which places more emphasis on the markup being rich enough to apply suitable styles.
- Expressing page content with visible metadata. Providing useful metadata on web pages is an important problem where the traditional solution of meta tags has not been overly successful. Making metadata visible enables websites to describe their content much more directly, and is of huge benefit to search engine friendlyness as well as human readability.
These concerns are by no means an exhaustive summary of the problems faced by web authors and designers, but do give a good indication of the particular context in which the concept of design patterns can apply to XHTML. Rather than thinking of the patterns as being specific usage of XHTML elements and attributes themselves, I’m starting to see them more as ways to organize and document a general approach to finding reusable solutions.
The most prominent examples of these kind of patterns are Microformats – building blocks for semantic metadata in XHTML that emphasise community process as the key ingredient in maturing successful standards for decentralized communication over the web. From the patterns perspective, there are two important principles of design patterns that Microformats follow:
- They exist to solve a specific problem in a way that is generalized, but not directly prescribed. Just as no two implementations of a pattern will ever be exactly the same, Microformats such as hCard and hReview can be transposed on top of any combination of HTML elements.
- They are focused on modularity and reusability. Microformats are inter-related and support one-another, often sharing the same basic building blocks. Again, hCard is probably the best example of this modularity – individual contact attributes can be embedded directly in hCalendar and hReview.
Strictly, where Microformats differ from design patterns is that they are documented standards, defined normatively, rather than described as an abstract solution to a problem. But because they do share so much with the classic view of design patterns, they form a significant aspect of understanding emerging patterns in XHTML semantics.
The other significant aspect is XHTML Compounds – a way to describe reusable structures of basic XHTML elements. Where Microformats provide shared standards for a general context of interoperability, XHTML compounds provide a way to apply reusable structures to a precise design context. The basic idea is that any two or more XHTML elements can be combined to form a reusable semantic compound, and there are a great many possibilities here, some well explored, some yet to be invented/discovered.
An important point to note, is that XHTML compounds are not dependent on class attributes to be semantic. Simply combining standard element tags in a reusable way is often good enough. Classes are only needed to communicate more structured specifics, and using the basic elements of written language properly is the most important aspect of XHTML semantics, though it is often overlooked. To look at a specific example:
In this case, the first example is more semantic and preferable to reuse, because it communicates the intent of the content in a more concise and simple way: “A list of related links” as opposed to “A block of related links, containing related links”. This might seem trivial or contrived, but approaches like this second example are surprisingly common, especially among designers who have gone through a transition from table based layouts to pure CSS layouts. It’s surely tempting to add a new class wherever you need a new visual style, but this use of classes isn’t really much better than table based design – it’s still totally skewed towards presentation specific usage.
It’s not just designers making this mistake though. Many coders seem to be developing a habit of using extensive custom classes to define specific page elements. While not presentation specific, this markup suffers from the problem of rewriting the meaning of written HTML, which makes it far less semantic than is commonly thought. In context, a heading tag can say just as much as content marked up with attributes like class=”title” – and it also reflects the basic structure of human writing, which a may not.
In practice, designers, authors, and coders will need to find a balance between the restrictions and expressive possibilities of basic XHTML elements, and the further meaningful possibilities of structured class names. Further documentation of the relationship of XHTML compounds to design patterns will hopefully make this balance easier to reach.