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?
26 comments (Comments closed)
I think that the soon to be (I hope) css 3 selectors will give authors of css a very powerful tool for manipulating any xml based language. Instead of the fairly limited id/class system there will be a whole new [attribute]based system, along with a slew of pseudo-elements and pseudo-classes. And I haven’t even got my head around the whole generated-content modules that are still incomplete.
I have put quite a bit of thought into these same questions. Lately I’ve been thinking about this as it relates to having Web based content (xhtml - xml) being your single source document for content, print included. In order to achieve that the content really needs to be as presentation free as possible.
In my day job I spend lots of time working with legacy content as well as tools developed by vendors and an extremely clunky CMS system.
Every day I see more than my share of font, span, b and i tags as well as way to many inline styles.
My goal has been to do as much as I can to present the content with as few (hopefully semantic) tags as I can get away with. I strip the content down to it’s barest essential and start from there.
I think it’s much more important, looking to the future, to make sure your content is presentation free than it is making sure your templates or layout are presentation free. Although, obviously there are benefits to both.
However, it seems to me that this is often the opposite of the way many people work. They work on taking the tables out and moving the “layout” presentation to css, and this is great, but in the long run the content is what really needs this attention.
I mean, chances are the content is going to outlive any design or layout.
For a new site, this isn’t all that hard, but when dealing with legacy content or a CMS, this can get really frustrating. I feel like that with most content you can get by with under 10 tags and most content needs 5 or so.
But like you said, bad (old) habits die hard. I have an example of just this… Sometimes you revert back to the way you learned how to do something, or forget to employ some new method simply because you are caught up in getting something done. I bet we’re all guilty of that.
Since we are trying to get away from changing the markup everytime we update our design, I’d like to know what everyone thinks is the best way to structure the markup to have the most flexible markup when building a design?
Any thoughts?
When explaining CSS-based layouts and its cohort, I’ve started to say that we’re “insulating” content from presentation.
At the moment, the net result is that we’re decreasing the cost and complexity of changing markup; as others have noted, the cost will (presumably) decrease further or be eliminated once CSS 3 (and hell, even CSS 2) selectors are better supported in the wild.
To paraphrase Zeldman’s book, it’s a transitional approach for a transitional time. “Insulation” isn’t as good as “seperation,” but it’s far better than nothing at all.
I think right now that complete seperation of content and design is not possible outside of a small personal site. Currently there are too many variables involved in integrating disparate systems and content for larger sites, not to mention browser issues. However, I think that if you design with an eye towards the future and try to abstract things out as much as possible and keep thinking to yourself “man in 1 year everything could change, I should try to make this easy on my future self”. The transitional approach I think is the best route at this point, particularly in this time of browser uncertainty. Who knows what browser people will be using in 3 years, if it is a browser at all.
In the present state of things, content and presentation are already separated most of the time, let’s face it, with content in a DB on the one hand and a website or wapsite or xml output or rss or whatever on the other hand.
I’m always wondering what the limit is, money-wise, before we stop asking this kind of question.
Basically it’s an ideal, but by definition an ideal is unattainable.
I use the phrase separation of content and presentation as a goal that is never to be forgotten, but in my everyday practise I feel that by its very nature the web doesn’t permit a complete separation.
“Who knows what browser people will be using in 3 years”
Probably IE 5 or 6, unless MS pulls their collective finger out or people suddenly decide to Switch…
When you update a page and add new content, or make new pages with new content, you’re likely going to be faced with new structure. For example, if I add an adbanner to my website because I have a new deal with a partner, I’ll probably want to wrap it in a new div with a class of “adbanner” or something like that. And then I’d have to move to the CSS to create the reference and style for that specific item.
Basically, it means that as long as you update your website, you’re going to have to make changes. As long as content is bound to structure - and it always will be - you’ll be forced to make changes to one to affect the other. And presentation will be a requisite if you intend to keep your layout up to scratch.
Web design is really just like database design: the more you can plan out before you start, the less you’ll have to do in the long run. But if you suddenly realise you missed out on some content element or type, then you’ll have to adjust the structure to fit around the new content.
The only thing we developers can do is try to be as efficient as possible when designing these sites. But that doesn’t mean we should make “for future use” divs like the CSS Zen Garden did, for example. That would be inefficient.
So even with minute planning and a lot of foresight, it still doesn’t solve the problem. The paradox is one that is bound to its context - much like content that is bound to its structure.
Every single site I’ve built (or rebuilt) using CSS for layout has structural complexities that require the HTML documents to contain additional divs to produce the layout I wanted (at the time). The early attempts used floats and div containers to place content in specific places on the page, now I mostly use position selectors to raise HTML from lower in the document to form a visual column or block.
In both cases the container, while having some semantic meaning, (perhaps defining an area of related links or contextually relevant notes), is only really there to allow me to place the content in a certain way, as part of a visual layout. For a visual user, HTML containers are regular shapes and their position contributes to their meaning. In order for content/data to be separated from the presentation, ought I not to remove these container divs as well?
Nowadays I, like many designers, construct my HTML in as minimalist a way as I can manage, (when time permits) iteratively and recursively checking each modification to ensure it, and it’s dependancies, are absolutely necessary. But I’m still adding containers to construct a layout.
Tables have
thead,tbodyandtfoot. Given that most HTML documents also display these features, why don’t new specs account for this? They have semantic meaning, they could even have a pre-stated, default, unique ID ‘#header’ etc. After all, it’s not like we’re talking about XML here. XHTML 2 introduces the concept of navigational lists, but why stop there?~
The only other theoretical way I can see to separate data and presentation would be to
IDevery element, and position each one individually. Apart from resulting in unwieldly style sheets, this would produce problems if a sheet was re-used for another document, and (e.g.) an absolutely positioned list had grown in size.Because of course, the point is to use the same stylesheet over and over.
Ooh. Ramble alert. What was the question again?
Ah, yes.
If you want do layout, no, you can’t separate presentation from content/data using HTML and CSS.
(XML and CSS, yeah you can. But 99% of the world use IE5+ish.)
One point - the mere fact that loads of content is stored in databases now does not entail that content and presentation are separate. I’ve seen people dropping FONT tag-ridden HTML into their databases to ‘better control how it looks’ when the CMS outputs it.
Granted, that’s primarily an issue with the CMS being too liberal in what it accepts, but it does go to show that just because something’s in a database doesn’t mean it’s free of presentational information.
Perhaps it’s time to start thinking about using XML as the base database format for web-based CMS’. That way the database itself is aware of semantic structure, presentational information, or other aspects of hypertext markup that SQL databases treat as “text” or “varchar”. And then you could easily choose to either parse the CDATA from XML nodes using a PHP script, for example, or use XSLT to grab the relevant information and turn it into HTML.
At least, theoretically, anyway.
My experience? I wish I could use this type of design strategy at work, but I just plain and simply can’t. My personal sites, and any other site that I create and maintain, definitely follow this tecnic. It’s makes things just so much easier.
At work, though, we have this CMS that does not allow any control over the <head> tags, plus the corporate color and design is created using nested tables that litteraly go about 7 tables deep to get the content in there (in it’s own table, of course). It’s a mess, and a nightmare to edit (especially since they aren’t using SSI anywhere… so all navigation chnages need to take place in every single file…. my head hurts thinking about it).
The biggest problem with table based layout is how difficult it is to pull out of it. When you are locked into tables, layout becomes a cross-browser nightmare, and design is also hindered.
I hope someday soon all this will be an afterthought, but unfortunately that’s no time soon - at least from my perspective at work. It’s a major organization, and it’s new implementaion of the wretched CMS just locks us into tables and a big ol’ honkin’ mess for years to come.
That’s my experience- since you asked for it!
Going towards a route with XSLT or XBL would make it possible to dynamically insert the needed tag elements used for presentation purposes without having to alter the original document’s HTML.
With XSLT, you can create a template, and use it to transform XML file to include additional presentation. And with XBL (XML Binding Language), you can “bind” additional presentation markup to HTML.
But, as with most things, there’s good and bad points to everything.
I think the second part, separating structure from presentation, is a bit of a pipe dream. Getting rid of nested tables and endlessly repeating font tags just makes good sense, but there comes a point where you can really start to overthink things. Let’s face it, HTML is inextricably linked to presentation. CSS is brilliant, but even with full css-3 support, some container blocks have to be there for essentially presentation reasons (even if we fool ourselves by giving them a semantic name).
The ideal solution is to have your content in a normalized relational database then build your pages out from there using XML + XSLT, or a content management system, or whatever. Just keep the source of your content pure, and you have the freedom to create pages however you want. XML by itself may be a great way to transfer specific document formats, but a relational database is the tried and true model for when you need true ad hoc flexibility of your data.
Of course, your intermediate layer also makes a big impact on how easy it is to modify any component independently.
For my website, my markup is constantly changing with each new design BUT I’m changing it to learn how NOT to change it. In a way, my website is getting more and more a lean clean machine to do whatever design I want with it.
I’m using it to get a base template that could do everything I want so that when a client finally understand the advantage of CSS based design, I could offer a site that stand a little bit the test of time.
I very much agree with this article, and I like what Josh says, above (comment 3).
The pages we make may validate XHTML, and may use all the cool techniques we’ve learned to make clean and clever CSS layouts, but the stuff in between is a bit random. By ‘in between’ I mean the divs and classes and page structure we end up using, either in one-off pages or within a templating system.
I know there are lots of future plans involving XML and other acronyms with X in them :-), but right now I wonder if we need to start thinking about the clearest and most consistent way to code - beyond the valid XHTML and CSS.
In a way, we need some kind of web standards for the semantics of coding a page, so that the divs and classes make real sense. My menus are usually in a div called ‘nav’, while Zeldman’s are in ‘secondarynav’. This site has the menu list inside ‘header’.
There’s no huge problem here, but on the other hand, maybe there really is. Just as h1 is meant to be the same on all sites (representing the main page title), is there any way, or any point, in developing a way to tie all our menus (or whatever) together semantically? To make all our content divs inherently content? A footer is, afterall, a footer whoever’s site it’s on: if we all had a way of IDing our divs consistently, then we could more or less swap CSS files between any site, and everything would work. This isn’t an end in itself, of course… instead it would be something that happened when there was a standard way of laying out pages… a standard way of linking each of the CSS rules with the HTML on the page.
Sorry for the long rant… I’ve been thinking about this a lot recently :-)
I think the article we’re discussing has been a long time coming - what does Zeldman etc. think? Someone write a big article for ALA!
When I first read the title of this article I was afraid it would be another criticism of CCS for not being practical enough, but having read it I would say it is Right On. Most manipulation of HTML to achieve presentational effects is done because the original markup was not correct or thorough enough. And I couldn’t agree more with Post #1: CCS 3 will take us one giant leap towards having fine-grain control over presentation, something I’m looking forward to very much.
In terms of progressing towards having specific div IDs and such, I think XHTML 2 is more or less that same idea, with having <section>s and such. But because of such advances, it’s getting a lot of criticism… so maybe overspecifying such things for dynamic documents like websites isn’t the best choice?
My experience is similar to that of everyone posting here. XHTML just does not have the correct semantic elements for describing a page. The structure of a page is determined mostly by coding style and style sheets do not transfer.
Adding extra structural elements to XHTML seems to be the best way forward. In real terms this would probably take a good couple of years to propagate even if done now.
A W3 recommendation for coding style describing IDs/classes to be used for common structures would be superb. This would allow me to use and understand style sheets written by other developers immediately (and vice versa).
If this was sufficiently encompassing then conversion to future markup languages could even be achieved by running the existing XML markup through some standard XSLT.
This topic has been of great interest to me recently. I work at a company that has it’s own website, but then creates versions of this website for partners. The content is the same, but we must match the partner’s look and feel. This is a perfect testing ground for seperating content from presentation.
I’ve started exploring the use of XHTML and CSS for this purpose. The ideal is to have a single set of structural XHTML and then to only write new stylesheets for each partner. This is proving to be a difficult task. The current methods of XHTML/CSS may not be flexible enough to allow for the customization of layout that partners desire. While CSS Zen Garden has proven that this is theoretically possible, it requires the addition of extra markup to anticipate future design needs. The problem is exacerbated because we are an e-commerce site as opposed to a more text-centered content site. The formating needed is more complex than just header/footer/sidebar and paragraphs of text.
While I think that this method has a number of benefits, I don’t know if we’ll be able to get away from having to go in and edit the structure of the documents.
You can see some of my efforts at http://usairways.lastminute-getaways.com
This is a beta launch of the site, so there are still issues to be worked out. The site should render well in ie 5/6 for Win, Mozilla, and Safari. There are still some issues with IE 5.2 for Mac. Also, the XHTML will not strictly validate because of invalid HTML in the database, and ampersands in query strings generated by the back-end. I’ll be working to get those cleaned up as well.
While XHTML/CSS is a vast improvement over previous methods, the ideal of seperating content from presentation and especially structure from presentation isn’t there yet.
This is an initial thought: your battle with this topic seems to me to go way beyond websites. You are talking aboutr knowledge itself, both in psychological and in philosophical terms. Is knowledge and meaning seperate from structure and words or is there always an interelationship? I offer no answers because this is an off the cuff response but I think the artificial intelligence area which battles with questions of how computer and human memory is structured, the psychological arena and philosophy itself, would all be interested in the issues being thrown up be the evolution of the Internet and World Wide Web
A similar point has been made by Eric Meyer, but it bears repeating that there is a problem with talking about separating content from presentation. Without content, there is nothing to present, and the nature of that content is what determines how it should be presented.
This is something that can often be overlooked by web designers when they utilize style (presentation) in spite of the content, rather than to present the content in a usable way.
In my own experience, I run into this problem when I am asked to design banner ads before the copy is written. It is assumed that the text can just be added to the design afterwards. What they are missing is that the copy, for the most part, is the design.
We should be careful not to forget that design is inextricably linked to content.
Our site is a real-world example of seperation of content and presentation. The source document for both the “grahpics” and “text” versions is an XML representation of content that we created a schema for ourselves. Then used XSLT to transform it and CSS to present it.
XML and XSLT are certainly tools that can help seperate structure from presentation.
Strangely I was working a similar vein of this thought process myself yesterday (Wed) when I came across this post from Tuesday.
The three (content, structure, presentation) are very much separate entities, but they are tied together at the core. Structure is dependant upon available content, and presentation (at its best) must take both structure and content into account. However, in order to acheive an appropriate presentational effect, content and structure may have to be altered to accomodate.
In exploring these thoughts, it truly is very similar to the detail and care given to typesetting and design before the age of digitally-aided Desktop Publishing. If a line of text dropped a widow or orphan to the line below, text (content) had to be edited for the sake of design—either to drop a word to remove the widow, or to add text in order to push the line further across the containing column.
This reliance upon each other, ultimately, is a good thing for web design. The three are distinct and at the same time bound. If properly realized, this should lead to thoughtful and brilliant design.
Nitpick:
What you’re talking about is separating content from structure, and structure from style.
structure + style = presentation
First, this is not about “content versus presentation”. At the URL below I show that content can undoubtedly include presentation, even presentation generated using CSSs!
http://www.barry.pearson.name/articles/content_presentation.htm
It about “mark-up versus presentation”. In other words, put your presentation into the content, or add it later with CSS, but don’t do it in the mark-up. (I hope people don’t think that “content” equals “text”?)
Second, although this wasn’t necessarily a key theme here, there are some misleading and indeed mischievous staements made about the “tableless” page-formatting principles. These are useful new tools, but that doesn’t mean that they are in any sense “the way to go”. They are simply yet another tool to be evaluated along with the others. I am working on this, comparing various approaches, but an initial (repeat - initial) view is expressed at:
http://www.barry.pearson.name/articles/table_pages.htm
I note that some of the arguments I used in that page have been better expressed in this forum! Especially by anyone who talks about presentation applying to the content available, and not being something independent.
A third theme I am working on at the moment is that I, and many others, tend to put material onto a single axis, something like “information rich” to “artistic”. I also think that I am guided about where the author thinks material should be on that axis by how artistic it appears, since that is the easiest to see. So if it is artistic, I don’t even expect it to be information rich.
When I look at the CSS Zen Garden site, I don’t bother to look at the text in the examples, because these are works of art, surely not information-containers? I wouldn’t bother with something that purported to be an academic paper but was overly concerned with artistic presentation.
Comments no longer open for this entry.