Separation: The Web Designer’s Dilemma

With all the discussion about separating presentation from
content (and structure), it’s easy to lose track of the goal. So
let’s step back, define our terms, and take a look at why it
matters.

Article Continues Below

Presentation#section2

The major reason to separate presentation from the rest of the page is
simple: to simplify any change from a slight design adjustment to a
full-fledged redesign. To achieve complete separation of the
presentation, we must isolate everything specifically and
solely geared towards style.

Contrary to what you might be thinking, this isn’t
limited to just the CSS, not even on a site like CSS Zen Garden. It
also involves HTML tags and properties that exist only to provide a
handle for the designer to apply
styles to. After all, what use is a .pageheader {…}
declaration block if there is no element with that class on the page?

Hold on to this thought and read on.

Content#section3

The reason to separate content from the rest of the page is just as
easy to see as the reason to isolate presentation. Isolation of content
makes adding or updating things easy while maintaining presentational
consistency throughout the site. However, as with the presentation,
there can be confusion
over what content actually is.

For our purposes, content is (usually) text and includes accompanying
semantic
coding: tags like h1-h6, paragraphs, list, em, strong,
code, cite, etc. Content should not require any additional
presentational tags or styles in order to fully convey its
message.

In isolated cases, we might use additional tags to more
correctly present the content. For example, a poem — where
specific line breaks are important — could be set apart by a
<pre class=“poem”> tag, or it could simply make use
of <br> tags to break lines.

Structure#section4

Here’s where things get sticky. First of all, what is
structure? We could describe structure as everything that makes up
a page, minus presentational elements and content. However,
this is at best an overly simplified definition that could easily
cause undue confusion.

Take the navigation menus on ALA as an example:

  • Change a color here, a border thickness there, and you have a
    change in presentation.
  • Change the text of the first navigation item from “Up
    front” to “Home”, and you have a change in
    content.
  • Lastly, you have the <div id=“menu”>,
    <ul>, and <li id=”…”> tags
    as the structure. Switch those out with an antique row of table cells,
    and you have a change in structure.

But wait — remember what I pointed out earlier? Those tags
include
presentational elements: the IDs. As both Doug Bowman and Eric Meyer have pointed out,
presentation is pointless without structure. Furthermore, I’ll
show that
it’s also pointless to try to separate structure from content.

Take the simplest example of web content you can think of:

  

Title#section5

Lorem ipsum dolor met.

The <h1> and <p> tags are clearly
part of the content, right? We can’t write correct HTML content
without this basic semantic markup. Yet this markup is also part of
the document structure, dividing up an otherwise-uniform blob of words
into a heading and a paragraph. (And of course, if you want to get
picky, you can consider the markup to also be a part of the
presentation as well. After all, the browser has a preset way of
displaying <h1> and <p> text,
doesn’t it?)

So where does this leave us?

Content and structure#section6

You can theoretically separate content and structure, but then you’d be left with <ul><li>

for structure and plain featureless text for content. Needless to say, building a functional site out of those is quite impossible.

So we can conclude that structure cannot and should not be separate
from content.

Presentation and structure#section7

As we have seen, without structural elements, there is no way to apply
styling to the content. Structure cannot be separate from presentation
— nor should it be.

Which leaves us with …

Presentation and content#section8

Although presentation still depends on structure, some of which is
embedded into the content as noted above, presentation can and should
be separated from content.

And while major presentational changes can require changes in
structure,
content can be changed without any need for structural change
beyond the already-embedded structural elements.

Real-world separation tools#section9

With all this in mind, let’s envision the perfect website
separation system.

It would store content in a database, allowing the isolation and
management
of content information. Presentation and structure would be handled
together; presentation
could be managed with a stylesheet and accompanying structural elements
where needed.

Structure would best be dealt with through a system of
template “packages” built using a server-side scripting
language (such as PHP or ASP). Each template “package”
could have one or more stylesheets (e.g. CSS Zen Garden), but every
template “package” would connect to the same with the same
database to
retrieve content for display.

Many content management systems provide varying levels of this kind of
template support. However, full-featured template systems that make CSS
Zen
Garden-like usage of stylesheets — especially ones that come with
a comprehensive content management system — are few and far
between.

But for a competent webmaster, building something like this from
scratch can’t be all that hard. Can it?

About the Author

Michael Cohen

American-Israeli webmaster Michael Cohen has been coding web pages since 1995.

80 Reader Comments

  1. Interesting article, but I was never really confused by this. I’ve always considered that I’m constructing the content; using the implied structure of the content.
    For me, once I understood that it was a bad idea to do things like class=”blue”, I understood that I was trying to find the right markup for a document that already had implied markup. Using h1 and p is obvious, but it was more difficult to figure out navigation, or how to divide up the page and what comes first in the source.

    I think that a big stumbling block can be that people don’t realize that your content needs to have an implied structure. Start there, with well written content.

    I’m not exactly sure where the dilemma is though… http://dictionary.reference.com/search?r=2&q=dilemma

    and is it just me, or did we not come back to this thought I was told to hold “After all, what use is a .pageheader {…} declaration block if there is no element with that class on the page?”

  2. “And of course, if you want to get picky, you can consider the markup to also be a part of the presentation as well. After all, the browser has a preset way of displaying

    and

    text, doesn’t it?”

    Actually, no. Modern browsers use an internal style sheet for the presentation of all elements. This style sheet is over-ridden by a user’s personal style sheet, and/or the style sheet referenced by a document.

    But yes, the separation of style, content and behaviour are very important. Keeping them separate allows people with specific skills to operate on a site without fear of stomping on someone else’s work.

  3. This article is like the new Prince album – just as you’re enjoying it, it suddenly stops. I felt there was no proper ending to it, no examples of what we should do. Instead the onus was put on the reader to carry out what is required. But how?

    I am also left confused as to the relationship between content, structure and presentation. The article seems to suggest previous thought on the issue was wrong. Now I don’t know what to believe.

    A good point about a header and a paragraph being already styled though. You’d have to make everything a paragraph to avoid that, then add code like class=”header” where you wanted the header. Which would be silly of course.

    Or you could just use CSS to style everything to the same size, then restyle as necessary (which I’ve done before myself):

    * {
    font-size:12px;
    font-family:Arial,Helvetica,sans-serif;}
    font-weight:normal;
    }

    That way headers and other tags are no longer pre-set by the browser. Hmmm…

    My mind then thought of XML as the perfect solution. The browser would *not* style this, since it wouldn’t know what the tags meant, leaving us to add the style ourselves.

  4. I agree. I did not see the purpose in the article. It seems like I was reading the introductory chapter for a book on why to use CSS.

  5. Nice article, but:

    —QUOTE—
    Furthermore, I’ll show that it’s also pointless to try to separate structure from content.

    I’m not so sure about that. Sure structural tags give explicit meaning to content. But does that mean the content sitting in my database or text file is a hopeless jumble of letters and spaces? Should it not have an implicit meaning?

    Like Jim stated, content should have an implied struture so that even without ‘s and

    ‘s it can be dicerned. That’s the job of a talented writer and editor. So it comes down to well-written content, not just well-marked up code.

  6. …i read the article twice, but it’s a confused and confusing mess, in my humble opinion.
    it seems to make the point that there’s not just presentation and content, but also structure. however, i would posit that structure is an inherent part of the content itself. or am i missing something?

    Terrence wrote: “Like Jim stated, content should have an implied struture so that even without ‘s and

    ‘s it can be dicerned. That’s the job of a talented writer and editor. So it comes down to well-written content, not just well-marked up code.”

    discerned by what? a human reader? yes. any kind of user agent, assistive technology, search engine? well, they require it to be marked up properly.

    altogether, a muddled mess of an article…

  7. I think we have the closest thing out there in terms of what your article is suggesting. Pure separation of content/structure from presentation, xhtml strict templates by default, full css implementation, and an xhtml wysiwyg editor that understands and enforces xhtml strict. At an affordable price for designers. I challenge anyone to show me a system that allows them to build a standards compliant site faster than I can with Octane8.

    If anyone would like an online test drive, drop me a line sblanchard@octigon.com

  8. –QUOTE Patrick H. Lauke—
    discerned by what? a human reader? yes. any kind of user agent, assistive technology, search engine? well, they require it to be marked up properly.

    Yes, by a human reader. And yes, screen readers, search engines, and the like need markup for interpretation.
    But my main idea was that, although markup gives some structure to content, it doesn’t give content ALL of its structure.

    As you said: “…structure is an inherent part of the content itself.”

  9. “However, full-featured template systems that make CSS Zen Garden-like usage of stylesheets — especially ones that come with a comprehensive content management system — are few and far between.”

    Blogger comes to mind! WordPress…
    (though they are specialized tools)

  10. aha yeah… this way of thinking is the way geeks these days generally do it up. I don’t mean that in a perjorative way, compartmentalization has brought us all sorts of lovely innovations (off-the-shelf GUI toolkits with elaborate class heiarchies, component-based architectures like .net, java and its many accompanying three-letter acronyms that start with “j”, etc ad nauseum).

    but yeah I find the assumption that “content” will uniformly end up being blocks of undifferentiated text rather disheartening. sometimes, to communicate effectively, things like “structure” and “behaviour” should react to “content” in ways perhaps unforseen by the person who built the site. “content” shouldn’t get the shaft because of the assumptions of the site designer, n’est ce pas?

    perhaps this is unclear. mr. dean allen’s textile somewhat addresses this.

    yes!

    -fish

  11. xml = content
    xslt = stucture
    css = presentation ?

    Even when using templates on the serverside, presenting correctly written xhtml+css to the clientside, you are still sending ambiguous data to the client.

  12. Recently came across this site at http://www.media-paradigm.com – which is direct rip off of our look and feel at http://www.firewhite.com. This is appalling for a variety of different reasons.

    First, our site was designed by Two Thirty Media http://www.twothirty.com out of Canada, one of our strategic partners. So, presumably Media Paradigm owes Paul Jarvis, President and CEO a design fee equal to what we paid for him to design our site.

    Second, media-paradigm claims that it offers services in content management and graphic design. Well, if you are a graphic designer you don’t need to steal. So I question whether media-paradigm offers any “real” services. Certainly, when it comes to coding, I’d have real doubt. Why? Because their rip off doesn’t take advantage of CSS and tableless-design so as to meet web standards; our site does and was designed to do so. I can only assume that the UK is an world of hurt. If – as MP claims – these guys are the “UK’s most established Web Development firm” be afraid, be very afraid. What this basically says is that no one in the UK – and by extension Europe – knows how to implement web standards.

    Also, the content management “solution” that MP resells – ContentSpot is based on ColdFusion, which is both expensive and relatively slow.

    Sorry for the rant but this burns me!

  13. > But wait — remember what I pointed out earlier? Those tags include presentational elements: the IDs.

    Actually, IDs are far from being presentational elements : they’re semantic. When you add, say, a “publishDate” ID to a paragraph, you’re giving meaning to it. It becomes uniquely identified. The same applies for classes, which allow serialized identification.

    I make extensive use of IDs and classes instead of comments in HTML documents, and they don’t necessarily serve as hooks for CSS or DOM scripting. They act as semantic links between the text (content) and its containers (structure), and they make both more human-readable.

    From my perspective, content and structure separation is an empty – and rather naive – proposition.

  14. For what it’s worth, the spacing between the words is presentation; and words are just syntactical presentation of ideas. Content should be separate from presentation and structure should serve to bind the two.
    Perhaps I am a CSS luddite, but it seems like a web-master’s skills would be better spent elsewhere.

  15. The luddite statement refers to compartmentalizing data, not content/presentation (xhtml/css) separation.
    Sorry, too much coffee.

  16. And everything falls into places.

    You may need to serve same data to multiple platforms: phone, PDA, some exotic device for visually impaired that does not take markup at all but take a binary blob instead. So, you need to have “pure” data (XML) on the server. And then a way to apply ANY required presentation (host based scripts, Java, .NET applications, anything). So your client, whatever it may be, receives only what it needs while presentation technologies may be completely different.

    The world is changing and HTML with all the X, D or whatever in front of H is dying

  17. Gecko browsers and IE/Win already allow for the client-side separation of content, structure, and presentation. As .les said above (http://www.alistapart.com/discuss/separationdilemma/2/#c8118), this is what XML, XSL, and CSS are for. No database or middleware language needed, unless you also want to separate data from data markup.

    See my site and view the source. XML to describe the content, XSL to transform structure to XHTML on the client side, and CSS for presentation.

    Of course, the limitation (for now) is client support if that’s important to you. Well, that, and search bots don’t seem to understand XML, so if being found by search engines is important to you…

  18. I don’t at all want to sound mean but this article was really…(how do I say this without hurting feelings)…terrible. It mentions nothing of seperating behaviour and structure.

    We’ve heard enough of seperating structure and presentation. How come there is so little emphasis on seperating behaviour and structure.

    I found only one (excellent) article about seperating behaviour and structure by Peter-Paul Koch: http://digital-web.com/articles/separating_behavior_and_structure/

    Same old: people don’t take Javascript seriously because accessibility zealots claim
    that it restricts accessibility and usability.

    I will not worry about minute issues like using the correct h2 or h3 or whatever. There are far more important issues to be worried over than “well, a h3 is too big but it’s ‘semantically correct'”.

    Just my two cents

  19. I use an xml document that describes content as document{ information{title,author,etc}, content{html}, section{ title, content{…}, section{…}} … if that notation makes sense. One could use this for a generic LaTeX-style structure document, or one could use it for a weblog. All that matters is what you use for your xsl transform. strong IDs round out the output, and good ole CSS takes care of all presentation.

  20. This is old news. Actually, I won’t even consider it as news. It is merely a repetition of an old idea. The ideal system you describe has been build many times over, and in many cases these systems have been used successfully. There is no perfect system that will meet the needs of everyone, however. I prefer to use the tool that best fits the job.

  21. I really agree with the author. But I would note that there is the problem of a complex content. A content may consist of many small parts which have their own structures, presentation and content. And this fact really deserves our attention.

  22. This article makes out seperating things to be really hard. I can explain it as simple as:

    CSS (Presentation) is seperated from structure but connected with the link tag (or the import method).

    Javascript (Behaviour) is seperated from structure but connected with the script tag.

    Seperating content and structure is daft. You wouldn’t seperate your car and its engine, would you?

  23. Ive always struggled with the design of content… most of the time opting for blocs of text (like most sites) this is increasingly frustrating as i seek to expand my use of the media. I’d like to be able to integrate magazine style innovation and typography into designs which when separating content from code is an impossibility.

    in an age where the die hard CSS luddites say graphics are redundent, that means all sites are going to start looking the same (see cssvault.com where most sites listed are of the 2 column style (like zeldman/alistapart and more) its annoying because theres nothing to choose between them apart from a colour change.

  24. I’m working on an article about what I call ‘content flow’, and it address the problem of columnar layouts (no originality, and how sometimes they can be obstrusive.). ALA probably wouldn’t publish it, so I’m going to submit it to Evolt.

    Verdict on content, structure, presentation and (much ignored) behaviour: seperate but equal.

  25. In response to the various people who have made note that the article seems to be a bit “old news”, in a way they’re pretty much correct. This article was originally written to be published approximately 5 months ago, but due to events beyond anyone’s control, it was delayed until now. My apologies to one and all. 🙂

    Regarding the criticism, thank you. 🙂 The whole point is to figure out what the “right” way of doing things is, and I certainly don’t claim to know the answer any better than one of you.

    To the typical end user (a human, as opposed to a search engine spider or the like), semantic markup must be both integrated into the content, as well as styled in order to stand out from the “plain” content.

    The main point I would like to get across is that things cannot be simplified down to “content” and “presentation”. There is a 3rd element, “structure” (or “semantic markup”, if you will), that we must also be aware of.

    Finally, to those who mentioned the lack of resolution to the article: I don’t believe there can be a one-size-fits-all solution. One site will have nothing but content that can be perfectly structured using native HTML tags, where another will demand creative use of all sorts of class and ID designations that must be uniquely styled in order to have any meaning for the human reader. It is important to look afresh at each new project, each different kind of content, in order to make the best use out of the tools given to us.

  26. The average user will no absolutely nothing about HTML and will never, ever look at the source code, never mind yell at you for using b instead of strong.

    With a site like ALA, which is for web developers, this is different, but for a site for the average user (ESPN or a history website), you shouldn’t worry about using phrase elements or ‘semantic’ markup.

  27. I think we sometimes forget that in coding raw html we *are* separating the content from the structure. If you type a word document you get structure by hitting <enter>. When using HTML you need to add <p> tags. HTML *IS* structure for your content (content, for everyone’s purpose, being everything in-between tags). I think that was Tim Berners-Lee’s point when he described it as a “markup language”.

    Having said that, I too am confused as to what the point of this article might be. I get the feeling that it asks whether content management works and whether the separation of content, structure and style supports the CM process.

    IMHO content management needs a “reasonable” degree of separation to be successful, but more importantly, the content managers need to understand the job they are doing and to understand what effect the “content” they add to the database will have on the website.

    I think programmers often try to hide/reduce the need for training by trying to protect the “system” from untrained users. Is this really the most effective approach?

  28. (not same m.cohen as the author!)

    Hi,
    I found the article and discussion very interesting.

    I’m reading this as a reversal of the purist/pragmatist dilemna where once the ideal was to write hand written code has become the search for the perfect engine to do it for you.

    Either way round the purist seems to end up trying force round pegs into square holes In this case the templating purist is making bigger more expensive engines that end up more complex than writing the code by hand because fundamentally the 3 things can’t be decoupled. As an example adjust a presentational element to change the colour of text to be white on white – doesn’t that couple presentation with content (while actually not affecting structure)?

    My take on templating engines is they are great when when there is little money and they empower small orgs to have sites they wouldn’t otherwise afford but taken too far and they become a burden, an obsfuscator, a garden path leading away from the nirvana of writing the code (and all else that entails) yourself.

    Okay coming back to separation debate, well i’ve delved into css without training or time and my experience is that I’ve made an increasingly cumbersome style sheet lacking good naming conventions for classes and probably far too many classes but which does allow minor miracles to take place on my site.

    So – I don’t think complete separation is possible or even makes any sense whereas understanding the issues and best practice on how to write css is highly desireable?

    mikey

  29. >>Dante:
    The average user will no absolutely nothing about HTML and will never, ever look at the source code, never mind yell at you for using b instead of strong.

    They are not going to yell at you for using strong instead of b either 😉

    >> for a site for the average user (ESPN or a history website), you shouldn’t worry about using phrase elements or ‘semantic’ markup.

    Semantic markup is largely for the benefit of machines, not humans. If you don’t beleive in semantic markup, drop your tag, drop your </p> <p> tags, drop your <hx> tags and style everything with <font>. Lets see how well Google ranks your site afterwards.</font></hx></p> <p>

  30. >>
    Semantic markup is largely for the benefit of machines, not humans. If you don’t beleive in semantic markup, drop your tag, drop your </p> <p> tags, drop your <hx> tags and style everything with <font>. Lets see how well Google ranks your site afterwards.<< What I meant was nitpicking about the little things (strong and b, em and I). I know the <title> tag is important, and I am NOT and advocate of tag-soup. I do use P tags (though some pages on my site are from when I was just learning HTML, and I haven’t updated them yet) and headers. </p> <p>I myself I use the em tag, but I style it so that it appears bold, italic, and underlined (which means strong emphasis). When I want just italics, I use the I tag. In my view this is very semantically correct, and the em tag should be styled with bold, underline, and italicized as default. </p> <p>As for search engines, I don’t really believe that strong will result in better ranking than b. And even if it does, it’ll only be a drop in the ocean.</p> <p>Maybe you could cheat search engines by styling all tags as a h1. Sounds a like a cool experiement to try…</p> <p>As I said before, seperating content and structure is like seperating your car and its engine: they both form one as a whole.

  31. This article is not preaching anything new and is merely recanting the widely used concept of separation of content and stylization.

    I really don’t think this article deserved to be published on ALA. We should focus more on practical, or cutting edge concepts of separation.

  32. It is useful to consider structure as the glue that connects presentation and content. In precisely the same way as you use labels (class and id attributes) to connect the structure to the presentation you can use labels to connect the structure to the content.
    This is a standard technique when multilingual applications are written. There is no reason why a similar scheme should not be applicable to web pages.

    Okay, I accept that it isn’t that simple. You could certainly seperate out block structures without too much sweat but where does a set of em tags fit into the scheme. Are they presentation, content, or structure?

  33. It’s nice to see that one of the core values of Media Paradigm is stated as “Integrity, honesty and responsibility – as individuals and as a company”

    Based on the fact that they have stolen and ruined a design it seems somewhat amusing.

    I can however assure you that just because they say they are the “UK’s most established Web Development firm” does not make it so. The UK (and Europe, although I’m not sure why Marcia made the extension in this case) has a wealth of fine designers who don’t have to resort to such blatant plagiarism to ply their trade.

    This issue does highlight the fact that design, I feel, is becoming increasingly easy to steal but due to the nature of the Internet’s internasionalness (is that a word I wonder) very difficult to stop.

  34. Well, what about XSL? I mean you can truly separate content from presentation if your content is, for instance, XML. Then you use XSL for structure and finally CSS for presentation.

  35. “I myself I use the em tag, but I style it so that it appears bold, italic, and underlined (which means strong emphasis). When I want just italics, I use the I tag. In my view this is very semantically correct, and the em tag should be styled with bold, underline, and italicized as default.”

    No, that’s wrong. The tag is for emphasis, but the tag is for stronger emphasis. So that’s what you should use. (You even say “strong” emphasis in your text above!)

  36. First of all, I think it’s obvious that structure and content are tightly interwoven; there isn’t any need to separate these.
    Second, I don’t consider adding classes and ids to structural elements as necessarily introducing presentation to the structure/content, but merely as appending the often insufficient set of (X)HTML elements.

    Although this practice often springs from the need to create “handles” for presentation, if chosen properly they shouldn’t have a presentational character.

    Consider a markup language which did offer all the different elements needed to mark up each and every bit of content with the appropriate meaning: each element could be specifically targeted for styling without any “pollution”.

  37. First of all, the most interesting part of the article (I see no “real” problem with the main issue) and as I see it the beginning of very interesting discussion/article is the last paragraph “Real-world separation tools”.

    It describes “the perfect separation system” from a web developers point of view; which to me is just one of many perspectives needed. In other words we are merely touching the production phase of a much larger and more complex process. There are many more factors to involve when dealing with web content management; i.e. the client may have one or more existing systems that we need to retrieve content and/or structure from.

    Separation must have a purpose. It also seems that the author has missed the point of separation; the main reason this “separation system” should be allowed to exist is to be able to present the parts as a whole. So why not call it a “wholer system”? Since that should be the purpose of separation.

    One of the main issues when investing in (deciding to use) a web content management system is also to “get rid of” the webmaster. It is about creating a new collaborative environment where the ones involved, depending on his/her role, can do what they do best; designing, developing, writing, administrating etc, without having to rely on someone else to be able to perform the task needed. A web content management system opens up opportunities (as well as restricts if wished upon) and streamlines work process. It is a long term investment (decision) that should come from company strategy and not from “developer needs and wishes”.

    From what I have seen following the links to various tools suggested in this discussion none of them are web content management systems, mostly because they only focus on one role/task in a larger process.

    They are also tools that offers one thing, but also restricts many other things. Say they allow me to only write valid css/xhtml, then they restrict me from writing “hacked” html for i.e. IE6. That is something I would never agree upon. It might seems stupid, but sometimes a clients needs (i.e. in an intranet solution where the company only uses IE6) makes me tweek the limits (of cause being aware of the hacks I am doing).

    I would rely on a tool that demands nothing but offers everything. That way it is up to me as a designing human being to make the right choices for my clients… depending on the situation and conditions.

    I could write miles but I am afraid I have already bothered you with poor English and maybe, to you, poor thougths…

    To try and answer the question in the article: A webmaster is not able to build a competent web content management system (if so is the case: he/she is not a webmaster or the system is not a web content management system)

    Sorry for the poor english. (I am one of those people from Europe)

  38. “I challenge anyone to show me a system that allows them to build a standards compliant site faster than I can with Octane8.”

    Octigon.com doesn’t validate as correct html.

    Ok, http://www.plone.org.

  39. IDs were presented here as being presentation. I am in the camp that wants to use them as structure: ID=sitenav ID=pagenav etc.

    Hn, P, etc., are not just needed for search engines, but also for modern screen readers. In the current version of Jaws, for instance, the end-user can tell Jaws to skip to the next or previous Hn tag.

  40. I agree with Charles. When introducing others to structural markup, I have described it as function-oriented rather than appearance-oriented. The tags (with or without ids or classes) desribe the role that the enclosed content fills. That’s the purpose for the structure: to label headers as headers and paragraphs as paragraphs. The data without such structure has very little value to machine or human. With structure (and stylesheet) it works with both.

  41. The problem with most of the replies is the assumed concept of the ideal system; eg. everybody uses a standards complaint system, you can do everything you need in standards.

    This is not how the world is unfortunatly. My CMS (http://www.infireal.com/solutions/mxr) handles this problem by a flexible template solution so you can define targets(web/print/IE only web/RSS with auto detect or url) on a per sub/template basis.

    eg. for standards web target
    you have a template with subtemplates for the article, news

    for IE only(intranet) target
    reuses the article, news subtemplates but with a header that uses different CSS & JS

    for XML target
    XML template with no presentation links –

    This to me is a very clean approach.

    The system is also non HTML coder friendly:
    In the ControlPanel I use HTMLarea3(restricted to B,I,Lists) that produces relatively clean HTML and then postprocessed to be semantic meaninfull.
    Remember to capture as much seperate data as possible eg. having a date in the DB instead of markup(throught HTMLarea3):

    nowdate

    For the designer you can edit the raw html or include uploaded files. To each his own I say.

    ps. the demo on my site is very old and does not use the above.

  42. “As I said before, seperating content and structure is like seperating your car and its engine: they both form one as a whole.”

    “First of all, I think it’s obvious that structure and content are tightly interwoven; there isn’t any need to separate these.”

    I think that both these statements are wrong, and just a tad ignorant of the possibilities available with content and structure separation.

    I have wrote a bit about this here:
    http://www.wubbleyew.com/blog/showblog.asp?blogID=229

  43. “Hn, P, etc., are not just needed for search engines, but also for modern screen readers. In the current version of Jaws, for instance, the end-user can tell Jaws to skip to the next or previous Hn tag.”

    Opera 7 can cycle through headers on a page using S and W.

  44. You cannot separate structure from content without making the structure ilogical. That’s why I don’t do it.

  45. We have bigger things to worry about than seperating content and structure. It’s like worrying that you’re going to miss your favorite TV show (for me, The Simpsons) whilst your house is burning down.

    Example: I have been researching the possibility of 100% accessible Image tab Rollovers that use Javascript to replace the images and CSS for the rollovers. This method is built to so that
    it’s accessible to any UA – even screen readers (but only one browser, the best browser ever, gets it right: Opera 7). Sites using FIR are either inaccessible or riddled with hacks: it’s been solved by using Javascript, but no one seems to care: we’re all too busy worrying about ‘Should I use em or strong?’

  46. Harry: “…XML to describe the content, XSL to transform structure to XHTML on the client side, and CSS for presentation.
    Of course, the limitation (for now) is client support if that’s important to you. Well, that, and search bots don’t seem to understand XML, so if being found by search engines is important to you…” (http://www.alistapart.com/discuss/separationdilemma/2/#c8125)

    The solution is server-side scripts and stuff to fall back on, which I havn’t tried YET.

  47. There are several structures please stop fighting over the wrong ones!
    There IS structure in content that is part of the content, then there’s structure that’s part of the current page, plus structure of the whole site (repeated on all pages).

    You start by building a structure and adding content (yes the content includes a bit more structure). Now you use the structure (which may include some class or id attributes or not) as the hooks to style-up with CSS. If the structure is consistent throughout your pages, the style will be consistent throughout your site (a very good thing). And you can use the structure as a framework to add new pages/conent with the confidence that the presentation is already taken care of.

    The structure is the link between the separated content and presentation, wheter or not content can be separated from structure or not, is irrelevant. Hook onto the structure in order to provide presentation hints and behavioural facilities, but ensure the structure and content-with-some-of-its-own-structure is perfect before adding presentation.

    Also the greatest reason behind the separation (not sure if this has actually been mentioned yet!) is that it means you don’t have to rely on un-reliable presentation to convey the semantics/structure/content/meaning.

  48. First of all, I’d like to point out something that’s not directly related to the issues at hand.

    The website of the company I work for is horrid. As pointed out to us via a form submission, there’s no doctype declaration. Nor, I will point out myself, is it a site to be proud of in any way, shape, or form. It uses tables up the wazoo, needless BR tags, etc etc – in short, quite embarrassing for a standards-minded developer like myself.

    It’s a simple case of the shoemaker going barefoot. He’s so busy with projects for customers and clients that he has no time to make himself shoes. I’ve got at least 3 big projects on my plate (big is relative, since I’m the only web dude around these parts), and a number of people in the waiting line to ask for sites. In the words of the (in)famous Prince Humperdink, “…I’m simply swamped!”

    Ok, enough of that embarrassment. :p

    Dante: “What I meant was nitpicking about the little things (strong and b, em and I).”

    Yes, for most users, it is nitpicking. But tell that to the blind man who uses a screen reader to surf websites. The B tag is purely presentational, and says nothing about the meaning of the content it encloses. It is merely “Display this text in bold.”

    STRONG, on the other hand, is (usually) formatted by default in bold, because that is the commonly accepted way of placing a strong emphasis on content. But when you look at (listen to?) screen readers, they know to place a stronger emphasis on text designated with the STRONG tag, because it designates meaning, not appearance. Semantics (via structure), not presentation.

    Rob G.: “This article is not preaching anything new and is merely recanting the widely used concept of separation of content and stylization.”

    Partially correct. 😉 As stated in one of my previous comments, I wrote this 5 months ago, but it was only able to be published now.

    However, at the time of writing, I had not seen anything besides “separate content and presentation”. I did not see any mention of there being 3 players, not 2. And I, needless to say, did not see every single article ever written, so forgive me if I missed something. 🙂

    Steveg: “You could certainly seperate out block structures without too much sweat but where does a set of em tags fit into the scheme. Are they presentation, content, or structure?”

    EM tags are semantic in nature, and are structural markup. They have default presentational styling assigned to them by the browser, and they set apart content contained in them as emphasized.

    Ronald van der Wijden: “Consider a markup language which did offer all the different elements needed to mark up each and every bit of content with the appropriate meaning: each element could be specifically targeted for styling without any “pollution”.”

    Quite correct. This is, according to my limited understanding, what XML/XSLT/XHowManyXAcronymsCanWeHave is for. 😉

    Kristian: “Separation must have a purpose. It also seems that the author has missed the point of separation; the main reason this “separation system” should be allowed to exist is to be able to present the parts as a whole. So why not call it a “wholer system”? Since that should be the purpose of separation….

    …Sorry for the poor english.”

    First things last, your English is considerably better than many (most?? :-/) native English speakers.

    Secondly, the purpose of separation is not to present the parts as a whole. That is comparing apples and oranges. “Separation” has no purpose, it IS a purpose. With separation, we allow content changes without affecting site structure or presentation, and presentation changes without affecting content.

    Yes, it’s pointless unless put together for the end user. But separation does not have a purpose, it is the purpose. 🙂

    Charles Belov: “IDs were presented here as being presentation. I am in the camp that wants to use them as structure: ID=sitenav ID=pagenav etc.”

    That is the proper use of ID and CLASS properties – structural markup and CLASSification. They are handles to allow styling just as much as Hn tags are. The only exception is that the ID/CLASS is user-definable, therefore it does not have a default styling set by the browser.

    Mathias Munk Hansen: “You cannot separate structure from content without making the structure ilogical. That’s why I don’t do it.”

    Not to the end user, no. But if you store your articles in a database, you certainly don’t want to store the site navigation DIV along with it. That’s a kind of structure, too. I assume you’re talking about STRONG tag structure and the like, however. 😉 In that, you are correct – it should be, at every stage, part of the content itself. Which was one of my points in the article. 🙂

    Dante: “Example: I have been researching the possibility of 100% accessible Image tab Rollovers that use Javascript to replace the images and CSS for the rollovers.”

    I find this slightly amusing, but correct me if I’m wrong here. You’re using Javascript to ensure the accessibility of your site? Looking beyond the typical computer platforms, do you know how many devices that access the web do not support Javascript, or any kind of scripting, for that matter?

    XML and Various Related Flavors: Those of you who have brought this up are probably making a very good point. Unfortunately (see the Shoemaker analogy above), I haven’t had the time to teach myself this branch of coding. Yet.

  49. Michel Cohen: “This is, according to my limited understanding, what XML/XSLT/XHowManyXAcronymsCanWeHave is for. 😉

    That is exactly what I was referring to, but I thought not to throw in the “X-acronyms” to avoid clouding the discussion any further… 😉

    I feel this whole “separating content from structure” is rather artificial.
    Sure, with server side techniques you can separate text blocks from the basic page structure and drop them in as the page is requested, but what’s the point?

    Structure is not about techniques like that; I mean, a bunch of characters become a word once they’re grouped together in a certain structure, words form a sentence once they’re stringed in a certain order, seperated by spaces and/or interpunction. If you take the sentence structure out of the sentence, all you’re left with is words, context-less words.

    “Separation” in this context means to me: disentangling one from the other so both can be maintained and altered without – immediately – influencing eachother.

    If you try to disentangle the strands of wool that make up a sweater, all you and up with is a bunch of wool; once the structure of the sweater is gone, so is the sweater.

    Again, separating presentation from structure/content and behaviour makes good sense to me since they can live separately without harm; separating content from structure does not since that would destroy the meaning of the content and thereby the content itself.

  50. quote:

    Again, separating presentation from structure/content and behaviour makes good sense to me since they can live separately without harm; separating content from structure does not since that would destroy the meaning of the content and thereby the content itself.

    /quote

    I couldn’t agree more. I just finished writing about this on my own site. Essentially, I think content and structure can be separated on an administrative level with a good CMS, but they can not exist without one another at the final page rendering. The behavior and presentation layers, however, are completely optional to functionality.

    For those interested (with neat illustrations!): http://www.graphicpush.com/archives/000070.shtml

  51. quote:

    Again, separating presentation from structure/content and behaviour makes good sense to me since they can live separately without harm; separating content from structure does not since that would destroy the meaning of the content and thereby the content itself.

    /quote

    I couldn’t agree more. I just finished writing about this on my own site. Essentially, I think content and structure can be separated on an administrative level with a good CMS, but they can not exist without one another at the final page rendering. The behavior and presentation layers, however, are completely optional to functionality.

    For those interested (with neat illustrations!): http://www.graphicpush.com/archives/000070.shtml

  52. To add to Pats point octane8 has over 100 errors! I suggest people try http://urbanmainframe.com and the others that DarkBlue (1st post) has singled out as they all validate! Don’t bother boasting about something you can’t deliver its a waste of all of our time.

  53. >You’re using Javascript to ensure the accessibility of your site?

    What’s wrong with that? For image replacement it seems to make perfect sense, at least with javascript you can check to see if it’s supported before changing the presentation.

  54. A content may consist of many small parts which have their own structures, presentation and ontent. And this fact really deserves our attention.

    Great point, and a solution is to use a CMS that stores content “chunks”, not pages and one that allows you to define content structure for different types of content.

    liveSTORYBOARD CMS (http://www.livestoryboard.com) does this. It uses schemas to define content types (i.e. generic article, job description, image slide show, etc.) and enables content authors to define and pick the appropriate type for their needs. Content pieces are then assigned to pages, so you can have one or more content piece on a page and they can be of different types.

    A few other benefits:
    – XML/XSLT/CSS (ideal for separating content and presentation)
    – valid pregenerated output (XHTML, HTML, JSP, etc)
    – real time wysiwyg editor validation
    – “nice” urls such as http://www.sitename.com/dirname/pagename.html as opposed to the more common with content management systems http://www.sitename.com/123?x=a&blah and more 🙂

    As one of the developers, I suppose this may be a bit of a shameless plug, but for those interested, here is an example screenshot of some work in progress: http://www.girlsinc-online.org/demo/ExploreAndSucceed/Introduction.html. As a really simple example, this page shows a sample interview screenshot of what’s behind login for this portal project.

    The page contains an “intro” XML content piece, first pregenerated with XSLT, then furhter styled with CSS and “question/answer set” type content piece. We use XML schemas for the content types, so a common point of refernce for the semantics and content structure is used throughout a site. Authors edit the xml through a wysiwyg (http://www.livestoryboard.com/Products/Screen_shots.html), so the complexity is hidden from the non-techy CMS user.

    Further on the subject, storing your content and templates in XML (XSL is XML) allows you to continuously evolve them over time programatically rather than hand coding. So, as your needs and knowledge evolve, you don’t have to start from scratch.

  55. Looks like the “.” after “http://www.girlsinc-online.org/demo/ExploreAndSucceed/Introduction.html” was made part of the href, therefore breaking the link.

  56. So if one main purpose of separating content from presentation from structure is to allow easier redesigns site across entire sites, I’m curious how often it really happens like that.

    I’ve worked on projects where the previous designers worked hard to maintain this philosophy, but in the end, I still had to make drastic changes to the structure in order to achieve the desired presentation.

    My experience is that clean markup focused on separation of content, structure, and presentation might make a redesign easier, but in the end, one often ends up having to change up more than they ever expected.

    For instance, if a two column site is moving to a three column format, the structure of the two column format will not allow for the new three column structure (99% of the time).

    In the end, I believe this philosophy is good, but sees most of the benefit in site-wide changes to presentation rather than changes to structure.

  57. Pat, Aaron,
    I did not make any statements about octigon.com and its ability to validate. I’m talking about our next generation web development tool, octane8 version 5.0 Our public website is going to be ported to xhtml strict in a few weeks under our new version of Octane8. The site is currently using version 4 of our software.

    As I said, if anyone wants to take an objective test drive of Octane8 version 5 – which will ship in June, drop me an email.

  58. I see we have a Javascript hater on our hands.

    MC: “I find this slightly amusing, but correct me if I’m wrong here. You’re using Javascript to ensure the accessibility of your site? Looking beyond the typical computer platforms, do you know how many devices that access the web do not support Javascript, or any kind of scripting, for that matter?”

    I find it extremely amusing your article mentioned nothing about seperating behaviour and structure; instead you threw a cigarrete at a hay stack and started this meaningless “content/structure seperation” argument that has, literally, gone “up the wazoo” (note I don’t trust anyone who says the ‘W word’).

    I DO know how many devices have no javascript, excluding spam bots and search engine spiders: 2%, if not less.

    My javascript solution DOES seem crazy, I know that. But you’ll see there’s a method to my madness once I finish the article about it (and get the technique to work in a certain browser which I will not name).

    Please correct me if I am wrong.

  59. I must admit that I too was disappointed in this article. It appeared to be written by someone who has never heard of Content Management Systems or understands what they do and now that the “lights have come on” is recommending that each designer build their own CMS.

    Designers are free to do so, but IMHO would be wasting time reinventing the wheel. There are a great many Content Management Systems out there from simple to complex (see http://www.cmsmatrix.org ).

    In a CMS “Content” is defined as “the part you will allow someone else to modify/update.” If you are maintaining and updating the site yourself, it might be considered “the part of the page that will be different from page to page”. It is not limited to a discussion of certain html tags. It is an area on that page that the user can modify within certain parameters. Some CMSs like the most excellent Open Source Typo3 ( http://www.typo3.org ) provide a Rich Text editor where the user can choose basic word processor-type controls for justification, bold, italic, etc. However, they can only format the portion(s) of the page for which they have been given privileges.

    A site can be made up of multiple templates, and a large site can have multiple “content editors”, but (as the author correctly states) a redesign of the site is easily accomplished by changing the templates (and/or the CSS pages referenced by the templates).

    One wishing to “get their feet wet” with a simple example of a CMS could do worse than to look at phpWCMS ( http://www.phpwcms.de ). After you have learned some of the concepts, and are ready for a serious tool, I recommend looking at Typo3 which has been reviewed as the equal of CMS products costing tens of thousands of dollars.

  60. For sites that rely on dynamic content, the separation of content from structure and presentation is a necessity. Tools like PHP allow the content to be managed separately from the presentation and structure.

    The further separation of presentation from structure has its own benefits. CSS allows the presentation to be managed separately from the structure and content.

    Zope’s Page Templates provide a better alternative to tag-based dynamic content generation tools like PHP. In page templates, instead of adding tags that get replaced by the server, you add parameters to structural html tags that can tell the server to replace the contents of the tag, the tag and its contents, or even other parameters (e.g., class or href). By using parameters to control the dynamic generation of content, the template, with generic content, may be viewed directly in a browser and may be edited with tools like Dreamweaver without messing anything up. This makes it much easier to write and test CSS for dynamic pages.

    Page templates don’t do anything to automate the development of CSS, but they make it much easier for those of us who manage content separately (by choice or necessity) to accommodate separate presentation, and they allow the use of other tools that do help with managing presentation.

    http://www.zope.org/

  61. I was about to comment on this, but then I just noticed that there are already seven pages of comments for this.

    There is definitely not that much to say about it…

  62. I understand the idea of separating content (including its inherent structure) and presentation. It’s the whole “pure” XML thing that throws me off. Why would anyone want to have there data in an XML document? Why wouldn’t you just use an RDBMS like MySQL? I only have a couple years web experience and don’t know a whole lot about XML, so these questions are not just rhetorical. Give me some answers, if you like.

    For a small site it would be easy enough to code the XHTML by hand, no need for a database or XML conversion. And you would afford the opportunity to create an interesting visual presentation rather than just spewing out systematic information. (I am currently doing my personal site with php and MySQL as a learning experience and proof of ability. I know a dynamic site is really uncalled for.)

    For a large site on the other hand, systematic information spewing is a necessity. A relational database allows content to be retrieved, entered and updated efficiently. I don’t see how information in an XML document could be retrieved with the same efficiency (I learned SQL in a day or two, it is extremely simple). With XML wouldn’t you need to “read” the entire document every time you wanted to retrieve data? Or would you write multiple XML docs, one for each page of the site? Why not just write XHTML and avoid the whole XSL transformation step?

    Data (in database) -> server side script transforms to -> XHTML -> CSS for presentation

    — or —

    Data (in XML) -> XSL transforms to -> XHTML -> CSS for presentation

    Looks like the same number of steps.

    Or is the idea:

    Data(in database) -> server side script transforms to -> XML -> XSL transforms to -> XHTML -> CSS for presentation

    Why the extra steps?

    I must be missing something.

  63. Some responses where quite repetitive of what others actually said already, perhaps reading the article would have been appropriate for those of you.

    Otherwise this article was a great introduction (even if it was 5 months old) and for those who didn’t seem to realise soon enough should have given it some thought, as Michael has said already that he never did have the answers to this dilemma and I personally don’t think anyone ever will for a while to come.

    There were a few points I came across that I do have remarks to but I don’t have any intentions of making this post add to the ever-growing amount of responses already here, nonetheless I accept that there are methods that ‘attempt’ to do what this article is trying to explain. Although I do believe that content was never meant to be without structure. Its simply there to stay that way. 😀

  64. The lumping together of structure and content kind of struck a bad chord for me, which is why I chose to create my site using PHP. If you look behind the scenes, you will find that all of the page text comes from include files. In here, the creation of an entire entry is simplified down to a string array for settings and then the actual text. I can’t really explain it properly, and I’ll probably find a better way to do it eventually (perhaps even database driven as you pointed out in your article), but I understand what the dilemma is here.

  65. This reminds me a little of the separation model I often advocate for database development projects. The real irony of this article seems to be that it is supposed to be about content and structure, but it seems lacking in both areas.

  66. “Many content management systems provide varying levels of this kind of template support. However, full-featured template systems that make CSS Zen Garden-like usage of stylesheets — especially ones that come with a comprehensive content management system — are few and far between.”

    Whilst not as powerful as matrix systems cms, I am surprised that no one has mentioned Dean Allen’s texpattern (though someone did mention

    Its free, uses php, produces valid xhtml and uses CSSp.

  67. If you though that was confusing, you should see when I put out an article on my site, zachblog.com

    It about the seperation of behavior and CSS, from…everything else. If CSS is supposed to be used for styling only, and not for behavior, what about behavioral style, ala the :hover phesudo element. It styles a behavior, usually used in javascript(onmouseover). So I think thats where it gets REAL sticky…I’m sure someone else has wrote about this, but I’m going to post out my views anyways(NayNay-NayNay-NayNay)

    😛

  68. Thanks for the article… Im new to CSS, XML and stuff, i found the article really helpfulll.. Very well written. 🙂

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA