With all the discussion about separating presentation from
content (and structure), it’s easy to lose track of the goal. So
let’s step back, define our terms, and take a look at why it
matters.
Presentation#section2
The major reason to separate presentation from the rest of the page is
simple: to simplify any change from a slight design adjustment to a
full-fledged redesign. To achieve complete separation of the
presentation, we must isolate everything specifically and
solely geared towards style.
Contrary to what you might be thinking, this isn’t
limited to just the CSS, not even on a site like CSS Zen Garden. It
also involves HTML tags and properties that exist only to provide a
handle for the designer to apply
styles to. After all, what use is a .pageheader {…}
declaration block if there is no element with that class on the page?
Hold on to this thought and read on.
Content#section3
The reason to separate content from the rest of the page is just as
easy to see as the reason to isolate presentation. Isolation of content
makes adding or updating things easy while maintaining presentational
consistency throughout the site. However, as with the presentation,
there can be confusion
over what content actually is.
For our purposes, content is (usually) text and includes accompanying
semantic
coding: tags like h1-h6, paragraphs, list, em, strong,
code, cite, etc. Content should not require any additional
presentational tags or styles in order to fully convey its
message.
In isolated cases, we might use additional tags to more
correctly present the content. For example, a poem — where
specific line breaks are important — could be set apart by a
<pre class=“poem”> tag, or it could simply make use
of <br> tags to break lines.
Structure#section4
Here’s where things get sticky. First of all, what is
structure? We could describe structure as everything that makes up
a page, minus presentational elements and content. However,
this is at best an overly simplified definition that could easily
cause undue confusion.
Take the navigation menus on ALA as an example:
- Change a color here, a border thickness there, and you have a
change in presentation. - Change the text of the first navigation item from “Up
front” to “Home”, and you have a change in
content. - Lastly, you have the
<div id=“menu”>,
<ul>, and<li id=”…”>tags
as the structure. Switch those out with an antique row of table cells,
and you have a change in structure.
But wait — remember what I pointed out earlier? Those tags
include
presentational elements: the IDs. As both Doug Bowman and Eric Meyer have pointed out,
presentation is pointless without structure. Furthermore, I’ll
show that
it’s also pointless to try to separate structure from content.
Take the simplest example of web content you can think of:
Title#section5
Lorem ipsum dolor met.
The <h1> and <p> tags are clearly
part of the content, right? We can’t write correct HTML content
without this basic semantic markup. Yet this markup is also part of
the document structure, dividing up an otherwise-uniform blob of words
into a heading and a paragraph. (And of course, if you want to get
picky, you can consider the markup to also be a part of the
presentation as well. After all, the browser has a preset way of
displaying <h1> and <p> text,
doesn’t it?)
So where does this leave us?
Content and structure#section6
You can theoretically separate content and structure, but then you’d be left with <ul><li>
for structure and plain featureless text for content. Needless to say, building a functional site out of those is quite impossible.
So we can conclude that structure cannot and should not be separate
from content.
Presentation and structure#section7
As we have seen, without structural elements, there is no way to apply
styling to the content. Structure cannot be separate from presentation
— nor should it be.
Which leaves us with …
Presentation and content#section8
Although presentation still depends on structure, some of which is
embedded into the content as noted above, presentation can and should
be separated from content.
And while major presentational changes can require changes in
structure,
content can be changed without any need for structural change
beyond the already-embedded structural elements.
Real-world separation tools#section9
With all this in mind, let’s envision the perfect website
separation system.
It would store content in a database, allowing the isolation and
management
of content information. Presentation and structure would be handled
together; presentation
could be managed with a stylesheet and accompanying structural elements
where needed.
Structure would best be dealt with through a system of
template “packages” built using a server-side scripting
language (such as PHP or ASP). Each template “package”
could have one or more stylesheets (e.g. CSS Zen Garden), but every
template “package” would connect to the same with the same
database to
retrieve content for display.
Many content management systems provide varying levels of this kind of
template support. However, full-featured template systems that make CSS
Zen
Garden-like usage of stylesheets — especially ones that come with
a comprehensive content management system — are few and far
between.
But for a competent webmaster, building something like this from
scratch can’t be all that hard. Can it?
You cannot separate structure from content without making the structure ilogical. That’s why I don’t do it.
We have bigger things to worry about than seperating content and structure. It’s like worrying that you’re going to miss your favorite TV show (for me, The Simpsons) whilst your house is burning down.
Example: I have been researching the possibility of 100% accessible Image tab Rollovers that use Javascript to replace the images and CSS for the rollovers. This method is built to so that
it’s accessible to any UA – even screen readers (but only one browser, the best browser ever, gets it right: Opera 7). Sites using FIR are either inaccessible or riddled with hacks: it’s been solved by using Javascript, but no one seems to care: we’re all too busy worrying about ‘Should I use em or strong?’
Harry: “…XML to describe the content, XSL to transform structure to XHTML on the client side, and CSS for presentation.
Of course, the limitation (for now) is client support if that’s important to you. Well, that, and search bots don’t seem to understand XML, so if being found by search engines is important to you…” (http://www.alistapart.com/discuss/separationdilemma/2/#c8125)
The solution is server-side scripts and stuff to fall back on, which I havn’t tried YET.
There are several structures please stop fighting over the wrong ones!
There IS structure in content that is part of the content, then there’s structure that’s part of the current page, plus structure of the whole site (repeated on all pages).
You start by building a structure and adding content (yes the content includes a bit more structure). Now you use the structure (which may include some class or id attributes or not) as the hooks to style-up with CSS. If the structure is consistent throughout your pages, the style will be consistent throughout your site (a very good thing). And you can use the structure as a framework to add new pages/conent with the confidence that the presentation is already taken care of.
The structure is the link between the separated content and presentation, wheter or not content can be separated from structure or not, is irrelevant. Hook onto the structure in order to provide presentation hints and behavioural facilities, but ensure the structure and content-with-some-of-its-own-structure is perfect before adding presentation.
Also the greatest reason behind the separation (not sure if this has actually been mentioned yet!) is that it means you don’t have to rely on un-reliable presentation to convey the semantics/structure/content/meaning.
First of all, I’d like to point out something that’s not directly related to the issues at hand.
The website of the company I work for is horrid. As pointed out to us via a form submission, there’s no doctype declaration. Nor, I will point out myself, is it a site to be proud of in any way, shape, or form. It uses tables up the wazoo, needless BR tags, etc etc – in short, quite embarrassing for a standards-minded developer like myself.
It’s a simple case of the shoemaker going barefoot. He’s so busy with projects for customers and clients that he has no time to make himself shoes. I’ve got at least 3 big projects on my plate (big is relative, since I’m the only web dude around these parts), and a number of people in the waiting line to ask for sites. In the words of the (in)famous Prince Humperdink, “…I’m simply swamped!”
Ok, enough of that embarrassment. :p
Dante: “What I meant was nitpicking about the little things (strong and b, em and I).”
Yes, for most users, it is nitpicking. But tell that to the blind man who uses a screen reader to surf websites. The B tag is purely presentational, and says nothing about the meaning of the content it encloses. It is merely “Display this text in bold.”
STRONG, on the other hand, is (usually) formatted by default in bold, because that is the commonly accepted way of placing a strong emphasis on content. But when you look at (listen to?) screen readers, they know to place a stronger emphasis on text designated with the STRONG tag, because it designates meaning, not appearance. Semantics (via structure), not presentation.
Rob G.: “This article is not preaching anything new and is merely recanting the widely used concept of separation of content and stylization.”
Partially correct. 😉 As stated in one of my previous comments, I wrote this 5 months ago, but it was only able to be published now.
However, at the time of writing, I had not seen anything besides “separate content and presentation”. I did not see any mention of there being 3 players, not 2. And I, needless to say, did not see every single article ever written, so forgive me if I missed something. 🙂
Steveg: “You could certainly seperate out block structures without too much sweat but where does a set of em tags fit into the scheme. Are they presentation, content, or structure?”
EM tags are semantic in nature, and are structural markup. They have default presentational styling assigned to them by the browser, and they set apart content contained in them as emphasized.
Ronald van der Wijden: “Consider a markup language which did offer all the different elements needed to mark up each and every bit of content with the appropriate meaning: each element could be specifically targeted for styling without any “pollution”.”
Quite correct. This is, according to my limited understanding, what XML/XSLT/XHowManyXAcronymsCanWeHave is for. 😉
Kristian: “Separation must have a purpose. It also seems that the author has missed the point of separation; the main reason this “separation system” should be allowed to exist is to be able to present the parts as a whole. So why not call it a “wholer system”? Since that should be the purpose of separation….
…Sorry for the poor english.”
First things last, your English is considerably better than many (most?? :-/) native English speakers.
Secondly, the purpose of separation is not to present the parts as a whole. That is comparing apples and oranges. “Separation” has no purpose, it IS a purpose. With separation, we allow content changes without affecting site structure or presentation, and presentation changes without affecting content.
Yes, it’s pointless unless put together for the end user. But separation does not have a purpose, it is the purpose. 🙂
Charles Belov: “IDs were presented here as being presentation. I am in the camp that wants to use them as structure: ID=sitenav ID=pagenav etc.”
That is the proper use of ID and CLASS properties – structural markup and CLASSification. They are handles to allow styling just as much as Hn tags are. The only exception is that the ID/CLASS is user-definable, therefore it does not have a default styling set by the browser.
Mathias Munk Hansen: “You cannot separate structure from content without making the structure ilogical. That’s why I don’t do it.”
Not to the end user, no. But if you store your articles in a database, you certainly don’t want to store the site navigation DIV along with it. That’s a kind of structure, too. I assume you’re talking about STRONG tag structure and the like, however. 😉 In that, you are correct – it should be, at every stage, part of the content itself. Which was one of my points in the article. 🙂
Dante: “Example: I have been researching the possibility of 100% accessible Image tab Rollovers that use Javascript to replace the images and CSS for the rollovers.”
I find this slightly amusing, but correct me if I’m wrong here. You’re using Javascript to ensure the accessibility of your site? Looking beyond the typical computer platforms, do you know how many devices that access the web do not support Javascript, or any kind of scripting, for that matter?
XML and Various Related Flavors: Those of you who have brought this up are probably making a very good point. Unfortunately (see the Shoemaker analogy above), I haven’t had the time to teach myself this branch of coding. Yet.
Michel Cohen: “This is, according to my limited understanding, what XML/XSLT/XHowManyXAcronymsCanWeHave is for. 😉
”
That is exactly what I was referring to, but I thought not to throw in the “X-acronyms” to avoid clouding the discussion any further… 😉
I feel this whole “separating content from structure” is rather artificial.
Sure, with server side techniques you can separate text blocks from the basic page structure and drop them in as the page is requested, but what’s the point?
Structure is not about techniques like that; I mean, a bunch of characters become a word once they’re grouped together in a certain structure, words form a sentence once they’re stringed in a certain order, seperated by spaces and/or interpunction. If you take the sentence structure out of the sentence, all you’re left with is words, context-less words.
“Separation” in this context means to me: disentangling one from the other so both can be maintained and altered without – immediately – influencing eachother.
If you try to disentangle the strands of wool that make up a sweater, all you and up with is a bunch of wool; once the structure of the sweater is gone, so is the sweater.
Again, separating presentation from structure/content and behaviour makes good sense to me since they can live separately without harm; separating content from structure does not since that would destroy the meaning of the content and thereby the content itself.
quote:
Again, separating presentation from structure/content and behaviour makes good sense to me since they can live separately without harm; separating content from structure does not since that would destroy the meaning of the content and thereby the content itself.
/quote
I couldn’t agree more. I just finished writing about this on my own site. Essentially, I think content and structure can be separated on an administrative level with a good CMS, but they can not exist without one another at the final page rendering. The behavior and presentation layers, however, are completely optional to functionality.
For those interested (with neat illustrations!): http://www.graphicpush.com/archives/000070.shtml
quote:
Again, separating presentation from structure/content and behaviour makes good sense to me since they can live separately without harm; separating content from structure does not since that would destroy the meaning of the content and thereby the content itself.
/quote
I couldn’t agree more. I just finished writing about this on my own site. Essentially, I think content and structure can be separated on an administrative level with a good CMS, but they can not exist without one another at the final page rendering. The behavior and presentation layers, however, are completely optional to functionality.
For those interested (with neat illustrations!): http://www.graphicpush.com/archives/000070.shtml
To add to Pats point octane8 has over 100 errors! I suggest people try http://urbanmainframe.com and the others that DarkBlue (1st post) has singled out as they all validate! Don’t bother boasting about something you can’t deliver its a waste of all of our time.
>You’re using Javascript to ensure the accessibility of your site?
What’s wrong with that? For image replacement it seems to make perfect sense, at least with javascript you can check to see if it’s supported before changing the presentation.
Great point, and a solution is to use a CMS that stores content “chunks”, not pages and one that allows you to define content structure for different types of content.
liveSTORYBOARD CMS (http://www.livestoryboard.com) does this. It uses schemas to define content types (i.e. generic article, job description, image slide show, etc.) and enables content authors to define and pick the appropriate type for their needs. Content pieces are then assigned to pages, so you can have one or more content piece on a page and they can be of different types.
A few other benefits:
– XML/XSLT/CSS (ideal for separating content and presentation)
– valid pregenerated output (XHTML, HTML, JSP, etc)
– real time wysiwyg editor validation
– “nice” urls such as http://www.sitename.com/dirname/pagename.html as opposed to the more common with content management systems http://www.sitename.com/123?x=a&blah and more 🙂
As one of the developers, I suppose this may be a bit of a shameless plug, but for those interested, here is an example screenshot of some work in progress: http://www.girlsinc-online.org/demo/ExploreAndSucceed/Introduction.html. As a really simple example, this page shows a sample interview screenshot of what’s behind login for this portal project.
The page contains an “intro” XML content piece, first pregenerated with XSLT, then furhter styled with CSS and “question/answer set” type content piece. We use XML schemas for the content types, so a common point of refernce for the semantics and content structure is used throughout a site. Authors edit the xml through a wysiwyg (http://www.livestoryboard.com/Products/Screen_shots.html), so the complexity is hidden from the non-techy CMS user.
Further on the subject, storing your content and templates in XML (XSL is XML) allows you to continuously evolve them over time programatically rather than hand coding. So, as your needs and knowledge evolve, you don’t have to start from scratch.
Looks like the “.” after “http://www.girlsinc-online.org/demo/ExploreAndSucceed/Introduction.html” was made part of the href, therefore breaking the link.
So if one main purpose of separating content from presentation from structure is to allow easier redesigns site across entire sites, I’m curious how often it really happens like that.
I’ve worked on projects where the previous designers worked hard to maintain this philosophy, but in the end, I still had to make drastic changes to the structure in order to achieve the desired presentation.
My experience is that clean markup focused on separation of content, structure, and presentation might make a redesign easier, but in the end, one often ends up having to change up more than they ever expected.
For instance, if a two column site is moving to a three column format, the structure of the two column format will not allow for the new three column structure (99% of the time).
In the end, I believe this philosophy is good, but sees most of the benefit in site-wide changes to presentation rather than changes to structure.
Pat, Aaron,
I did not make any statements about octigon.com and its ability to validate. I’m talking about our next generation web development tool, octane8 version 5.0 Our public website is going to be ported to xhtml strict in a few weeks under our new version of Octane8. The site is currently using version 4 of our software.
As I said, if anyone wants to take an objective test drive of Octane8 version 5 – which will ship in June, drop me an email.
I see we have a Javascript hater on our hands.
MC: “I find this slightly amusing, but correct me if I’m wrong here. You’re using Javascript to ensure the accessibility of your site? Looking beyond the typical computer platforms, do you know how many devices that access the web do not support Javascript, or any kind of scripting, for that matter?”
I find it extremely amusing your article mentioned nothing about seperating behaviour and structure; instead you threw a cigarrete at a hay stack and started this meaningless “content/structure seperation” argument that has, literally, gone “up the wazoo” (note I don’t trust anyone who says the ‘W word’).
I DO know how many devices have no javascript, excluding spam bots and search engine spiders: 2%, if not less.
My javascript solution DOES seem crazy, I know that. But you’ll see there’s a method to my madness once I finish the article about it (and get the technique to work in a certain browser which I will not name).
Please correct me if I am wrong.
I must admit that I too was disappointed in this article. It appeared to be written by someone who has never heard of Content Management Systems or understands what they do and now that the “lights have come on” is recommending that each designer build their own CMS.
Designers are free to do so, but IMHO would be wasting time reinventing the wheel. There are a great many Content Management Systems out there from simple to complex (see http://www.cmsmatrix.org ).
In a CMS “Content” is defined as “the part you will allow someone else to modify/update.” If you are maintaining and updating the site yourself, it might be considered “the part of the page that will be different from page to page”. It is not limited to a discussion of certain html tags. It is an area on that page that the user can modify within certain parameters. Some CMSs like the most excellent Open Source Typo3 ( http://www.typo3.org ) provide a Rich Text editor where the user can choose basic word processor-type controls for justification, bold, italic, etc. However, they can only format the portion(s) of the page for which they have been given privileges.
A site can be made up of multiple templates, and a large site can have multiple “content editors”, but (as the author correctly states) a redesign of the site is easily accomplished by changing the templates (and/or the CSS pages referenced by the templates).
One wishing to “get their feet wet” with a simple example of a CMS could do worse than to look at phpWCMS ( http://www.phpwcms.de ). After you have learned some of the concepts, and are ready for a serious tool, I recommend looking at Typo3 which has been reviewed as the equal of CMS products costing tens of thousands of dollars.
For sites that rely on dynamic content, the separation of content from structure and presentation is a necessity. Tools like PHP allow the content to be managed separately from the presentation and structure.
The further separation of presentation from structure has its own benefits. CSS allows the presentation to be managed separately from the structure and content.
Zope’s Page Templates provide a better alternative to tag-based dynamic content generation tools like PHP. In page templates, instead of adding tags that get replaced by the server, you add parameters to structural html tags that can tell the server to replace the contents of the tag, the tag and its contents, or even other parameters (e.g., class or href). By using parameters to control the dynamic generation of content, the template, with generic content, may be viewed directly in a browser and may be edited with tools like Dreamweaver without messing anything up. This makes it much easier to write and test CSS for dynamic pages.
Page templates don’t do anything to automate the development of CSS, but they make it much easier for those of us who manage content separately (by choice or necessity) to accommodate separate presentation, and they allow the use of other tools that do help with managing presentation.
http://www.zope.org/
I was about to comment on this, but then I just noticed that there are already seven pages of comments for this.
…
There is definitely not that much to say about it…
Your forgot to mention not only seperating behaviour and structure, but behaviour and presentation: http://www.digital-web.com/articles/separating_behavior_and_presentation/
I understand the idea of separating content (including its inherent structure) and presentation. It’s the whole “pure” XML thing that throws me off. Why would anyone want to have there data in an XML document? Why wouldn’t you just use an RDBMS like MySQL? I only have a couple years web experience and don’t know a whole lot about XML, so these questions are not just rhetorical. Give me some answers, if you like.
For a small site it would be easy enough to code the XHTML by hand, no need for a database or XML conversion. And you would afford the opportunity to create an interesting visual presentation rather than just spewing out systematic information. (I am currently doing my personal site with php and MySQL as a learning experience and proof of ability. I know a dynamic site is really uncalled for.)
For a large site on the other hand, systematic information spewing is a necessity. A relational database allows content to be retrieved, entered and updated efficiently. I don’t see how information in an XML document could be retrieved with the same efficiency (I learned SQL in a day or two, it is extremely simple). With XML wouldn’t you need to “read” the entire document every time you wanted to retrieve data? Or would you write multiple XML docs, one for each page of the site? Why not just write XHTML and avoid the whole XSL transformation step?
Data (in database) -> server side script transforms to -> XHTML -> CSS for presentation
— or —
Data (in XML) -> XSL transforms to -> XHTML -> CSS for presentation
Looks like the same number of steps.
Or is the idea:
Data(in database) -> server side script transforms to -> XML -> XSL transforms to -> XHTML -> CSS for presentation
Why the extra steps?
I must be missing something.
XML -> XSLT -> [XHTML, CSS, JavaScript]
XHTML, CSS, and Javascript form a unified whole.
Some responses where quite repetitive of what others actually said already, perhaps reading the article would have been appropriate for those of you.
Otherwise this article was a great introduction (even if it was 5 months old) and for those who didn’t seem to realise soon enough should have given it some thought, as Michael has said already that he never did have the answers to this dilemma and I personally don’t think anyone ever will for a while to come.
There were a few points I came across that I do have remarks to but I don’t have any intentions of making this post add to the ever-growing amount of responses already here, nonetheless I accept that there are methods that ‘attempt’ to do what this article is trying to explain. Although I do believe that content was never meant to be without structure. Its simply there to stay that way. 😀
Separation is a must. Separation of private and work stuff, but even in website’s is it more than usefull!
The lumping together of structure and content kind of struck a bad chord for me, which is why I chose to create my site using PHP. If you look behind the scenes, you will find that all of the page text comes from include files. In here, the creation of an entire entry is simplified down to a string array for settings and then the actual text. I can’t really explain it properly, and I’ll probably find a better way to do it eventually (perhaps even database driven as you pointed out in your article), but I understand what the dilemma is here.
This reminds me a little of the separation model I often advocate for database development projects. The real irony of this article seems to be that it is supposed to be about content and structure, but it seems lacking in both areas.
“Many content management systems provide varying levels of this kind of template support. However, full-featured template systems that make CSS Zen Garden-like usage of stylesheets — especially ones that come with a comprehensive content management system — are few and far between.”
Whilst not as powerful as matrix systems cms, I am surprised that no one has mentioned Dean Allen’s texpattern (though someone did mention
Its free, uses php, produces valid xhtml and uses CSSp.
Very useful article
If you though that was confusing, you should see when I put out an article on my site, zachblog.com
It about the seperation of behavior and CSS, from…everything else. If CSS is supposed to be used for styling only, and not for behavior, what about behavioral style, ala the :hover phesudo element. It styles a behavior, usually used in javascript(onmouseover). So I think thats where it gets REAL sticky…I’m sure someone else has wrote about this, but I’m going to post out my views anyways(NayNay-NayNay-NayNay)
😛
Changed it to TypeSpace(.org)
Wonder how hes going to do that
Thanks for the article… Im new to CSS, XML and stuff, i found the article really helpfulll.. Very well written. 🙂