All of you might be scratching your heads and thinking: "what was the point of the history lesson of that last post Paul made?" Essentially, I wanted to show how the languages we use to build websites today have evolved towards the "separation of concerns" principle. Nevertheless, we'd likely have a more fool-proof solution if HTML, CSS, and JavaScript were all invented concurrently.
But this has happened over time, with a large number of corporations and organizations influencing things along the way. Netscape, Microsoft, Mozilla, and the W3C have all played major roles in the adoption and standardization of these languages; web standards is the broader long-term goal of the web development community that encompasses the separation of concerns principle discussed here. As web developers, we must make due with the end result, adhering to this principle as best as possible.
Separation of concerns, a recap
| Concern | Layout | Presentation | Behavior |
| Language | HTML | CSS | JavaScript |
The table above summarizes the separation of concerns that I talked about in my last post. The concept of separating away the presentation of your web page isn't a terribly new idea. However, once we begin to look at the details, we see that the separation of concerns cannot be as neatly segregated as it is in the above table.
Funky capabilities of CSS
If our webpage doesn't change its appearance as it's being used (i.e. it's static), CSS does everything we need it to. With the flexibility of absolute and relative positioning, we have a number of options. Also, the CSS 2.1 specification itself allows us to radically redefine HTML elements. For example, the CSS table model allows us to make any HTML tag display data as if it were a <table> tag.
Furthermore, you can do a lot with the CSS ":hover" and ":focus" styles (such as dropdown menus, styled forms, even circular links). Here are some very impressive, purely CSS examples.
CSS browser detection hacks
The unfortunate side-effect of a complex CSS stylesheet is that it will inevitably render differently across different browsers. If your stylesheet isn't too involved, you can always make adjustments so that the cross-browser variations are so small they are barely noticeable.
As we'd expect, this solution simply isn't good enough for some situations (e.g. a perfectionist designer or a demanding marketing team). In these cases, many resort to CSS browser detection by exploiting bugs in older versions of Internet Explorer , or the use of conditional comments. Although these methods are frequently frowned upon, they are nonetheless used because no other option exists (within the realm of pure CSS programming).
Look-and-feel limitations of CSS
Despite all the fancy things we can do with CSS, sometimes we want to introduce a look-and-feel element to a website that unquestionably requires the use of JavaScript. Many JavaScript APIs exist solely for this purpose -- moo.fx is an example of a popular one.
Strictly speaking, this breaks our separation of concerns model. However, dynamic graphical effects such as these fall into somewhat of a grey area, as some developers consider these to be a behavior (versus presentation) component.
Pure CSS: Great for many, lacking for some
We can do a whole lot with CSS; in all honesty I didn't appreciate just how much you can do until I blogged about it. In fact, it's my opinion that the majority of a website's visual requirements should fall within the capabilities of pure CSS.
Something like a fading / sliding menu seems to me to be a frivolous reason to go beyond CSS (use JavaScript) and break the separation of concerns principle. Then again, I try to be somewhat of an idealist in this regard.