LearnThe separation of structure, presentation and behavior is dead


writes on January 24, 2012

The separation of structure, presentation and behavior is dead. It has been dead for a while. Still, this golden rule of web design sticks around. It lives on like Elvis and we need to address it.

I remember the weight of separation vividly. I remember writing custom JavaScript to replace the <a> tag’s target attribute because it added behavior to HTML. I remember dropping the <font> tag from my arsenal of tools, something I don’t regret.

In principle, the rule of separation was good. It helped us explain the best practice and implementation of HTML, CSS and JavaScript. It spun the web toward a brighter future. Separation vanquished the <font> tags, spacer gifs and inline JavaScript that polluted the web for years. In the old web structure, presentation and behavior lived in one layer but the principle of separation divided them.

The old web

The Path

The principle of separation lead web standards into victory during the first browser wars. Separation did not do this by eliminating proprietary standards, but by defining the “path” for new standards like CSS and XHTML. Through this victory browser makers work together now, for the most part. Browsers prefix proprietary CSS and push together for new technologies such as HTML5.

However, separation was an old idea that lived hand in hand with XHTML 2. The idea was that structure, presentation and behavior should be at all times pure. Separation like XHTML 2 has seen its day. Just look at the current state of our specifications. The proof is in the pudding.

The Truth

CSS now has behavior with features like :hover and animations. CSS has structure as well with the pseudo elements ::before and ::after. HTML has the same issues. Its new <input> types have behavior and presentation littered throughout. What the web currently looks like vs what separation wants the web to be is not the same.

The way the web really looks

The specification says separation is dead and the browser makers agree. Last year at SXSW during the browser wars panel I asked the panelists for their thoughts. I asked them what was to keep the <font> tag from coming back and why separation was not being addressed. Brendan Eich answered quickly and simply, “We don’t care about separation.”

He is right to say this. Separation has played its roll. But if he is right and we live in a new age, why do we we still teach separation? Why do we still pretend to follow it? I have a few assumptions.

Why Separation is Still Around

First, it worked at a basic level. It let us know when we were getting into gray areas. Second, the principle was simple and easy to understand. Each technology has its place, HTML, CSS and JavaScript.

So then, what should we do? Ignore all reason and do whatever we like? No, of course not. We need to be honest with ourselves and understand the raising pattern: Divergence.

We have been using Divergence for years. With every site you include :hover in your CSS. With the “email” value you use as your <input> tag’s type. With the many jQuery plug-ins that add new structure and presentation to a site. You use Divergence.


What is Divergence? Divergence is the process you take when any of the three layers of separation cross. Let’s think about what we know the web is like today.


As an example let’s examine a scenario where presentation and behavior cross, such as when you need a design change as the cursor moves over a link. You need to pick CSS or JavaScript.

An example

JavaScript has the mouseover event handler and CSS has :hover. However, you want to add a presentational effect, a nice underline maybe.

During the crossover of the two layers we are forced to choose CSS or JavaScript. You could choose CSS because you want to change the link’s style, but you could also choose JavaScript because the change is triggered by a behavior.

Unlike separation where you are trapped, Divergence says this is fine. In Divergence the lines can cross.

Think of Separation and Divergence as totally different logical approaches.

With Separation you live in a true and false world. Everything is black and white. It is on or off. It is Boolean by nature. With Divergence there’s black and white, but there’s also gray.

Truth is Conditional

The first rule of Divergence is that truth is conditional. Presentation can be behavioral and vice versa. We can use CSS a presentational technology with behavior as in the case of :hover.

However, Divergence does one thing that keeps it from creating a world where anything goes. To understand that concept we need to look at the <font> tag and understand how divergence keeps us from using <font> just as the principle of separation does.

Under the “conditional truth” rule of Divergence the <font> tag is fine. It is presentational and structural. However, with the second rule of Divergence there is an issue. This is the rule of “wholeness”.


The <font> tag is in HTML so it is a structure. However, it is not semantic and so while it is a structure it is not structural. The rule of divergence says that an item who falls into conditional truth is fine. It can be both structural and presentational at the same time. The <font> tag is.

However, the <font> tag must now pass the second rule. This rule, wholeness, says that the item must by nature be compliant wholly… to at least one of its parts. This does not negate the first rule. It only approves the item has the properties of the layer in which it lives.

Wholeness works like this:

  • An item who is in structure must have the properties structure. In other words HTML must be semantic.
  • An item who is in presentation must have the properties presentation. In other words CSS must effect presentation.
  • An item who is in behavior must have the properties behavior. In other words JavaScript must effect behavior.

Divergence says that items can have multiple properties but can only operate from a layer if it belongs to it in wholeness. This means that the item itself must have the properties of the layer it lives in and can demonstrate the properties of another layer if it likes.

Where <font> Fails

The <font> tag meets the conditional truth of Divergence but is not fully structural. It demonstrates the properties of presentation in that you can set “font properties” with it. But, it can not belong to structure because its structural property is not structural. This is because the tag name is purely presentational – “font”. This means that it doesn’t belong fully to at least one of its parts.

Therefore it can not diverge to one side or the other. HTML or CSS. So, we can not use the <font> tag under Divergence.

The principle of Divergence is simple and complex. It apples to all layers of web design.

Some Examples

As a quick example we can say that the HTML5 email value of the <input> tag’s type is fine under Divergence. It is semantic and behavioral but complies wholly to at lest one of its parts HTML.

Simply using the pseudo elements ::before and ::after to create content as structure and not presentation is not divergent because it is not fully presentational. Not to mention inaccessible.

It is unfortunate that the world of web design is not black and white and fortunate at the same time because it moves us forward.

To Round it Up

We are standing in a new age. We need to stop saying separation and doing divergence. In the end we can pretend that the principle of separation is still relevant but it doesn’t support the current direction of the web. It doesn’t help standards and browser makers don’t care.

Most importantly we need practical principles to guide us. So we know when to say yes or no to new features in CSS and HTML so that we can keep one eye on the vendors and the other on the web’s future. We need to accept the fact that separation of structure, presentation and behavior is dead.


Learning with Treehouse for only 30 minutes a day can teach you the skills needed to land the job that you've been dreaming about.

Get Started

32 Responses to “The separation of structure, presentation and behavior is dead”

  1. Rob Reed on October 7, 2016 at 5:42 pm said:

    SoC has been around long before web developers decided it was inconvenient. Is it a little fuzzy, sure. But so are all principles. The fact that people lie every day of their life is not a reason to abandon the the principles of honesty and integrity. I’ll grant you that separation of concerns is overly simplistic. But must less so than the idea that it’s dead.

  2. Just 2 cents, on the post.

    i would agree in a number of things. Like “separation” etc is indeed **dead** and continues to die everyday from bad apllication, programming and insufficient understanding of what it means and what problems (if any) it addresses to solve.

    So yes i agree with this and also take this a little futther and say that using a different terminology (e.g “divergence”) does not (necesarily) solve the issue either (see reasons above).

    Furthermore, all the “immutable maxims” e.g “HTML is for structure”, “CSS is for presentation” and so on are in most of cases **empty statements**. Why?

    Let me tell you why. The whole point of using any strategy or design principle is to make good code that works and is flexible enough to be reused and also be updated with the least, necesary amount of extra work per updated feature.

    HTMl , CSS and all that are NOT design principles in this sense and they are not obeyed most of the time (e.g think of “popular frameworks” which actually generate all the HTML/CSS in Javascript). HTML is only used because browsers work that way, not because it represents any intrinsic design principle (for example browsers could very well work with javascript/json for “structure”, maybe even “future browsers” will do that).

    In this sense where and how to use and generate html / css / javascript takes a completely differrent aspect.

    So, if according to given needs and purpose one decides that doing everything with javascript or CSS is the best approach, she should do it and that would be a good thing to do. So lets stop polluting new programmers brains with principles that are not principles at all but rather limitations posing as principles and let them decide on their own based on their own use cases, the optimum approach and representation to take.

  3. I’m against using the word “dead” for separation. It’s still out there, and the underlying rules which propose it are really solid. I think we’re just playing with words here. Using JavaScript or jQuery to give a class to an HTML element is not bad, because what we do here is called taxonomy, and that is the responsibility of scripts. However, we shouldn’t apply styles directly on elements (like changing the color to red) through script, because that is the responsibility of the CSS and styles.

  4. I think there’s a boat here, but we’re all missing it because we’re standing a few inches away from the hull haggling over the type of rivet used. Stand back and look at the big picture for a moment.

    Separation is just a principle, and all good principles can be “separated” (no pun intended) from the technology and still make sense as a principle.

    When content/behavior/presentation separation was conceived, we put the barbed wire fences up around CSS, (X)HTML and JavaScript because it seemed to make sense at the time. Each was uniquely suited to its respective task and there was relatively little overlap.

    That’s changed a bit, but there’s lots of ways to achieve separation besides the language used, and there’s no particular reason that language is a better place to draw the line in the sand than any other.

    Case in point — many developers make a living by separating their content, behavior and presentation by following a little principle they call MVC. They are able to produce great stuff that’s separate, modular and maintainable — and yet somehow WITHOUT using three different languages to markup each of the three segments in that acronym.

    So while I fully agree that separation is a great principle to follow for front-end development, separating it at the language/markup is arbitrary and the only reason “divergence” even exists.

    When it comes to separation it’s the process that matters, not the final rendered code that gets sent off to the browser. THAT’S why vendors could care less. We have the tools and technology to build backend systems that maintain a perfect separation of content, presentation and behavior if we so choose. So what if they cross the boundaries of markup?

    Worrying about separation at the point where its rendered and delivered to the browser is silly. It’s like worrying about the purity of markup in the PDF file you’ve generated and sent to your printer, or the ZIP file full of content and imagery you receive from a client. It’s like a software developer worrying that when he compiles his application, all of his nice, clean, object-oriented code gets mashed into a single EXE file.

    So just gather up all those trendy CSS3 animation rules and/or your :hover states and put them in a separate file labeled “animations.css” or “behaviors.css” — whatever makes sense. Voila! Separated. Bonus points for combining, compressing and caching these back into one file before serving them.

  5. Structure of chromosomes during the g1(growth1)
    phase, the chromosome is single because the cell just underwent
    mitosis. after growth 1, the cell enters the s phase (synthesis phase), 

  6. jQuery Rocks on January 30, 2012 at 6:58 pm said:

    I think this is a fairly good summary of what might be called “The Philosophy of Modern Web Development” – or at least an aspect of that philosophy.  It is true that in recent years, the capabilities of HTML, CSS, and JavaScript have blossomed, creating a much more diverse web ecosystem – due in great part to HTML5 and CSS3, and components of these new specs that were around well before the standards were formally established (Apple’s creation of is a great example).
    Interesting piece.

  7. I love the presentation of your Idea its very clear. But I’m not quite sure that all the people agree on this.

  8. Checks and balances. No one branch could get ultimate power over the others.

  9. I believe that you’ve made a category mistake.

    “Separation(etc)” is not a feature of browsers, or of any other product or technology.

    Its usage (for example, in a software project) is normally managerial, not in response to the necessary implications of any given technology stack. 

    Additionally, canonical definitions of its components do not exist — compare to “MVC”.

    The metaphysical replacement proffered is unnecessary.

  10. Rather than see this as a new theoretical framework,  I think its better to view this shift as attempt to lower the bar of entry to modern user experience best practices. 

    As several have discussed before, the appropriate use of separation and divergence depend entirely on the scope of the project and temperament of the person (people) developing it. It seems more likely that behavior is creeping into presentation and structure because of the practical divide between people whose responsibility has traditionally been structure and presentation (ie.  designers) and people whose responsibility has traditionally been behavior (programmers). 
    A fully fledged implementation of a behavior mechanism carries with it complexity that is usually outside the scope of a designers mastery. Pseudo classes in CSS allow non-programmers the ability to implement basic and frequently occurring behavior without having to learn or master any additional complexity. Ditto for HTML5 input fields. 

    The point at which you are mixing these strategies is where we run into trouble,  and why the trend towards divergence is concerning. If the entire scope of your behavior is captured in CSS then it seems like a wise decision to avoid the overhead associated with JavaScript. But,  if that behavior needs (or worse,  grows to need) flow control, set theory, iteration, or more advanced repeatability,  then its time to refactor – clean out the behavioral aspects of your presentation and commit fully to the complexity and power that comes from JavaScript.

    Otherwise you don’t have separation or divergence.  You just have bad implementation.

  11. Call it whatever you like. How the idea of separating behavior from content needs to be revised?…it just do not make any sense.The fact the you can use it does not mean you have to. Different projects may need different approaches, it is not the same to for example, develop a simple slideshow than a online store.

  12. It seems to me that this discussion is pointing to what I think is the existence of a 4th dimension.  There’s structure or HTML.  There are colors, widths/heights, positioning, etc. or CSS.  There is logic, processing and functionality or Javascript.  Then there’s another dimension where this “divergence” layer exists.  It encompasses things like animation, interactivity, visual effects and increasingly things like audio and dynamic interactivity. It is the dimension where the rubber meets the road or the user interacts with the content.  It is the invisible layer between the user and the content.  The layer where the “interaction” happens.  This interaction can be mechanical, tactile, visual and even audible and vocal.  It is the world of clicking, rollovers, touching, swiping, dragging, scrolling, typing, watching, listening and even moving.  What I am referring to is a layer that hasn’t really been fully exploited in web design/development before.  But it has existed in the world of more immersive and interactive content such as video games or plugin powered content.

    With the latest advances in web development technologies we must begin to move away from old paradigms and begin to embrace practices that take this dimension into account.  As the web becomes ever more accesible through ever more places, devices and technologies it will also become more dynamic and immersive.  Designing and developing in that environment will require thinking more deeply about the reciprocity between your content and the user.

    This is why I think the HTML/CSS/JS paradigm for web development must change to a more dynamic and fluid one.  If we ever hope to have web based content be as good as native content, the technologies and practices used to develop it must change.

    Designing and developing with structure, presentation, behavior in mind is fine.  But taking into account the layer that stitches them together is becoming ever more important.

  13. Great Article. Needs re-edit. Someone should have stuffed you into a room and forced you to get clear on what you are talking about ‘cus you’re ideas are worth it.
    I am in process of converting my website from XHTML into HTML5. The iteration is temporary, as I plan to next convert to a Responsive+mobile1st design and re-work my branding. However, this first iteration is a necessary step to make my HTML as semantic as possible. Meaning – my goal is to make my mark-up “content-first” (content only?) so that I can change the presentation easily in CSS and re-purpose the content. I think that is the value of “Pure Structure”. I’m not perfect. I still have a lot of little class=”” presentation hacks in my HTML. . . but thanks to advice from people like you I am on my way! Thanks.

  14. Good stuff found here. You and I have had this discussion before.  While I’d agree on some points, I would say that while if may not work anymore semantically, I do believe separation is still a good thing organizationally.  I’ve found that keeping these things separate, where possible just simply makes for a better file structure and a more organized work flow. If for nothing else…

  15. CSS3 is pretty powerful and definitely blurs the limit between presentation and behavior, but as developers, I think it’s still useful to make separations where it makes sense to us, at least for collaborative or maintenance’s sake. 

  16. Jonathan Kelly on January 24, 2012 at 11:43 pm said:

    I like the clarity. However, don’t you mean Convergence?

  17. I had some mental distress when CSS animations and transitions started becoming prevalent. “Aren’t they behavior?”, I thought, “Is that not a gross neglect of the concept of separation?”.  After much consternation, I came to a conclusion that has helped me come to terms with the new way (and does indeed conflict slightly with the central conceit of this article, that separation is “dead”) :

    Animations and transitions are not behavior. They are, in fact, presentation. The behavior (which is handled by javascript) is actually the DOM manipulation (usually a class change or similar) triggered by a user interaction. The subsequent change in appearance of the DOM element and its accompanying animation is very much presentation, and is best handled by the CSS layer. These days, changing the appearance of an element via a JS animation feels very wrong to me, and indeed, when I can help it, I don’t write fallbacks for browsers that don’t support CSS transitions/animations.

    Sure, things get a little fuzzy when talking about CSS :hover and browsers’ native validation of the new form fields (I do believe, however, that ::after and ::before are presentational and not structural as they don’t show in the document outline, so CSS is the right place for them), but as far as animations and transition go, I believe that we’ve been considering them in the wrong category for a a long time.

  18. Anonymous on January 24, 2012 at 8:34 pm said:

    Very interesting article, thanks.

    It reminds me of how Quantam Physics turned Newtonian Physics on its head.

    We don’t entirely throw out our original understanding even though we know things are more complicated in reality.

    We use both to fly to the moon.  🙂

  19. Dean Peterson on January 24, 2012 at 7:51 pm said:

    Separation of concerns is a “best” practice.  It is simply best to keep these things as separate as possible for development and maintainability purposes.  Of course there is going to be overlapping between them, we live in the real world.  

    “Dead” is the notion that everything can be absolutely separated, not that keeping them as separated as much as possible.

  20. OMG, this is going to create infinite confusions to the new and old school developers. New web developers are going to continue the old way. Old school developers are going to be lazy after reading this article. 

    I would update the article title as “What’s next, after separation of Structure, Presentation and Behavior”.

  21. Anonymous on January 24, 2012 at 5:28 pm said:

    It seems your title is a bit over-reaching in its statement.  Separation is always beneficial, and browsers do care–or at least reward you for it.  By separating your presentational and behavioral rules, the browser will cache these for future pages that reference them.  Furthermore, it is truly beneficial from a maintenance standpoint: edit one, affect all.

    • Anonymous on January 24, 2012 at 6:49 pm said:

      To clarify on the browser’s not caring:

      I’m not say that they do not care about standards. They do. When I was at SXSW last year the panel of the “Browser Wars”, this included all of the vendors, agreed when I asked them directly if they cared about the separation of concerns. The answer was quite literally “no”. They said that it was basically something they could care less about.

      Firefox, IE, Chrome and Opera if I remember correctly

  22. So, executive summary, separation is good but there are gray areas.  We accept that and move on.

    Yup, agreed.  That doesn’t mean such separation is “dead”.  (Although I’m sure that was just an attention-getting headline, which I fully appreciate having used the same myself before.)

  23. As this is a perceivably controversial stance that you’ve given a name and everything, I want to call you up on it because I believe your message is muddled and does not apply to all development environments.
    Your example of making a decision on behaviour when considering the CSS :hover pseudo-class is moot.  You wouldn’t decide to style simple anchor text with an underline on hover using CSS embedded within JavaScript, for instance. You could, but it’s a Bad Idea.  You may however decide to do things like add a class attribute to an element whose styles reside in a style sheet when the mouseover event is triggered.  Or you may want to initiate a complicated effect which could only reasonably be implemented using JavaScript. The complexity of implementation correlates with the complexity of the design.

    Where behaviour crosses over into presentation and via verse[sic], it is usually because of the deficiencies of a platform or because the presentation is intrinsic to the behaviour (hiding elements, animating between styles where CSS can’t handle it, etc.)If you’re working by yourself and are just pulling in jQuery plugins from around the Web, then you are going to run into all kinds of sloppy bloat, where presentation is mixed in heavily with behaviour, and you won’t have to worry about the ease of access for other developers – but this isn’t planning for the future.

    If you’re working on a project with a few developers and your designer is not your front-end engineer, then separating the two can become vital.

    Separation of concerns isn’t dead, it’s a cornerstone of good development practice – so in the end, it’s not about separation vs. “divergence”, it’s about what’s best suited for your project, and you are going to have to make some intelligent decisions about how it is best in the long-term to divide your structure/behaviour/presentation, and these decisions are usually based on maintainability, scalability and performance.

    This isn’t a new thing; and it’s been going on since the “tables are bad for layout” arguments that I encountered when I was starting out.

    I don’t mean to be snide (it’s hard to avoid when leaving a comment like this) but you may also want to proof-read before making sweeping commentary, because it really doesn’t help convince the reader if the message is full of typos.

    • Fen, thanks for your thoughts. And, if I may I do apologize for the typos.

      I do agree with you to a degree. My thoughts on :hover come from http://adactio.com/journal/857

      Still. I can not play the fence and say that I think Separation is valid for today’s development practice. I do think is is good at a basic level. It can still be used as a guide in process. However, the idea was based on the thought that XHTML would run the web. This is simply not the case from my understanding of current trends.

      Again, this is the principle I use when making choices about standards when the lines cross.

      Thanks again for your comments.

  24. This was an interesting post to start my day with. I do really like the concept of simplicity that comes from complexity presented here. It’s true that things are very different. My question is will this help or hurt the web industry? I believe it will help, but with anything that isn’t clear cut many discussions and disagreements will emerge. I must admit I like the steadiness of separation, but know that the web is far more complex. Nice post sir!

    • Thanks Steve. Your question is much like mine. I’m not sure how these recent changes in the direction of the standards specification will influence the web. Or, as you asked if it will help or hurt.

      Still, separation of the three layers is good at a basic level. As you and I agree. Separation is a good principle and I don’t want to undermine this fact. However, we need to be honest and realize that the web has changed and other solutions need to be investigated.

      For me Divergence is the answer for now. Still I hope that one day we will not need such complex ideas to help us make basic choices.

      Thanks for your thought 😀

Leave a Reply

You must be logged in to post a comment.

man working on his laptop

Are you ready to start learning?

Learning with Treehouse for only 30 minutes a day can teach you the skills needed to land the job that you've been dreaming about.

Start a Free Trial
woman working on her laptop