Building a better web: The bare necessities

Monopoly - WP

I need a CMS. To my mind, my expectations are simple, obvious. Give me content I can reuse — including between sites — that can be styled based on its context of use. Give me structure and patterns. Let me manage my content according to the paradigms that make sense to me. Is there nothing available?


I have worked with the web since it became available to the general public; the days of 14.4k modems that came with a half dozen dial-up trials. I’ve seen many things come, and almost as many go. I’ve despaired at many of the comings; likewise at some of the goings.

Of the many and varied web presences I’ve designed and maintained, my own have generally been short-lived — a consequence of manual maintenance.

No fit CMS

Why would I maintain a site manually? I could choose one of those easy-install web publishing/blogging tools — whether on my server or hosted — and have a working site in minutes, with enough themes, plugins, and so forth to keep anyone happy for years.

I do not consider easy-install web publishing tools to be content management systems. Yes, they are populated with content, and they meet the fundamental definition of a content management system, as used in my book, Author Experience:

A content management system is an environment that allows information to be created, stored, and edited, in a compartmentalised structure, and output for use.

But simply meeting the base definition does not imply a tool is fit for purpose. Of course, it depends what you want to do, and the respect you have — or not — for content. Do you consider a delivered web page to be content? Or is content the material that populates a presentational container to create a web page?

I embrace the latter definition. While the delivered instance is a form of content, it lacks the versatility of the purer definition.

Web publishing tools

Easy-install web publishing tools are just that: tools that facilitate publication to the web. They are neither designed, nor intended, for anything else.

Such tools consider the page as the base structural element. They are aimed at people who want flexibility in the content they publish. The standard page may include a title and some tags, but there are few constraints on the body. It accepts a small block of text, a quote, a video, a long-form article, or any combination thereof.

By default, many web publishing tools provides a rich text body area that accepts just about anything.

The problem with this approach, when viewed through the lens of pure content, is that the available content elements and mark-up structures are visual rather than semantic.

All about presentation

I don’t expect magic. I know that building meaningful content — meaningful structures — requires some level of content definition, and a separate definition of its presentation. (Yes, separate.)

None of those web publishing tools come close to doing what I expect of a content management system. They hide these definitions in code, rather than allowing declarative configuration.

Web publishing tools manage content for the sake of web presentation, rather than dealing with semantic value and applying presentation rules separately. (This is not always by original design, but the plugin culture’s focus on presentational blocks has corrupted the tools in that direction.) The guiding principle appears to be that it is better to spend on the operational process of having people handle the mess and manage the special cases, than invest in an underlying infrastructure.

Every web-publishing tool I have seen would require considerable customisation to do what I expect, in one of two ways. Either I’d have to dig into the tool’s code and structure, learning a new language that I’d never use again. Or I’d have to hire a developer — whose presentation-centric tendencies, inevitably, would be at odds with my desired objectives — to extend the tool for me.

The presentation-coupling bugbear

The topic of semantically structured content returns every few years to the industry’s awareness. Like a beach facing off against a relentless ocean, the demand for semantic content claws its way into the public and professional consciousness, only to be smothered by the next breaking wave.

At its core, semantic structure defines content where each element — and sub-element — is described based on its contextual value. It contains no information pertaining directly to how it renders in any environment. A separate process maps visual styles onto meanings.

This separation of the content from presentational aspects is known as decoupling.

Decoupling the CMS

Most discussions about semantic content relate with handling the semantics within the CMS. In theory, it’s the easiest part of the communications process to decouple, at least when content management systems are designed to manage content, rather than web pages.

With single channel publishing tools, there is a tendency to think that we might as well store content in the format that will be presented to the end user, so it makes sense for our authoring interface to create that format. This does not mean, for web publishing, that we store HTML files. It means that our stored content chunks are HTML fragments, using standard HTML tags.

If we serve our content through only one channel, why not? Storing content in the form that we serve to the user saves processing time on each request. And that adds up.

There are three core reasons for decoupling content from presentation within the CMS:

  • Reusability across other media and channels (they will not all use HTML)
  • Reusability across contexts within the same channel (an alternate wrapper or HTML structures will be needed)
  • Redesigning/rebranding the delivery channel is significantly easier with decoupled content

A solution exists that allows the best of both worlds. To gain the benefits of decoupling without losing the performance benefits of ready-to-serve HTML, we simply need cache — to store two (or more) versions of the content: the master version, which provides decoupled semantic content for editing, and a pre-built version ready for quick delivery.

Decoupling the delivery

The second aspect of content-presentation decoupling, which receives a fraction of the attention, is decoupling within the delivery. Most people believe this has already been solved. After all, that is the purpose of CSS.

But decoupling HTML content from presentational descriptions is a tricky process. There are three offenders:

  • Presentational HTML
  • Inline styles
  • Presentation-centric class names

Presentational HTML is any HTML syntax (as opposed to CSS) that dictates how content displays. The most notorious form is table-based layout. A seemingly innocuous attribute like align="center" also qualifies.

Inline styles are cases where a style="" attribute is attached to an element, instead of using class="". They indicate that the code generating the HTML would need to change if the site were redesigned.

A usable exception to inline styles is a style="display:none" attribute, when attached to an element that would never display, irrespective of design (such as an analytics-related element). Of course, the equivalent presentation-centric class name would be better.

Presentation-centric class names are class names that describe the content’s display characteristics, rather than its semantic function. Positional and decorative identifiers, such as centre, red, and gradient-bg, are common offenders. Then, there is the ultimate sin: class="clearfix".

Class name that straddle the line between semantic and presentation (e.g. class="inline") are acceptable.

(I looked at a few big-name sites (news and social media), to see how they fare on these fronts. CNN and Facebook failed with presentational HTML. Google and Twitter both included inline styles. The New York Times and the BBC used some presentation-centric class names.)

As with CMS-level decoupling, avoiding content-presentation coupling in delivery makes redesigning and rebranding the channel a lot easier. It also facilitates repurposing across channels and platforms.

Decoupling dynamics

While the first two forms of decoupling are easily understood, the third is more difficult to understand and to achieve. I am referring to how we handle changes to content styling, usually in response to end-user interaction.

We have the following tools at our disposal:

  • Basic HTML containing the content itself
  • JavaScript to modify stuff dynamically
  • Class attributes that apply CSS to the HTML
  • Style information that:
    • Defines the CSS
    • Can be applied directly to the HTML

Which tools have become the industry standard for dynamically manipulating presentation? Obviously, we use JavaScript to apply styles directly to the HTML. We couple them as we manipulate.

Alternately, we could (at least in theory):

  • Have classes that represent each possible display we expect of our content, and use JavaScript to change the applied classes, or
  • Use JavaScript to change the style definitions within the CSS.

When items need to move dynamically, there are too many variables and options to pre-define every permutation. CSS transitions cover many of the movement scenarios in simple cases, but not user-directed content manipulations.

Modern browsers support manipulation of CSS definitions, but the mechanism is convoluted. I get the feeling that developers chose to discourage this approach: why employ a layer of indirection to interactions when the end result — application of style information to the rendered elements — is the same? The rendering engine has less work to do if the style is applied directly to the element. (The decision appears to have been taken back in 2007. The performance argument may have had some weight then. But it is invalidated by the presence of the calc(…) function — and equally indirect definition — in modern CSS.)

Classes are used more to apply styles to content elements than they’re used to identify the semantic value of content. Our presentation dynamics are coupled to our content.

This does not have the redesign/rebranding issues that in-CMS and delivery coupling do. The scripts would need to change irrespective of whether they are manipulating styles applied to elements, or to classes.

The strongest argument for fixing presentation coupling in dynamic interactions is cleanliness.

Given the overhead involved in manipulating class definitions, I would accept a compromise solution where intermediate motion uses coupled styling, switching to a new class upon reaching a stable state.

My site goal

Having despaired of ever finding a web CMS provides meaningful management and output of content, I decided that I need a custom implementation.

I am not starting with a platform choice. I leave that to the developers. Instead, I came at the problem with two basic requirements:

  1. Output HTML that, with only a CSS change, can serve multiple sites
  2. Provide a semantic authoring experience that makes sense

I’ll throw in an additional requirement for good measure: No access to manually manipulating the HTML.

Don’t touch the code

Why do I not want to be able to manipulate the generated HTML? Because accessing the HTML breaks things. If the interface cannot generate the semantics I have specified, it is incomplete. If I’m creating new structures on demand, I am trying to communicate with semantics that are not part of my style guide, that I do not have CSS to present.

Now, sometimes you want to do something special. I follow Matt Gemmell’s blog, which mostly deals with writing. A while back, Matt posted a piece on the value of handwriting as a communications tool. In that article, he delved into the personal nature of the hand-written word, as compared with typed content. To illustrate his point, he included a switch that replaced all the text with hand-written images of the same. It was a cool feature, making for a powerful piece. It was a one-off.

Occasionally, one-off pieces of content are worth the investment of custom-developing a template that can cope with an alternate data structure.

Where the investment is justified, do it. But do not use that possible need as an excuse to lower the cost of one-off functional designs; doing so allows content managers free rein to hack the code structures used in every page, eroding the site’s thematic voice.

The moment code has been directly manipulated, we lose the ability to properly manipulate it with the standard tools. (This can work the other way, where the tools do not allow certain expected functions, and strips them out if they are added directly. I’m, looking at you, WordPress, with your WYSIWYG editor that does not support, and actively strips out, <br> tags.)

A rational author experience

Author experience is a big thing for me, obviously.

I understand that for many, getting content into a web page — thinking only of how it will be presented in this specific instance — is enough for now. But I can see where communications and technology are going; content needs to flow to many platforms and channels. We cannot rely on move-the-sidebar-to-the-bottom responsive rules.

Content needs structure. It needs to be semantic. Machines need to be able to understand it. (Yes, so Google can extract an answer from your content and present that to the user, without them ever visiting your site!)

Content is the currency of communication. If you want to manage content, you have to view it holistically. Then, the purpose of a CMS becomes clear (again, from my book):

The purpose of a content management system is to facilitate the human process of managing the communication content lifecycle from creation, through use, to archiving.

I want a CMS that understands my semantics. I want a CMS that allows me to reference a person, a book, or a place, and reuses defined characteristics of the referenced entity, while marking up the output with schema.org itemtype and itemprop attributes.

When I define a content type, I want control over the authoring layout of its fields. I do not want that dictated by some belief about how the content is presented.

Am I asking so much of technology, that it support my processes, rather than forcing me to contort my thinking into an unnatural pattern to accommodate its restrictive paradigms?

Pure content, pure presentation

As should be obvious by now, marked-up content that’s semantically described by class names will be presentation-agnostic. It can be styled any way you want — presented in any format — simply by changing the associated CSS. While this requires an understanding of the cascading nature of CSS, it has very compelling consequences:

  • It is accessible
  • It is search-engine friendly
  • It is machine-scrapable and reusable
  • It can be styled responsively while maintaining relationship sequences
  • Its presentation can be easily rebranded in CSS

Is this too much to expect from technology? Is it any more than should be demanded by every organisation involved in communicating information that is relevant and valuable to its audience?