http://www.barry.pearson.name/articles/content_presentation.htm

It about “mark-up versus presentation”. In other words, put your presentation into the content, or add it later with CSS, but don’t do it in the mark-up. (I hope people don’t think that “content” equals “text”?)

Second, although this wasn’t necessarily a key theme here, there are some misleading and indeed mischievous staements made about the “tableless” page-formatting principles. These are useful new tools, but that doesn’t mean that they are in any sense “the way to go”. They are simply yet another tool to be evaluated along with the others. I am working on this, comparing various approaches, but an initial (repeat – initial) view is expressed at:

http://www.barry.pearson.name/articles/table_pages.htm

I note that some of the arguments I used in that page have been better expressed in this forum! Especially by anyone who talks about presentation applying to the content available, and not being something independent.

A third theme I am working on at the moment is that I, and many others, tend to put material onto a single axis, something like “information rich” to “artistic”. I also think that I am guided about where the author thinks material should be on that axis by how artistic it appears, since that is the easiest to see. So if it is artistic, I don’t even expect it to be information rich.

When I look at the CSS Zen Garden site, I don’t bother to look at the text in the examples, because these are works of art, surely not information-containers? I wouldn’t bother with something that purported to be an academic paper but was overly concerned with artistic presentation.

What you’re talking about is separating content from structure, and structure from style.

structure + style = presentation

The three (content, structure, presentation) are very much separate entities, but they are tied together at the core. Structure is dependant upon available content, and presentation (at its best) must take both structure and content into account. However, in order to acheive an appropriate presentational effect, content and structure may have to be altered to accomodate.

In exploring these thoughts, it truly is very similar to the detail and care given to typesetting and design before the age of digitally-aided Desktop Publishing. If a line of text dropped a widow or orphan to the line below, text (content) had to be edited for the sake of design–either to drop a word to remove the widow, or to add text in order to push the line further across the containing column.

This reliance upon each other, ultimately, is a good thing for web design. The three are distinct and at the same time bound. If properly realized, this should lead to thoughtful and brilliant design.

XML and XSLT are certainly tools that can help seperate structure from presentation.

This is something that can often be overlooked by web designers when they utilize style (presentation) in spite of the content, rather than to present the content in a usable way.

In my own experience, I run into this problem when I am asked to design banner ads before the copy is written. It is assumed that the text can just be added to the design afterwards. What they are missing is that the copy, for the most part, is the design.

We should be careful not to forget that design is inextricably linked to content.

I’ve started exploring the use of XHTML and CSS for this purpose. The ideal is to have a single set of structural XHTML and then to only write new stylesheets for each partner. This is proving to be a difficult task. The current methods of XHTML/CSS may not be flexible enough to allow for the customization of layout that partners desire. While CSS Zen Garden has proven that this is theoretically possible, it requires the addition of extra markup to anticipate future design needs. The problem is exacerbated because we are an e-commerce site as opposed to a more text-centered content site. The formating needed is more complex than just header/footer/sidebar and paragraphs of text.
While I think that this method has a number of benefits, I don’t know if we’ll be able to get away from having to go in and edit the structure of the documents.

You can see some of my efforts at http://usairways.lastminute-getaways.com

This is a beta launch of the site, so there are still issues to be worked out. The site should render well in ie 5/6 for Win, Mozilla, and Safari. There are still some issues with IE 5.2 for Mac. Also, the XHTML will not strictly validate because of invalid HTML in the database, and ampersands in query strings generated by the back-end. I’ll be working to get those cleaned up as well.

While XHTML/CSS is a vast improvement over previous methods, the ideal of seperating content from presentation and especially structure from presentation isn’t there yet.

Adding extra structural elements to XHTML seems to be the best way forward. In real terms this would probably take a good couple of years to propagate even if done now.

A W3 recommendation for coding style describing IDs/classes to be used for common structures would be superb. This would allow me to use and understand style sheets written by other developers immediately (and vice versa).

If this was sufficiently encompassing then conversion to future markup languages could even be achieved by running the existing XML markup through some standard XSLT.

The pages we make may validate XHTML, and may use all the cool techniques we’ve learned to make clean and clever CSS layouts, but the stuff in between is a bit random. By ‘in between’ I mean the divs and classes and page structure we end up using, either in one-off pages or within a templating system.

I know there are lots of future plans involving XML and other acronyms with X in them :-), but right now I wonder if we need to start thinking about the clearest and most consistent way to code – beyond the valid XHTML and CSS.

In a way, we need some kind of web standards for the semantics of coding a page, so that the divs and classes make real sense. My menus are usually in a div called ‘nav’, while Zeldman’s are in ‘secondarynav’. This site has the menu list inside ‘header’.

There’s no huge problem here, but on the other hand, maybe there really is. Just as h1 is meant to be the same on all sites (representing the main page title), is there any way, or any point, in developing a way to tie all our menus (or whatever) together semantically? To make all our content divs inherently content? A footer is, afterall, a footer whoever’s site it’s on: if we all had a way of IDing our divs consistently, then we could more or less swap CSS files between any site, and everything would work. This isn’t an end in itself, of course… instead it would be something that happened when there was a standard way of laying out pages… a standard way of linking each of the CSS rules with the HTML on the page.

Sorry for the long rant… I’ve been thinking about this a lot recently :-)

I think the article we’re discussing has been a long time coming – what does Zeldman etc. think? Someone write a big article for ALA!

I’m using it to get a base template that could do everything I want so that when a client finally understand the advantage of CSS based design, I could offer a site that stand a little bit the test of time.

The ideal solution is to have your content in a normalized relational database then build your pages out from there using XML + XSLT, or a content management system, or whatever. Just keep the source of your content pure, and you have the freedom to create pages however you want. XML by itself may be a great way to transfer specific document formats, but a relational database is the tried and true model for when you need true ad hoc flexibility of your data.

Of course, your intermediate layer also makes a big impact on how easy it is to modify any component independently.

With XSLT, you can create a template, and use it to transform XML file to include additional presentation. And with XBL (XML Binding Language), you can “bind” additional presentation markup to HTML.

But, as with most things, there’s good and bad points to everything.

At work, though, we have this CMS that does not allow any control over the <head> tags, plus the corporate color and design is created using nested tables that litteraly go about 7 tables deep to get the content in there (in it’s own table, of course). It’s a mess, and a nightmare to edit (especially since they aren’t using SSI anywhere… so all navigation chnages need to take place in every single file…. my head hurts thinking about it).

The biggest problem with table based layout is how difficult it is to pull out of it. When you are locked into tables, layout becomes a cross-browser nightmare, and design is also hindered.

I hope someday soon all this will be an afterthought, but unfortunately that’s no time soon – at least from my perspective at work. It’s a major organization, and it’s new implementaion of the wretched CMS just locks us into tables and a big ol’ honkin’ mess for years to come.

That’s my experience- since you asked for it!

At least, theoretically, anyway.

Granted, that’s primarily an issue with the CMS being too liberal in what it accepts, but it does go to show that just because something’s in a database doesn’t mean it’s free of presentational information.

In both cases the container, while having some semantic meaning, (perhaps defining an area of related links or contextually relevant notes), is only really there to allow me to place the content in a certain way, as part of a visual layout. For a visual user, HTML containers are regular shapes and their position contributes to their meaning. In order for content/data to be separated from the presentation, ought I not to remove these container divs as well?

Nowadays I, like many designers, construct my HTML in as minimalist a way as I can manage, (when time permits) iteratively and recursively checking each modification to ensure it, and it’s dependancies, are absolutely necessary. But I’m still adding containers to construct a layout.

Tables have thead,tbody and tfoot. Given that most HTML documents also display these features, why don’t new specs account for this? They have semantic meaning, they could even have a pre-stated, default, unique ID ‘#header’ etc. After all, it’s not like we’re talking about XML here. XHTML 2 introduces the concept of navigational lists, but why stop there?

~

The only other theoretical way I can see to separate data and presentation would be to ID every element, and position each one individually. Apart from resulting in unwieldly style sheets, this would produce problems if a sheet was re-used for another document, and (e.g.) an absolutely positioned list had grown in size.
Because of course, the point is to use the same stylesheet over and over.

Ooh. Ramble alert. What was the question again?
Ah, yes.

If you want do layout, no, you can’t separate presentation from content/data using HTML and CSS.
(XML and CSS, yeah you can. But 99% of the world use IE5+ish.)

Basically, it means that as long as you update your website, you’re going to have to make changes. As long as content is bound to structure – and it always will be – you’ll be forced to make changes to one to affect the other. And presentation will be a requisite if you intend to keep your layout up to scratch.

Web design is really just like database design: the more you can plan out before you start, the less you’ll have to do in the long run. But if you suddenly realise you missed out on some content element or type, then you’ll have to adjust the structure to fit around the new content.

The only thing we developers can do is try to be as efficient as possible when designing these sites. But that doesn’t mean we should make “for future use” divs like the CSS Zen Garden did, for example. That would be inefficient.

So even with minute planning and a lot of foresight, it still doesn’t solve the problem. The paradox is one that is bound to its context – much like content that is bound to its structure.

Probably IE 5 or 6, unless MS pulls their collective finger out or people suddenly decide to Switch…