David Dylan Jessurun: The Sci-Fi of CMS templates

The Sci-Fi of CMS templates

Introduction

In this article I want to take a look at building CMS templates.

Content Management Systems are becoming the norm when building websites. In fact, I always recommend that whatever type of site you build, you always build it on a CMS. There are many flavours to choose from, from very simple to extremely complex, from free to extremely expensive. Which one you choose depends on your needs, now and maybe later.

Which CMS to choose goes beyond the scope of this article, what I’m going to delve into is how to code effectively for templates/CMS. This is not an HTML tutorial, but rather an outline of a way of working which has, and still does, serve(d) me well.

As a true geek and collector of Sci Fi books, I’m going to go with an SF themed analogy to clarify matters. I hope it helps to explain my thinking, if it doesn’t I suggest you watch more Star Trek. Anyway, before I can begin to explain my method, I must explain why it is necessary. It’s all about two things: speeding up development by working in a structured and efficient manner, precluding as many frustrating issues as possible by coding defensively against browser issues and project scope changes. And it is about psychology. Anticipating the behaviour of those who will later be maintaining and/or using your site, and coding defensively (see a trend?) against that as well.

There are, in a nutshell, two reasons why CMS-es have started becoming the norm:

• Websites are increasingly complex and need more and more underlying functionality.
• Websites are increasingly maintained by non-developers.

This, in turn, gives rise to a need to:

• Speed up and simplify development, something many CMS-es can facilitate because they offer plug & play functionality in the form of plugins and addons.
• A standardized interface useable by non-experts for the maintenance of content.
• Bullet-proof your site against human error, a common side-effect of having site-maintainers use a standardized interface.

I will introduce several concepts for your consideration. These are, in summary:

• Working from general towards the specific
• Separation of code “layers”:
  Orbit (the browser, HTML/BODY, or where your site lives.)
  Structural (The frame upon which your site is built.)
  Modules (The several content items which fill your site)
  Nodes (The items filling your Modules)

I think these concepts ‘do the trick’. I hope you will take all, or some, of my suggestions on board. If not, I’d love to hear your reasoning as to why not. I’m writing this as much to order my own thoughts (and learn) as to share and enlighten.
Well, if you are still with me, and perhaps waiting for the Sci Fi to start, let’s go ahead with the main reason I think this method is useful; people.

Of Redshirts and Captains

We are going to look at what your code is going to be able to withstand. Let’s assume your client (or employer) is the captain. He tells you to produce him a website, perhaps he assembles an away team, maybe you are on your own. In any case, there you are with your yellow shirt on, facing a rather big task.

You know the captain is a fickle man. He gave you specifications now, but those might well change (several times) during development. You also know that the ones who are going to be maintaining your site are redshirts, nice enough folks but no astro physicists.

So, you need a CMS. A nice interface for your redshirts to use, so they can maintain the site in between sessions of getting killed on alien planets without having to know too much HTML. You also figure that it would save you a lot of time if you could just drop in addons and plugins every time the captain wants another cute extra he didn’t mention during the mission briefing.

What you also know is that redshirts don’t like being redshirts. Getting killed on alien planets is no fun, the pay isn’t grand and it’s not all that good for picking up alien women/men, either. You just know they are going to try and do things you neither anticipated nor would allow them to, like play designer and try to centre text, add images where they don’t belong (300 Dpi, if you are particularly unlucky) and so on. It’s not that they are malicious as such (more about that later) but they suffer from a condition that affects all of us to some degree: the “I can do this myself” disease.

Another thing you know is that while addons and plugins may save you a lot of development time, they are by their very nature made to be the Neelixes of coding; friends to all, tolerable to none. They will, not may but will, produce output code which in some way shape or form conflicts with your code. If you don’t anticipate this, and anticipate it well, this may cause the plugins to cost you more time than just coding the darn functionality yourself, and that would defeat the point.

So, you pick a CMS. Which one is beyond the scope of this article, but lets assume it is a well-known one and you are familiar with it. It’s also a halfway sane one (because there are a lot of bad ones out there) which lets you employ the structure discussed in the introduction. You have the Information Architecture, the look & feel and the other pre-code issues thought out (if not, then you are approaching this thing the wrong way around). OK, great, so let’s sit back and think about what it is you want to achieve and how this CMS is going to help you, rather than fight you.

What makes working with a CMS different

Let’s look at what a CMS “does”. In essence a CMS offers a set of templates, standard HTML/CSS definitions, some of which provide the basic page layout, others define how loose content items (a menu, a bit of text, etc.) look and behave.

In the olden days a site would be built as a collection of pages. You would think of the site as a tree-structure, with an entry point (the “home” page) at the top and underlying pages branching off from there in “levels”. But in the olden days a website was fairly static. Updates, if any at all, consisted of adding a page or changing some images and text every now and then. Simple changes you could do yourself, or leave to a “webmaster” working for the client. Changes would be done straight in the HTML document.

Modern websites are more thought of as a collection of “nodes” which interact in different ways. Some “nodes”, like a menu, may appear on all pages, and hold sub-nodes (menu items), which travel with it across all the pages in different configurations. Other nodes may not travel to different pages, but may be linked to each other, like a blurb on one page, leading to a full article on another.

These days websites are updated frequently, expanded upon and increasingly use external sources of content such as RSS feeds. A CMS primarily makes it possible to separate the actual code from the content so that those who maintain the site don’t have to be designers, developers and copywriters all rolled into one. The upshots of this are discussed below, but the disadvantage is that the site maintainers are going to be, at best, copywriters. More often than not they aren’t even that. The more websites are updated, the more hours a business needs to budget for, so they want those hours to be cheap. As a result we have a very real, situation of more time spent maintaining site content, by progressively cheaper labour.

This is by no means a bad thing. Gone are the days we needed to know it all, and good riddance. A designer is not a coder, coders are not marketers and marketers are not copywriters. This development allows us to specialize, and each of us to do what we do best.

But it does mean that we inversely also can’t expect website maintainers to be as at home with the underlying technology and theory as the ones who built the site. They are redshirts, or yellow shirts with a different specialisation. In any case, either we help them do their job proactively, or we lose our margin providing support retroactively. The choice seems clear.

So while websites become increasingly interactive, flexible and adaptive, a development driven by the advent and continuing sophistication of CMS systems, we also need to change our thinking about site development. We are no longer providing a finished product, but rather a sophisticated platform upon which others are going to build, and keep building for years to come.

A tree structure doesn’t really work for this situation. Maybe if you could visualise it in 3D you could effectively model a modern site, but we humans are not good at thinking in 3D, so let’s try to keep it simple.

Let’s use instead the (flawed but useable) analogy of a space station. If you have ever played Sid Meyer’s Civilization, or the great Open Source spin-off FreeCiv, you’ll have built a space station at the end to win the game. You had different cities working to build, and put into space, the different components of your spacecraft.

This is much the same for many modern websites; content arrives on the site from a multitude of sources, from RSS feeds, to ads from an adserver to different kinds of input from users and site maintainers.

Also, your content is going to be developed outside of context. Or, in other words: people are going to be producing content, and the first time this content is seen performing within it’s context (the site) is when it is published. It is essential therefore that the site can ‘take this’ without errors in modules breaking the site, to as great a degree as possible.

While an unclosed DIV will break any site, some rogue inline CSS or a box with weird dimensioning should not.

To stick with the space station:

There is the orbit. The great outdoors. The World Wide Web. You have little if any control over this. More about this later.

First you put up in orbit a set of structural beams, intended to serve as support, and only as support for the modules that will be hung on them. These beams therefore need to do only two things: provide a basic frame for the rest of the station, and be ready to fit anything and everything that comes later. This is not a lot, but it needs to do it very well, so the beams have to be strong and well affixed, and they have to be as unobtrusive as possible, as to not impose themselves upon the later structure and force the builders to adapt to the framework.

Then come the modules, engines, living quarters, a shuttle-pad and a gun platform to ward of those pesky Cardassians. These do a little bit more. They provide space for basic, predefined functionalities and specific uses. They can afford to, because they can be moved around on the framework. Need more sonic showers for the newly formed girl’s space-soccer team? Sure, blast one up here and we’ll attach it. The captain is upset he has no view of Earth through his office window? Unscrew his office module and reattach it on the other side.
This should work, regardless of the fact that the only sonic shower factory is in Utah, while the captain’s office was built and outfitted by the “Sacre Bleu” design group in Paris.

Inside the modules come the basic fittings; light fixtures, a towel-rack, the captain’s collection of 19th century erotic figurines…
These elements should be safe to put anywhere, without them compromising the structural integrity of the station as a whole, simply because they are at least one layer removed from the actual structure. Maybe it would be silly to have a towel rack in the captain’s office, but that is inconsequential. The point is that, on this level, it should be of no consequence to the station’s structure that there’s no towel rack in the captain’s office, because if you ever need a set of showers where the office is now, you move the office elsewhere and the shower-module in it’s place.

The Hierarchy recapped

Orbit: Quite simply, anything outside the HTML tag, or even the BODY tag.

Structural: The starting point of any set of templates, therefore, is the structure or the structurals as I will all them in keeping with FreeCiv terminology.

Modules: Your station is going to need different “modules”, each with different tasks and behaviours. In FreeCiv those are living quarters for your astronauts, propulsion modules so the thing can move, and so on. All these modules “hook on” to your structural, and each other.

Nodes: FreeCiv is fairly simplistic, but we can extrapolate that modules themselves are made up of smaller modules. Living quarters may offer a bedroom (or pod), a workspace, maybe a sonic shower such as Star Trek invented to give us semi-nude shots of B’Elana Torres. And so on. Let’s call those sub-modules “nodes”. (Not the best use of the term, but I want to keep this simple.) These nodes live inside a structural, which defines the module. (Dizzy yet?)

Since these different elements, have a very different role in the whole; your templates are going to need a very strict separation between the four:

• Orbit: Something you have no control over. The cold of space, to be kept out.
• Structurals: Provide a basic page layout of squares.
• Modules: Provide building blocks, which you slot into the structurals.
• Nodes: Provide the content of the modules.

In essence these live inside a very strict hierarchy. It is essential to keep to this hierarchy or your site will become a mess of patchwork solutions, which the aforementioned redshirts / yellowshirts can’t work with. Actually, many have been the times when I couldn’t even untangle the mess a website had become. Nodes should not be able to break modules, modules should not be able to break the structurals.

Many CMS-es already impose this way of thinking to a greater or lesser degree. This is good, but I’ve seen many, too many, cases where developers and designers “hacked” the CMS to get around this, because they were forcing the CMS to their design, rather than the other way around.

There are also, unfortunately, quite a few CMS-es around who ignore, or even make impossible, this structure. Most of them commercial products, but a few popular open-source ones, too. Let me take this opportunity to call upon those developers responsible to reconsider. There are more, but I’m especially looking at WordPress. (Breaking my rule of not naming names because WP is especially egregious in this respect, and quite popular.)

In practice, a very simple proof off concept

Back to the job at hand, the captain wants you to build a site for the new space-soccer girls’ team. His nephew made a design in SpacePaint3000, and you’re given “free reign”. (Which never means do-what-you-like, but that’s a gripe for another day.)

Now, this design needs to be turned into a template for a website. Assuming that the Information Architecture has been thought out and you are fairly clear on the content and features of the site, you can start to code from this example.

First things first, CSS reset

Different browsers still handle things differently, so what you need to do first is create a truly empty canvas, so to say. You may feel that you don’t need this because you know enough about all the browser quirks. So do I, sometimes. But the thing is that you aren’t coding just for you. Your code might very well be handed off to someone else later. That’s the point about a CMS; it facilitates easy editing and even when your template won’t be edited by anyone but you, the actual content may well be updated and maintained by someone else. At least, in an ideal world that is how things work. Designers design, Developers develop, Webmasters master and content managers put stuff online.

Most importantly: You may well find that the CMS, even if you pick one yourself, imposes some coding scheme which presents you with hard to solve cross-browser issues.

So we are going to “reset” the CSS. This means, in practical terms, that you ‘turn off’ all formatting which browsers normally assume without consulting you; standard margins, padding, font-size, etc. Whatever else browsers disagree on, zero is a number none of them can misinterpret. (With the possible exception of IE 6.)

Your code may look like this: (many thanks to www.meyerweb.com)

Like I said before, all this does is throw in any HTML element you can think of and turn off any proprietary formatting browsers may otherwise give them.

Predefine standard behaviour

The next thing to do is to define any what I will call “behaviour” that you are going to need more than once. In effect you are going to take your blank canvas and set up your own rules in place of the ones you just discarded.

Behaviour: Structural elements

First things first, you are going to need a structure to keep your content in. Think of this as a series of guides, or a “cage” to keep all elements on your site in place. This is a good way to work, CMS or no.

Remember the principle of separation of structurals, modules and nodes. You may feel that your CSS reset has done most of your work for you, but keep in mind that later developers, maintainers and even you yourself, may inadvertently or out of pragmatism introduce formatting which may be handed back down to your lower-level code. For example: I once needed to get around a particularly tricky issue with a CMS. This CMS had some pretty strict restrictions to what you could do and where. It’s too much to explain here. I’ll just give you what I did to get around it; I used regular input fields to open, and close, my HTML in a column above and below a fairly strictly defined area where it was allowed to place JavaScript. Then I put my JavaScript in that area. Together they provided a “module” as we use the term here, even though in fact the code snippets each lived in different parts of the “structural”. I’ll try to visualize:

This neatly serves as an example of wrong thinking about CMS systems. But that is not why I’m showing you this. The point is that I had unclosed HTML in the top area. CSS applied to that code therefore could be handed down (inherited) to the code making up the middle structural.

Of course, smart CSS coding will prevent this. But it caused quite a few headaches and I feel sorry for the guy who maintains the site now. I did comment extensively, of course. But still.

So we can’t assume that our “reset” will keep doing the trick. This is why we are going to build a very rigid set of tools, standard behaviors, which will live in their own section of the CSS. Perhaps even a separate CSS document, which you give later maintainers no access to, if you are particularly paranoid. (With good reason, many were the days when most of the day was spent fixing problems introduced by content maintainers with dreams of developer-stardom.)

We are going to use the much-maligned “!important” element to make extra sure that no fancy inline CSS trickery will ever override these standard behaviors.

Defensive coding Coding for a CMS is as much coding for the way a CMS ‘works’ as it is about anticipating how humans ‘work’. It’s about defensive coding. Assume users, maintainers and other developers are malicious. Not because they generally are but because stupidity, laziness and over confidence in people with a basic understanding, at best, of HTML and CSS produces the same effects as willful maliciousness.

So I define a class I universally dub “struct” for “structural”.

The second line defines a border; I do this because I’m a designer by origin and as such a very visual thinker. I like to see what I’m building. I added a comment /* remove */ so I can simply search for “remove” later on to get rid of all the instances where I did this.

As you can see, we’ve simply made sure that any element we are later going to tag as “struct” will not have any margin or padding. You may be tempted to think of your structurals as a layout grid which also provides your white space but don’t. You see; later modules may well be copy & paste code and bring with them their own rules for padding and margin, and you’ll be introducing exception upon exception just to keep your gutters and borders uniform.

Let’s release this in the wild and start setting up our basic structurals

I’m keeping things fairly simple for demonstration purposes, so don’t adopt my class naming scheme. Do note that I am prefixing all my class names with “ex”. In this case this simply stands for “example”. Prefixing your class names with some sort of unique identifier (I use an abbreviation of the project name) prevents problems later on when maintainers copy & paste in code which may use your same chosen naming scheme and therefore the same class names you chose.

Note that I’m not using Id’s. Id’s are often used by a CMS itself, or (amongst others) JavaScript so it’s a good idea to not use them for your styling.

Now, to set up the basic layout we use simple CSS. Remember to not introduce any styling at this point. We are just setting up a structure here. (I would say “grid” but the term is used for some horrible coding practices I absolutely abhor, so to prevent being thought of as a proponent of these monstrosities I’m avoiding use of the word.)

The CSS

This is obviously a very simple example, but I really can’t show you every possible situation.

There are a few things to watch out for, though:

• Over-sectioning: You are only setting up the structural beams of the building here. If you find yourself treating dividing walls, doors and windows as structurals, you’ve gone overboard.
• Under-sectioning: You do not know what your structure will be asked to hold, elements may have decent markup or they may not. While I’m all for fluid design and not deciding for the viewport how to display content, some safeguards are needed. You can’t rely on later maintainers being able, or inclined, to fix code issues or cross-browser differences, existing or new. So make sure your site has clearly delineated areas for different kinds of content, like a menu, ad space, etc.

In my example I’ve chosen to use three common types of structural; the top-bar, the menu area (In this case horizontal to keep the number of (nested) DIV’s needed to a minimum, and my code examples short) and a general content area.

The rule of thumb is to treat everything that might conceivably be changed, replaced or moved while not in the course of an actual site redesign as not structural.

Often, also, your CMS gives some definite hints as to what is structural, and what is not.
Ideally your templates should contain only structural elements with everything else defined as loose ‘building stones’ sometimes called ‘views’ or ‘free HTML blocks’.

So, assuming your CMS uses replacement tags, your code could look something like this:

At this point you test, and test again to make sure your code is solid and cross-browser compatible. Once you are sure of this, you can move on to the modules fairly secure in the knowledge that you can develop them outside of the context you set up here, and not break your site structure.

Behaviour: modules

Since we are taking away from the structurals any task that is not strictly structural, it befalls the modules to provide most of what people tend to think of as “design” or “layout”, including white space. Fortunately, the predefined-behaviours approach serves us very well, here, too.

In my example I’m going to want ten pixels of white space around all content items. People who still have one foot in the print world will now rally: “but, how do we put the white space between the elements without more structurals, and without styling them?”

Simple; we do not. Remember; we are going to think of our modules as segments of our space station; they screw on to the structural and beyond that they are entirely self-contained. So we are not putting our content between borders and margins, we are going to inverse our thinking entirely, and going to put our white space around our modules, like a protective force field.

Before I go on here, I want to revisit what I wrote about the CSS box model in my article “Padding the Margin” (http://www.defcon0.com/padding-the-margin/):

As you can see, or if you can’t, what I’ve drawn here is three boxes inside each other. The inner box is the padding, and will contain your content. The middle box is the border and can be used for styling edges and borders. It is often thought of as the actual boundary of the box, but this is not true. The outer box is the margin.
Now, to help you think about this in a helpful way, I’ll simplify matters by stating that the padding works inwards. It pushes content away from the border. Margin works outwards, it pushes other elements away from your box.

The box model

Since we want ten pixels around all content items, we give the modules a margin (protective force field) of five pixels. When two of them meet, those add up to ten. Simple, no?

If there are more known and unchangeable attributes that apply to all modules, or most of them, you can predefine them here too. The few outliers you will doubtless have further down the road can get overriding individual rules.

Mind the hierarchy: from general to specific.

Of course this introduces an issue when a module rests against a structural border, and not another module, like when it sits up against the side of the viewport. You could solve this by instead doing this:

Since usually, in our right-to-left reading world modules will float upwards and to the left, this solves the issue. For this example, I’m just sticking with the simple way and not mind about the occasional five pixel margin.

There are many more behaviours you could (should) pre-define this way, for example, I often define several levels of z-index. (See insert.) The object is to write code once, use it often, and to chisel the basic styling in stone where no maintainer can screw it up later.

Many CMS-es allow you to define what code maintainers can, and cannot insert in the site, but you can’t limit them too much because copy & paste code is becoming more and more prevalent, and everybody will be happy with your work right up to the point where the boss’ secretary can’t enter the copy & paste code for that funny YouTube video in the site. ( I wish I was joking here.)

Note the !important. Use it. Thank me later.

In my example, all modules float left. So, for the example page, the final code looks like this:

Just for display purposes I’ve defined the modules pretty uniformly, and rigidly. In the wild, this won’t usually be the case, of course.

This wraps up the modules, in a nutshell.

Backtracking: The orbit

Before we go on to the nodes, which should be simple, if a lot of work, we need to address one layer I didn’t say much about yet.

You may have noted that I added a “container” DIV and didn’t say much about it. There’s a reason for that: separation. We are treating everything as ‘layers’. Right now we have the following separate entities, which we insulated from each other as best we can:

• Structurals
• Modules
• Nodes

There’s a third layer: the orbit. This is the context within which the entire site is going to live when a user views it, usually thought of as the browser but in these days of increasing diversification of web-enabled devices, it could be anything. People might view your site on a mobile phone, a regular computer but I’ve seen music players with web-capabilities, even ’smart’ fridges. Since this layer is largely an unknown, it is best to stick with our principle of separation, and leave it alone.

In practical terms this means resetting our CSS (which we did) and from there on creating our own canvas rather than trying to anticipate what the orbit is going to do. So, our layers are:

• Orbit
• Structurals
• Modules
• Nodes

In that order.

By adding the container DIV we in essence are creating a super-structural to do all the stuff with we, in the olden days, would do to the HTML and BODY elements.

Obviously our container is the most generic element we have and it’s going to take all the styling we want applied to the entire document throughout. Which styles should that be?

Well, looking at our design, we can identify some specific styles, and some generic. These will vary from design to design, so there is no absolute rule. But at the very least you should catch all elements that later maintainers could screw up by omission.

To give an example: If you style all modules to have a certain font and font size associated with them, then you are targeting a generic class (if you stick to my method, that is), but what if a later maintainer leaves out the class, or omits wrapping some text in a container element altogether? This would be wrong and grounds for a few days in the brig, but it would still have happened.

So, we specify a generic font definition. The same goes for headers, anchors, etcetera. I’ll keep things condensed, so my code example is not going to be exhaustive.

As you can see, I’ve defined the same style for just the container and the P element within the container. All text should be wrapped in P’s, but a maintainer may well forget this, so we anticipate and catch.

The h1 was styled with a font size of 1.6 em. Since the H element runs from 1 to 6, it makes sense to respect the logic of this regression; so starting with 1.6 you can work your way down to 1.0 and keep a logical hierarchy. Pragmatism may lead you to other choices, but whenever you can, respect the semantic order of the elements, your SEO results, usability score and future-proof-ness will be all the better for it.

Behaviour: nodes

Uniformity

It is a useful habit to get used to conventions, even if they are ones you thought up yourself. They help you debug, work faster and keep track of what your code does.

I also define some standard behaviours I expect to be using often. For example:
Struct: Structural elements.
Transpa: Elements with background transparent (not opacity filters).
Absbottom: z-index 0.
Bottom: z-index 10.
Mid: z-index 50.
Top: z-index 99.
Abstop: z-index 100.

This example comes from a site which used AJAX extensively, and the AJAX-fetishist working “with” me (sorry if I sound bitter) was entirely self-taught and couldn’t, or wouldn’t re-code to suit my more sane coding practices. So, I needed a lot of trickery with, amongst others, z-index to get stuff to work.

I mention this not to have a dig at this guy, he’s out of my professional life and that’s it as far as I’m concerned, but because this is a reality you will get to deal with if you work in this profession any length of time. Predefined “behavior” saves you a lot of coding time in such situations.

I also prefix all my custom class names with an abbreviation of the site name. Like so:
Defc0_classname.

This prevents accidents when you, or the next guy, use(s) CSS belonging to, for example, widgets or other copy-in elements which are so popular in this web 2.0 age.

The nodes are going to be entered by the maintainers. This might be you, it might be someone else. Down the line it is very likely going to be someone else, or at least more people besides you. (You do aim for growth, right?)

The rule here is quite simple, as far as HTML goes; code all nodes as stand-alone units. So, give all nodes a container DIV or comparable element (avoid DIVitis, if a module has a block level element of it’s own, like an OL, use that) and call them .module. If you need more specific styling, add an individual identifier. Never add modules as “open” HTML, so no text without P, etcetera. Always assume that whatever internal structure a module needs, it brings with it.

When you are satisfied every type of module you need has been defined, it is time to identify the most common nodes, their basic styling and apply a ‘catchall’ for the rest.
Like I said before, if the site hasn’t been planned in detail yet, you are jumping the gun. So I’m going to assume you have some sort of style guide to work from.

Since we are working from the general towards the specific, we start with the catchall styles.

This means first deciding what the most common elements are generally going to look like. This means; The P, the H1 through 6, the anchors, and so on.

Then you identify the exceptions. Maybe the menu uses a different font, or some elements have a different background. See how many of those you can lump into one group, and create ‘catchalls’ for those.

Then, and only then, start on the specific extra classes you need for truly unique items, and style those.

What you’ll be left with, if you followed the rules I set out in this article is a condensed stylesheet and HTML templates with some exceptionally long trains of class names, but that’s a small price to pay in my humble opinion.

User roles

I put this last, because it wouldn’t make sense without the information given in this article, but you do this first: Set up user roles. Set up the hierarchy of the CMS items to compare as closely to the structure I outlined as possible. Give meaningful names to modules and make sure to only allow editing of those items that maintainers need to edit. If your CMS can hide items users have no rights for, all the better.

With your style-guide, design or briefing in hand, define all types of content as exhaustively as possible and make them available as standard content-items. Then exclude all HTML you can get away with.

Ideally maintainers enter no HTML at all, but usually you’ll have to at least allow them the italic, strong, list and list-item tags. If coloured text might be called for, set up classes for SPAN with common colour associated to them. Don’t “force” maintainers to use tricks like using deprecated FONT tags and the like.

They will still try, but just put yourself in their shoes, and anticipate.

To recap, you have:

• Separated structure from content, and super-structure from modular structure.
• Condensed your CSS for easy maintainability.
• Structured your code from the generic to the specific.
• Cut up your content into single units that are easy to replace, move around and edit.
• Structured your CMS to be easily navigated by others than you.

Now all that is left is to enter code and content (dummy or otherwise) in the CMS, comment, comment and comment more. If applicable, to provide a user-editable css document, and put your CSS somewhere on the server where unauthorized personnel can’t get at it. Oh, and fix remaining cross-browser issues, obviously.

Happy web-building!

No Comments yet.