Whilst this can be seen as a problem for accessibility, in full database-driven sites the page output would change for different types access, and would work around limitations of relying HTML and CSS with regard to problems such as the best placement of navigation on the page.

Page styling - CSS

The third layer of separation is the page style through CSS. The need for CSS to separate display from content is well rehearsed. An HTML page with a predefined structure can be transformed completely, just by switching the CSS without touching the HTML (eg www.notanant.com/templates).

However, many designers try to separate HTML and CSS, only to tie the CSS to explicit pieces of content so tightly that there is no way of changing the content without changing the CSS, for instance using a slight bit of extra padding under a certain paragraph, or a change in font-size for a specific piece of navigational text. This is not proper content separation.

In a dynamic site, the CSS works with the page structure and not expect any particular piece of content to be present except in designer controller areas. The CSS ultimately has to style the sections and areas of the page without reference to their contents. This works by considering the page as a series of layers each sitting one on top of the other. Each layer gets a particular styling, rather than each element. Thus a sidebar sits 'on top' of the 'main area' which sits on top of the page area, which sits on top of the window.

Because the content is in user control, designers should avoid absolute positioning, and explicit definitions of both height and width for areas that hold text. It is normally not a problem to set explicit widths for columns for example, so long as the width is not too narrow.

Checks should be made that extending or worse shrinking the browser window do not cause text to flow over images or text to flow over text, particularly where text size is overridden in the browser. These hidden float problems should also be treated as accessibility issues.

To relate the CSS to the page structure, it is advisable to target all the CSS through the class attribute, rather than an id. Id's are shorter and often easier to read, but technically each should exist only once on the page meaning classes give more flexibility and less specificity. In addition, when the interactive layer is added, it allows the id attribute to be reserved for use by Javascript or Ajax in terms of including or updating content dynamically.

Page Interaction - AJAX

The fourth layer of separation is the interaction layer. Most of the time this means Javascript and Ajax. Examples include edit-in-place, type ahead, dynamic loading of elements, in-page tabs, editors, slideshows and drag-and-drop controls.

Though both Javascript is in widespread use, it cannot be assumed that it will be present and any Ajax may not be able to connect to the server to bring in data so default, non-JS, actions must be available. Good practice means defining the page so it works without interaction, then adding interaction on top. For instance where items are being shown or hidden, their default should be show, with Javascript hiding them onLoad.

Javascript should be in separate .js files and interact with the page via the events model, rather than using inline onclick type methods as this degrades gracefully and allows for content to have events attached to it (eg on links) automatically with requiring the content generator to add them.

Actions are attached to specific ids or classes of elements using the events model (the name attribute cannot be used with DIVs or outside forms). In addition, once an action is in process the specific element changed or altered may need to be referenced directly. Consequently in the page structure, reserve the 'id' attribute for use with Javascript and use two separate classes to mark up key structures. One to attach the styling for the CSS, and the second to attach the action which is related to function. In this way elements with the same functionality can exist in several places on the page.

One problem with this events model is that if variables needs to be passed back to a database that differ for each element, coding the variables into the elements can be complex as there are no easy parameter attributes for page elements. The only possible mechanism is to use the ID, but recognise that only a limited character set can be used.

Site structure

The fifth of the layers is the site structure, although strictly speaking this should be considered first as it directly affects the navigational elements and flow of the site. Many designers first task is to create a skeleton design showing where and how pages should link together based on all the things that can be thought of today.

For static sites the skeleton often fixes the design. However, for dynamic sites, the site-structure has to be open. That is there has to be space for users to add and extend content. It may be that certain elements are fixed into sections, but within a section, content may need to be added, and in other cases additional sections may need to be created continually.

The open-ended structure means navigational elements may change or grow over time. This itself brings the serious problem of link spaghetti. It is not uncommon to see cases where a site has to be completely or partially rebuilt and re-upload just because one new page has been added and back links needed to be added into menus.

For dynamic sites, this is the point at which static HTML based solutions start to become unworkable in the longer term. Simply building and unbuilding the link structure reduces any ability for the site to be fully dynamic and complex sites with a matrix structure such as a magazine type site with pages by date and by subject are extremely difficult to manage within static HTML.

This is where proper content management systems come into their own. Good content management should allow a site to grow and extend, whilst managing all the navigation, linking and menuing automatically allowing the users to focus on the content within the design and structure created by the webdesigner. In this way, sites become living embodiments of the businesses they represent creating a more engaging experience with customers.

About the Author

Saul Dobney is chief designer and architect of Notanant Web2.0 web-engine www.notanant.com that combines CMS, social networking and e-commerce. You can try a free website to see some of the principles in the article at work.