Separate content from its presentation. One of the lingering mantras of web design and development. It exists as both a rule and a strategic practice. A commandment which promises rewards if followed. But have we iterated this phrase so much as to strip away its meaning? Have we lost sight of what it means to keep the two independent? And is the concept even a real possibility? Is it still merely a myth?
The world of dynamic, database-driven content and conditional server-side scripting brings significant advantages to site owners and content producers. Personal publishing systems and large-scale Content Management Systems add layers of abstraction, allowing the content (or data) to live outside the scripts which assemble content, and the XML or HTML which provides its structure.
These tools allow us to take a large step in the right direction. But they’re only one piece of the mantra above. Technically, we could split this separation concept into two parts. “Keep content separate from structure” and “keep structure separate from presentation“. The first part can be handled by almost any CMS or publishing system, as I’ve already mentioned. The second part is possible with the use of a style sheet language, such as CSS.
Reality?
But can presentation rules exist entirely separate from structure? CSS selectors build conditional rules which depend on document structure. Selectors specify conditions such as where an element appears in the document, or they hone in on an element based on a pre-existing application of classes and/or IDs. Subconsciously, we may realize our style sheet is a one-off, inherently bound to the document or site it defines. But a document is not at all bound to one style sheet, as the CSS Zen Garden competently demonstrates.
Design changes often require manipulation of more than just the style sheet. This is a reality. Content needs to shift places, or new content needs to be added. We’re constantly learning better ways to mark up our content with leaner HTML, replacing old hacks with better methods. But we need to remind ourselves that we won’t — and in some cases, shouldn’t — always have the luxury of markup control when changing or applying new styles. In some cases, final markup output might be controlled by a deeply embedded CMS under the dominion of stubborn engineers. In other cases, portions of markup might be served by third-party ad vendors and content partners.
In the spirit of keeping structure separate from presentation, ideally, the markup shouldn’t need to change if written correctly the first time. But we might not have power to change existing markup to better suit our purposes. We need to break ourselves of relying on the ability to affect markup in order to change design. When we talk about redesigning a CSS-based site in a matter of hours or days, compared with weeks or months, we’re implying the changes occur in the CSS alone, leaving the markup (mostly) untouched.
Old Habits Die Hard
Unfortunately, some of us have become accustomed to changing markup structure at will. Publishing systems controlled by templates allow endless manipulation of front-end code. We tweak templates, instantly distributing changes throughout hundreds or thousands of web pages with the click of a button or two. Personal sites and weblogs are often controlled by one person or a small group, providing a distinct advantage over larger commercial sites. Changes to markup structure and design happen any time, without need to consult producers or engineering teams.
The concept of keeping structure separate from presentation becomes obfuscated when we make design changes by manipulating both markup and CSS at the same time. Learning the effects of CSS by tweaking markup is one thing. So is stripping out old table hacks and font tags during a massive conversion. However, when we make small design adjustments by adding extra <div> tags or class attributes, then alter the CSS to take advantage of those markup changes, we confuse the concept of independent structure and presentation. We may even continue bad habits and form inappropriate expectations along the way. I write from my own experience. What’s yours?