Recently published

Practice notes

Home arrow Blog arrow Integrating web resources

Integrating web resources

Semantic markup is a very healthy development. But it's giving me some headaches figuring out how best to handle its ramifications for something like a Content Management System (CMS) or any other system that integrates web material from multiple sources.

semantic markup is intended to clarify the meaning of the document

To recap the basic principle, semantic markup means approaching HTML (usually XHTML nowadays) on the principle that it should not contain anything that is not to do with the meaning of the document. Indeed, semantic markup is intended to clarify the meaning of the document, by such simple devices as identifying headings, and clearly indicating their level. By contrast, semantic markup avoids, for example, the use of tables for purely positioning purposes, as opposed to display something that just is best described as tabular data.

All well and good so far, and the HTML document should be pretty readable, however it is communicated to the reader, including methods used by people who are unable to access a standard browser. Things being what they are, most web sites certainly will not stop there though. Presentation has never been more important, given the huge variety of competing material that floods the Web.

Naturally semantic markup puts more weight on CSS, since it aims to eliminate use of HTML for positioning or styling. The whole layout of the screen is likely to depend critically on the CSS, for example to position a series of <div /> elements alongside one another, rather than allowing the default of each one appearing further below its predecessor.

CSS is fulfilling two purposes now

This is where I start to see a problem. Although it is difficult to confidently draw a dividing line, it is fairly clear that CSS is fulfilling two purposes now. One is to create the page layout by manipulating elements and positioning them in relation to one another. The other is the traditional CSS role of specifying stylistic elements such as choice of font, color of text, decoration of links and such like.

Why is this a problem? Because when material is aggregated on a single site, for example as part of a CMS, the aim is normally to impose a site design on everything, and therefore much of the styling CSS is expected to belong to the site as a whole, and not to the various elements that are being aggregated. On the other hand, the positioning CSS is specific to an element, and will not normally be part of the overall site CSS.

What is more, if material that is being aggregated into a site was not designed specifically for that purpose, but was instead meant to be able to function stand alone, it is unlikely that any thought has been given to this issue. It is very likely that the material will have a single CSS file (it may have a few, but they may not be split between positioning and styling CSS). Indeed efficiency experts advocate the use of the fewest possible number of HTTP requests to make up a web page and therefore advocate use of a single CSS file.

later CSS overrides earlier

Some relief from the problem is provided by the fact that later CSS overrides earlier. So, provided the site's styling CSS is placed later than the CSS for individual portions of the page, then the site styling will override the more specific styling applied to the included material. But this is not a very robust solution, and is liable to founder on more complex markups such as CSS images used to create attractive headings, where techniques used at one level may react badly to being overriden with another, different scheme.

Issues of this kind are particularly messy where the CMS has a theming system so that individual site administrators can choose to replace the default theme with a choice of many others. In this situation the CMS designer who is attempting to integrate a variety of HTML resources has very limited control over the environment.

Clearly, one solution would be the introduction of more standards, and possibly further refinements in the way CSS is written and incorporated into pages. How much we can pin our hopes to developments of that kind is uncertain. CSS developments are currently uncertain, and in many cases hotly disputed. Creating good standards and persuading people to adopt them both look like substantial problems.

RESTful services

One route that looks appealing to me does involve rather more work than any scheme that simply incorporates CSS/HTML into a wider scheme, such as a CMS. That is to convert stand alone systems into RESTful services so that they can be utilised by a variety of different clients that can cope with the vagaries of widely different environments. But this clearly involves finding an API within the target system and turning it into RESTful services, preferably maintaing a Resource Oriented Approach.

For the moment, my position is that I can do little more than describe what I see as the problem. Maybe answers will be forthcoming. I'll certainly be interested to see.

#128004 • 08/23/2008 6:05pm by Martin Brampton • Vote: Up votes (727) Down votes (526)

blog comments powered by Disqus