17 May 2004
Separating Content and Structure
We have been having a lot of talk about ‘separation' of late. And it is not a new topic. Why the new found interest in separation? Are we taking it all a bit too far? Or are we just realising that other modules of web developments such as behavior and structure can also benefit from the separation that style and content has gone through.
Content/Structure and Behavior
I whole heartedly agree with the separation of Structure (including its content) and Behavior. It is only natural to me to want to separate all the javascript from a page when the visual layout (CSS) of the page is also separated. In fact, when first starting to realise the full power of CSS, I hoped I was on the edge of being able to drop javascript all together. I have since come to realise that client side scripting does still have its place, just not for something as trivial as image rollover effects.
The truth is that the javascript functionality of the page quiet often depends on the visual side of a page. If you change the visual layout of the page, the javascript, that was needed to do something (such as hide or display a div) might become null, and thus needs changing or removing. This is much harder to do if 'the Behavior layer', is inside of the structure, as apposed to separate.
I don't need to argue this point really, because other people have already (see links above). And as a side affect of this, people are realising that changing the CSS of a site for a redesign, is going to go hand in hand with changing the javascript. Even Dave S has considered letting people submit a JS file along with the CSS for the CSS Zen Garden.
Separating Content and Structure
Now this is a much stickier subject. The recent article on A List Apart has caused a bit of confusion over the matter. In my opinion the article lost a sense of its goal in the writing, and thus just became confusing. I don't think that the point of the article comes across very well.
On a side note, I get an awful feeling that ALA is loosing sight of its goals in a broader sense also. I do hope that they make some sort of decision soon to go in some particular direction, and stick with it. The latest bunch of articles just smack of being wrote for being wrote sake.
Back to my point though;. I think the point of the ALA article is to show that ideally separating content, from structure would be a good thing. However, complete separation in the sense of separating XHTML, CSS, and JS files is not possible, or not plausible. True, modern browsers will take XML for content, and XSLT for the structure, but using this method now (XML and XSLT on the Client Side), in our day, is moving a bit too far ahead of our time. It will cut off the older browsers, and it will bring in other limitations that I wish not to go into.
So, separating Content and Structure can not, or should not be done at the same level as Style or Behaviour separation. What about behind the scenes, before the content/structure even gets to the user agent? And why should we want to anyway?
Separating the Content from the Structure on the Server Side
This is not a new thing. People have been using database driven websites for years and years now. So at this level, the separation of Content and Structure has been practiced for years already.
Take my blogging system for example. I wrote is myself, so it is only a basic system, and to call it a CMS is not humble really in comparison to other CMS's out there. But for now, it will do.
On my front page, almost all the content is gathered from a database. I use a simple ASP page to import said content into the Structure defined by the ASP itself. This does mean that my structure and Server Side programming are now mixed up, but Content is coming from a different place, and separate.
On the individual entry 'pages' (where the comments are found) the same Structure, or ASP file, is used to call different Content for each entry. Thus, the Content changes, and the Structure remains the same. To change the structure to all the comment 'pages', I only need to change one Structure file. This is simple Content and Stucture separation.
Obviously, though, the main problem with most CMS's is that when they combine the Content with what ever 'templates' the CMS uses, the results are commonly (in a coding and semantic sense) extremely dire. Consider for example the code generated by the CMS that my current employee uses. Invalid is an understatement. I wish I had the ability to do something about that.
There are other reasons why the CMS approach does not always work, and it is not always down to the actual system, but the users. Many reasons have been taken into account already as to Why Content Management Fails.
It is possible, although theoretically, to separate content and structure in a good way using the CMS approach. In fact, I would say that this is the way to go. But few people or companies seem to be able to achieve this at the moment, and even fewer do it well. Why? I don't know. I guess people just need educating.
Why separate in the first place?
I think that one major question asked after reading the ALA article mentioned was "Why should we separate content and structure in the first place?". Is it taking things to far?
When your site is a personal blog, or a small static site without the use of Server Side scripting, then I say maybe. In cases like this, it might be taking things to far.
On the other hand, with a big corporate website (hopefully some of us have these as clients), I say no. One of the major benefits of CSS, and the separating of Style and Content was the ability to redesign with extreme ease. The Zen Garden is good proof that this is indeed possible. But in the real world, most redesigns will call for a rebuild in structure as well as style. And since in most cases, the structure (on the client side) is inevitably entwined with the content, changes can some times be called for in all pages of the website. Changes like these were meant to be done away with thanks to CSS. But things are rarely as good as they seem.
To give you an example of when structural changes will be needed, consider the following structure template:
Now this might look quite familiar, since it is a structure that a lot of bloggers seem to use these days. Now consider that this is the structure of a site that is about to be redesigned. Then consider that the client wants to redesign to be a three column layout. Not only will the style sheet need changing, but the Structure of the documents will need changing also. Into something like this;
And this is why the separation of Structure and Content would be beneficial, especially on a 1000 page site using the old structure.
As anyone who uses a good CMS, or even Dreamweaver templates to a degree, will tell you; It is nice to be able to change one template file, and the structure of all pages change. Just like that. Kind of sounds familiar doesn't it? That is because it is not new. This brings me to ask why ALA brought it up. Maybe they thought that we needed reminding that CSS can help towards easier redesign, but is not the whole answer.
How to improve and educate.
The potential problems and benifits with using Content Management to seperate Content from Structure are outlined above. Albeit in simple terms. So now we need to find the best way of implementing the concept. I personally agree with the folks who say that all content should be kept in a database, or in XML, and that XSLT is a great way of giving that content structure. That way, to change the structure of a site, you only need to change one (or a few) XSLT files. XSLT files then become your template files. I also think that the XSLT and XML should be processed on the server, before it reaches the client, for a most effective result.
This technique should be encouraged in the same way we have been encouraging CSS files to handle the styling of structure and content. It will be harder to do this though, because it will be less visible to the client. Still, lets do what we all know is right, for a better web, and a better developer.
The End
If this entry has given you some new ideas, then that is great. But if this entry is only telling you stuff you already know, then I hope you are not offended. This is meant as a reminder to such readers in my imaginary audience.
- Time: 17:01
- Wubb Development
Comments ( 27 )
Phil Baines
http://www.graphicpush.com/archives/000070.shtml
Richard@Home
Me too...
http://richardathome.no-ip.com/index.php?article_id=227
Andre M.
Very good article
Andre
Gary
This is a fabulous article
Separating data from structure is the last hurdle we need to learn for easy content management.
Phil Baines
Your right, separating data from structure is becoming one of the most important parts of content management. Our (Netring's) own CMS, and other systems, now use XML and XSLT to seperate content from data.
I am hoping to get the chance to write about this more on my blog, but finding the time is always a problem. Work keeps us busy!
cialis
cialis
texas holdem hand odds
texas holdem hand odds
888poker flush 8 or better omaha game
888poker flush 8 or better omaha game
pagerank main
pagerank main<a href=`http://www.dorank.com`
google pr main
google pr main<a href=`http://www.dorank.com`
pagerank main
pagerank main<a href=`http://www.dorank.com`
google pr main
google pr main<a href=`http://www.dorank.com`
mexico xanax
mexico xanax<a href=`http://1-xanax.wol.bz`
cheap valium
cheap valium<a href=`http://1-valium.sbn.bz`
best cialis price
best cialis price<a href=`http://cialis.sbn.bz`
buy cialis
buy cialis<a href=`http://buy-cialis.kazan.bz`
lortab
lortab<a href=`http://1-lortab.sbn.bz`
levitra sales
levitra sales<a href=`http://levitra.kazan.bz`
milf milf
milf milf<a href=`http://milf.sbn.bz`
restaurant soma
restaurant soma<a href=`http://soma1.wol.bz`
convert mp3 wma
convert mp3 wma<a href=`http://mp3.pbnet.ru`
car cheap new
car cheap new<a href=`http://new-cars.kazan.bz`
online-casino
online-casino
Sorry, commenting has been disabled for a while. I am getting a stupid amount of comment spam, and need to find a new way of doing things.
I will not publish your email address, but I may use it to get in contact with you.
HTML tags and entities display as source; they do not render. To create a live link, simply type the URL (including http://).