Over a million developers have joined DZone.

Creating good content mark-up: Content Management Systems vs. hand-crafted HTML

DZone 's Guide to

Creating good content mark-up: Content Management Systems vs. hand-crafted HTML

· Web Dev Zone ·
Free Resource

There’s an inner beauty of HTML code that I can never seem to get away from. The wonderful world of semantics – choosing the right element for the right task, something that conveys meaning, makes it more accessible and strikes the perfect balance of different parts of a web page. Which moves us on to Content Management Systems.

Content Management Systems’ editing of today

As a result of this, naturally, it becomes quite saddening when working with Content Management Systems. Usually an Interface Developer code templates for the framework of the web site’s pages, all structural parts, navigation etc. Then on top of that there is a content area, usually the main text of an article, where editors of the company behind the web site will write text and create content.

And depending on your CMS of choice, that content, HTML-wise, could be either terrible, decent or good – but then we’re only talking about the validation level and, at best, some sort of semantics for it. But getting perfect semantics, trying out new/alternative elements (especially with the new-found semantic richness HTML5 gives us) and constantly tweaking the details just doesn’t happen, and the HTML result is usually mediocre.

Where is the problem?

So, where lies the problem? How come practically no detail is put into the HTML of the content area? There are three factors to look into:

  • The Content Management System
  • The editor writing the content
  • The Interface Developer’s role

First, as long as a CMS offers the way to create semantic elements in any sort of fashion, like heading elements, paragraphs, lists etc and outputs valid HTML, it has sort of done its part. They do have a challenge, though, if/when they want content creators to create forms, tables and layout, and they definitely do need to look into HTML5 options as well, for the future.

When it comes to editors, and there are many different opinions about this, I personally don’t think they should need to know about HTML. Their job is to write good content, not to know about code. What they need to know, however, is how to mark up different parts of their content accordingly with headings, lists and so on, and, very importantly, write good and descriptive link texts.

From an Interface Developer perspective, all that can be done is influence the choice of CMS and WYSIWYG editor and try to educate the editor how important it is to have a distinction between different elements in a web page, for SEO, accessibility and code maintenance (when we talk about potential bugs/problems for the Interface Developer to support later on).

What it could be like

A couple of years ago, I was working for a company providing online gaming, and in their case, they had copy-writers putting together good texts with good structure, keyword density, the works. But, they were never allowed to put it into the actual web page – instead, their finished documents were sent to an Interface Developer who carefully made sure to mark it up in the most optimal fashion. Knowing and respecting the importance of good HTML code, for so many reasons, led to extremely streamlined, optimal and maintainable code and great results.

The downside of this, of course, is the potential time it can take for an Interface Developer to do this, but my experience is that getting things right the first time is so much more important than constant fixes and workarounds later on; also, getting things (at least closer to) perfect directly is such a mental relief for anyone involved.

Conclusively, I don’t see an optimal solution for this, but if you have the appropriate skill sets in your team and it works out workflow-wise, I’d recommend having someone who knows HTML be the last one to touch the content before it is being published.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}