The long-held best practice is that an ideally structured website will have it’s content completely separated form it’s presentation. For websites, there’s no fault I can find in this approach. After all, you can change a lot about the site through some simple css tricks, stylesheets give you the most tools to work around browser bugs, and inline javascript is ugly and inflexible.

However, the situation changes when you stop making web-sites and start using the web to build applications. For one, markup is no longer there to suggest to a browser “hey I think this should be bold.” It defines necessary functionality for user interaction. Elements become interactive controls.

This doesn’t mean you can’t separate out the control functionality from presentation, but more that it doesn’t make sense. The fundamental reason for separation of concerns is to allow one aspect to change without the other. However, this no longer holds true. A pretty common semantic refactor is changing the ID of an element because it’s name no longer describes what it does. In JQuery, this means you’ll a situation like this.

<script type="text/javascript" charset="utf-8">
    function attach() {
        $('#submit_button').click(function() { /* do some nasty js for ajax */ });
    }
</script>
 
<button id="submit_button">Request More Info</button>

“Submit_button” is a pretty crappy name, so when you change it, you need to change two different places. The concerns aren’t so separate after all.

With a modern, interactive web application, it makes sense to put the functionality inline with the markup around the content. It’s how you would define things in most thick-clients anyway. It reduces the amount of problems that can arise through simple refactors. It’s also a cleaner for the code-base, since it allows one to move elements around without the need for a monstrous, custom-functions library.

Popularity: 4% [?]