Michael Eriksson
A Swede in Germany
Home » Software development | About me Impressum Contact Sitemap

Separation of content and layout


It is almost always a good idea to split content and layout; be it during own thoughts, development of software components, writing of documents (easier said than done, I admit, for those stuck with MS Word), or any other area. Doing so puts the focus where it belongs, avoids wasting time with appearances before it is actually needed (if at all), leads to fewer errors and better maintainability through a cleaner division, allows better opportunities to delegate work to other parties and let specialists work on their specialties, and so on.


As a rule-of-thumb: When layout and content issues must be considered simultaneously bad things are likely to happen.

In fact, the realization that this split is important is a very good indicator of ability in a software developer: Those who do not have it are rarely (never?) worth their money; those who do usually are. (Some reservations have to be made for mere lip-service.)

Unfortunately, far too few developers have this realization—and when we move to other groups, including business students, it is typically a rare exception.

Below I discuss some examples of how a separation, or lack thereof, affects work. An independently written article on WYSIWYG contains a more detailed comparison of LaTeX and MS Word in this regard.


In many works on writing, a sizable portion of the text is dedicated to discussing margins, spacing, how to write a correct reference, how a mathematical formula should look, and similar issues that are of little relevance to the actual work at hand. In contrast, LaTeX (and some other tools from the academic computer-world) takes the approach of providing logical mark-up, in which the user merely provides the content. For instance, the user writes his paragraphs, chapter headings, lists, tables, formulae, whatnot, and LaTeX automatically renders the content in a way thought out by experts. Even hyphenation is handled automatically. Should changes be needed, the specification of the layout is altered in one place, and the change is effective everywhere in the document. In particular, various scientific journals have different pre-packaged specifications (corresponding to the layout they require for publishing) that can be applied to a LaTeX document through a simple one-line include—no additional work is needed to make the document conform.

This has large advantages for the authors: They can focus on the actual content of the document. Clarity and originality of thought, correctness and readability of language, and so on, have the main seat—not sifting through a text to see that all margins are in the exact right place or that other semi-arbitrary typographic conventions are followed.


The reason for these specifications are probably originally to be found in the use of typed-on-paper documents for academic essays, master’s and doctoral theses, etc., not intended for large scale publishing. Even as late as the early eighties, computers were comparatively rare even in the academic field, and professional type-setting capabilities only really became available with TeX (for which LaTeX is basically a set of macros) at roughly this time. Further, unfortunately, TeX and LaTeX never made an impact outside of the hard sciences—possibly, because writers in the soft sciences very often can get by with the characters present on the keyboard of a typewriter, or because computers were rarer in these fields. (Notably, the first uses of computers where in areas such as number crunching—where mathematicians have a larger interest that students of literature.)

Web-design and -usability (big picture)

If we now look at HTML, it started in a similar manner: The author enters his text, headings, whatnot, in a corresponding mark-up language (the “ML” part of HTML), and the rendering is done by whatever client/browser the reader uses to access the document. Originally, the rendering and capabilities of HTML were very close to plain text: The possibility of linking was there, but the rendering was limited by the text terminals originally used. As GUI browsers became prevalent somewhere around 1993–1994 and, in the following years, commercial companies flooded the Internet, the development of HTML took a very unfortunate turn:

What should have happened was a development to something resembling LaTeX (in its capabilities, not necessarily syntax; and taking the differing field of use into account). Someone providing a web-site would have written his texts in a fix mark-up, put his navigational structure into a similar definition, possibly given some advisory layout instructions (e.g. a preferred background color), and similar. This would then have been rendered by the user’s browser according to his preferences and to what the browser makers considered usable. (Some modern CMS’s work according to a similar principle; but with the major draw-back that the end-user’s control is limited, and that the rendering of menus and other usability features are determined by the CMS instead of the browser.) The result would have been a high degree of user-friendliness, a consistent look and navigation (based on browser, respectively user preference), no nasty surprises, no need to have a specific browser to view a specific site, etc. With a bit of luck, although this may be over-optimistic, the average web-site might actually have had content worth reading...

What did happen: Layout was given priority, executives and web-designers obsessed over unimportant details, websites often required specific browsers or screen resolutions, every website had its own navigational solution, etc. New functionality was introduced in an incompatible manner by various browser makers (e.g. JavaScript or Active-X), or third parties (Java, Flash). All in all, a splendid example of the proverb “Too many cooks spoil the broth.”...

Notably, even today, HTML it self does not contain something so basic as a mark-up tag (respectively, set of tags) for the definition of menus; and many other functions that could today be an integrated and well-thought-through part of HTML are provided only by third-party solutions (e.g. RichFaces) or company-internal (and usually low-quality) solutions.

GUI development (detail view)

The obvious area of application for a software developer is GUI development. Rather than re-hash what has already been repeatedly written on this topic, I recommend the reader to brush up on the motivations of e.g. MVCw or Three-tier_architecturew.

In brief, however, consider the amount of work needed to replace one GUI with another or to port to a different platform/framework, the ease of maintenance, the level of abstraction and the independence of the back-end from the front-end, and similar concerns.

Generally: Separation of concerns

Separation of content and layout is a special case of the more general principle of separation of concerns. Importantly, however, not separating content and layout is almost always wrong; not separating other concerns is in many cases harmless (or does only limited harm). In some cases, it can even be beneficial, e.g. for sufficiently small applications. (With the major reservation that what is small will not always remain small: The assumption that a certain “easy” solution will be acceptable because a program is small, intended to be used once and then thrown away, or similar, has come back to bite many a developer—often on repeated occasions. Err on the side of too much separation even privately; do so even more in the office.)

Further, only rarely will the general public be exposed to other special cases of separation of concerns than content and layout: Partially, this is something that happens in the implementation, where they cannot spot it; partially, things that should be done with separation are not—often with the claim from the software makers that it is easier or more “user-friendly” that way. (Typical office packages and WYSIWYG editors provide good examples of this.)