-
Content Management, Markup and Doing it Wrong
A few days ago I put out a poorly worded tweet about my feelings towards content management systems that leave traces of their own HTML in the frontend markup of the sites that they power. I said:
If I can tell what CMS you are using by looking at your markup, you are doing it wrong.
Of course, my emphasis here was all wrong - it sounded like I was putting blame at the feet of the user, rather than the CMS, which is not at all what I intended. After getting a few questioning responses, I tweeted a clarification:
To clarify: If I can tell what CMS you are using from looking at your markup, *your CMS* is doing it wrong.
What am I talking about here? In my mind — and in vastly oversimplified terms — a CMS should exist to provide a nice way to store structured data, map URLs to some kind of template/page and give you access to the data stored within it via some sort of templating language.
It is definitely not the job of the CMS to wrap that data in it’s own markup. How can it be? It can’t know ahead of time how I want my markup structured. It doesn’t know the template context that I’ll be using that data in, or how I like to write my markup. It doesn’t know wether I want to use double quoted attribute values, or if I want to add microformats when I output it, or whether I’ve decided to use an OOP-style CSS strategy (and it’s accompanying bevy of classnames) for my project.
So let’s step back a little and look at the different ways that a CMS can include markup in their output. I’ve started by lumping them all together, but that is a little unfair - some CMSs do this in ways that are far more toxic than others.
Starting at what I see as the optimum end of the spectrum we have content management systems that quite literally provide you with a blank slate - no default templates, no default markup. ExpressionEngine is a good example of this kind of CMS. It gives the developer a templating language powerful enough to extract content from it’s structured data store (the structure having previously been defined by the user) and you have complete control over what markup you choose to wrap around the discrete chunks of content. It has a powerful plugin architecture, but instead of these plugins providing direct HTML output, they typically just extend the templating language to give you extra tags to work with, so you can once again use your own markup to display the content with.
Then we have systems like Wordpress, whose templating language similarly attempts to provide you with access to the discrete items of data within it’s database. However, this templating API often returns content ready wrapped in HTML, such as when retrieving a list of categories or pages. Thankfully you can often customise this markup by passing extra variables into the function that is being used to retrieve the data, but this still feels inelegant to me - why jump through all these hoops when you could just give me back the data and a standard way to iterate over it and then I could build my own markup around it?
A perhaps bigger issue is that because the Wordpress core has set the expectation that generating output in this way is a good way to do things, plugin makers have followed this convention, but often with less regard than the core dev team for providing ways to override the default HTML output that they produce. So by using these plugins you are relying on the (often pretty shaky) frontend development expertise of the plugin developer to craft your markup for you. Not ideal.
And then towards the other end of the spectrum we have systems such as Drupal, which output large swathes of HTML by default, and often with little or no regard for correct use of semantics or for giving the developer the ability to override the markup with their own, or even customise small parts of it, such as the class names used. Each third party plugin typically brings it’s own large chunk of HTML output with it, which often reflect the plugin authors own style of writing HTML and which rarely (if ever) meshes seamlessly with the other generated output that is sits within.
Now, don’t get me wrong. I do think there is a place for content management systems that come with pre-packaged templates, such as Wordpress with it’s default themes. Obviously there will always be a large number of non-tech savvy people who want to set up a blog and don’t want to have to learn a bunch of markup to do so. But the templates should be just that, templates - and they should be directly editable as such. No one should have to go passing umpteen arguments into a function to customise the classnames attached to their unordered lists.
And, perhaps more controversially, I think that professional frontend web developers, those who really understand the difference between good and excellent frontend development, should steer away from these content management systems (or else be prepared to spend hours digging around in their internals to wrangle the markup to fit their own standard and style).
Yes, generated markup can save you time. But you can easily create a library of reuse-able template components for a CMS like ExpressionEngine that give the same time saving benefits but which is written in your own style, and more importantly can be easily customised to fit specific use cases - adding microformats, removing superfluous class names, or single quoting those attribute values… should you feel like it.
In short, I think that markup is too important to be left in the hands of the people who make content management systems. They all too often don’t care enough about it, and they can never know the context that you will be using it in, and so in my opinion they shouldn’t be trying to guess.
