Separation of content structure and style in LaTeX?

In HTML, over the last decade or so, there has been a strong push toward complete separation of content structure and style. Most websites are now built using HTML for structural mark-up, and CSS for presentation of that markup. This makes it really easy to apply different styles over the same content: If you aren't aware of how powerful this is, see for instance http://www.csszengarden.com/. There is a W3c document making the case for separation of semantic and presentational markup.

I'm relatively new to LaTeX, but I have been designing websites for a while. Yes, they're different fields, but they're trying to do the same thing: present content well. My experience with LaTeX over the last 6 months leaves me feeling that this concept of separation of content and style hasn't worked it's way into the TeX world very far. For instance, to define the wrapping rules of a table cell in HTML+CSS is as simple as adding a class to the cell, and adding one line to your CSS document. In LaTeX, you need to do something horrible like this.

So, am I missing something, or is LaTeX? Is this concept of separation of content and style used in the design of LaTeX? Is it just poorly implemented? Is it likely to be implemented better in future versions (LaTeX3? ConTeXt?)?

Note: I mean no offence to LaTeX devs: the system is really nice for many other reasons. I just see this gaping hole, and little discussion around it, and I am wondering why.

-
Note that ConTeXt and LaTeX are different things (both TeX formats, but with separate conventions, developers and history). –  Joseph Wright Aug 27 '12 at 8:21
In fact, in web development there’s a push away from separation, if anything. Most if not all modern CSS frameworks require the use of styling classes in the HTML (such as grid specs). In LaTeX, I use a far more rigorose separation between content and layout. –  Konrad Rudolph Aug 27 '12 at 10:31
@KonradRudolph: I think that classes and IDs are considered semantic (this is an [object] of [type x]). What the CSS renderer decides to do with objects of that type is separate from the HTML. The class/ID doesn't have anything to do with styling unless the CSS specifies something: they can equally well be used for specifying objects to be manipulated with javascript, and potentially other uses (zotero uses IDs to screen scrape, for instance). –  naught101 Aug 27 '12 at 13:11
@naught101 They are only semantic if they are, … well, semantic. class="notice important success" is semantic. class="clear grid_3 large red" isn’t (the latter is an example of mixing 960 Grid System with Twitter Bootstrap). Most importantly, they violate the separation of content and structure: if you want to change the layout, you now need to change your HTML source code. This is what the separation wants to prevent in the first place. –  Konrad Rudolph Aug 27 '12 at 14:22
@KonradRudolph: sure. You can't really include sanity or intelligence of the designer in a web specification ;) –  naught101 Aug 27 '12 at 23:11

History

Knuth wrote TeX in the late 1970s because he wanted to typeset material as well as he could, given the limitations of his own knowledge and of the technology available at the time. It's generally agreed he did a pretty good job, but what he certainly was not trying to do was separate structure and style.

Lamport wrote LaTeX in the mid 1980s when he saw the need for a clearer separation of the two areas. LaTeX was revised in the early 1990s, and the current kernel dates from 1994 (with bug fixes, of course). This predates the HTML + CSS model by some time, and again technological limitations meant that further complication of LaTeX then would have been impossible. (In 1994, LaTeX was almost too large for many PCs, and the team worked very hard to squeeze it down.)

In the HTML world, new tags can be added and will be ignored by renderers which do not know them. That's not the case for TeX: unknown control sequences are errors. So we can't just add new concepts and expect existing documents to work: this is really important. So the decisions made in 1994 still have importance for LaTeX today.

ConTeXt is newer, and does separate out a lot more design than LaTeX 'out of the box'. ConTeXt also takes a different approach to stability than LaTeX, with a more active development outlook for the kernel. However, the ConTeXt approach is in some ways more like plain TeX than LaTeX, in the sense that ConTeXt keeps the design 'closer to the user' than LaTeX does.

Input and output

In the HTML world, a document is read entirely into memory to build the DOM for rendering. TeX does not work like that, at least unless we program it all ourselves. Instead, TeX reads a line and processes it before moving on to the next line. (LuaTeX can alter this, but I think even in ConTeXt it's still true that the TeX model is the main one.) As such, the approaches needed to alter appearance are very different.

A key thing to bear in mind when thinking about this area is what people want as output. In the TeX world, we are focused on high quality typesetting. As such, there will almost always be some manual adjustment of the design to reflect the realities of the content. That's not what happens in 'well written' HTML, and although it can be expressed in XML, it certainly breaks the strict separation. I and others would argue that this is no bad thing: you do need manual intervention to get the best results.

Tables

Tables are specifically mentioned in the question, and I think they deserve consideration on their own. In HTML, tables have been used for a variety of purposes. In TeX, there is a much more restricted approach to tables. Tables are famously complex beasts in the TeX world, and Knuth did point out that's it's amazing that they work at all! In most typeset documents, tables are used mainly for 'formal tables', and these have a pretty restricted range of 'good' appearances. As such, there is less need to provide the full range of CSS-like controls.

As canaaerus says in his answer, the TeX world is managed not by a committee but by no-one, and so what gets implemented depends on what individual users want. There are a range of table packages out there for LaTeX, plus the ConTeXt approach, and the raw \halign in plain TeX. However, they are mainly trying to solve other problems, which tells you where the priority for users is.

As a member of the LaTeX3 Project, I know that we certainly are discussing better separation of content and design. One issue that is worth bearing in mind here is that the HTML + CSS model does not always translate well into what we want for typesetting. There are some significant differences between the two areas, and that means it's never going to be as simple.

Any better approach has to work with TeX, both in code terms and for interface. We have experimental code to deal with the relationship between objects ('l3ldb'), plus the idea of 'templates' for design, both of which are in this area.

-
Hey, nice answer, thanks. One thing: "Any better approach has to work with TeX" - That seems a bit restrictive, which is fine for a project that's specifically designed to be backwards compatible, but does there come a point where LaTeXY has to renounce it's heritage because it's holding it back? (in a similar way to how Python 3 was the first non-backwards compatible version of the language) –  naught101 Aug 27 '12 at 11:43
@naught101 By 'work with TeX' I was primarily thinking about the sort of input LaTeX users are used to, rather than the technical side of implementation, and also the type of documents that are common (it has to for example work with the concept of pages, which CSS does not). If you read anything on LaTeX3 you'll see that at the code level we can't hope for back compatibility, so that decision is essentially made. But we do need to keep the document syntax (\documentclass ... \end{document}). –  Joseph Wright Aug 28 '12 at 11:22
Your history section should mention SGML. –  Martin Schröder Aug 28 '12 at 19:58
@MartinSchröder I know very little about the link or otherwise between LaTeX and SGML, other than knowing that SGML has been around for a while. I suspect you would be much better placed to address this in a separate answer. –  Joseph Wright Aug 28 '12 at 20:03
@JosephWright: A discussion about logical markup (i.e. separation of structure and style) without mentioning SGML is simply incomplete. –  Martin Schröder Aug 28 '12 at 20:05

Although this separation of content and mark-up is an idea certainly not foreign to TeX developers and users, there are some fundamental differences, between how TeX and HTML as well as their communities work.

HTML is, in its essence, centrally organized. There is a committee (namely the W3C), that develops the web standards. Then all authors of HTML documents must write according to these standards and the developers of HTML interpreters (i.e. mostly web browsers) must implement them.

For TeX on the other hand, things happen a lot differently. There are no definitive standards. Surely most things are based upon Knuth's original TeX. But a lot of things have been added. For example there are now different macro packages, ConTeXt and LaTeX. There you can easily see, how already the basic syntax is not fixed. Anybody could say he wants to use / for macros instead of \ like LaTeX does. Furthermore very much of the functionality used today is added as packages. They make TeX extremely extensible.

This leads us to the technical part of the difference. TeX is Turing-complete! HTML instead is just a mark-up language. In HTML you specify the content, structure and style of your document, in TeX you write an algorithm of how to build your document.
Of course in the most simple cases, you do not have to use complicated programming constructs and so a TeX document looks not unlike it was written in a mark-up language. But I would argue, that as far as these kind of documents are concerned, separation of content and mark-up is applied very well in TeX.

If you look at the example you gave, that is exactly the point where the documents stops being mark-up-like.

-

A big difference between a TeX-based workflow and an HTML-based workflow is the point at which the information is transferred from the author to the recipient. Both are systems whereby an author writes some text and that is translated into information on someone else's screen. With TeX the transfer takes place at the last possible moment and the author has a high probability of knowing exactly what it will look like. With HTML, the transfer takes place early on and the author has a very low probability of knowing exactly what it will look like.

This means that an HTML author and a TeX author have different interpretations of what "separation of content and style" mean. For an HTML author, it means that you send the content in one file and the style in another, and moreover that the recipient can apply different styles as they wish. For a TeX author, it means that you deal with them at different times when writing the document but when the document is sent, the style is "baked" into it. But this latter view means that it is not necessary to separate them at the document level.

So when you hear about "separation of content and style" in the TeX world, what it really means is "separation of concentration on content and style". In my view, what is key to achieving that is, firstly, not presenting the author with the final version right in front of them and, secondly, making it easy afterwards to modify things. The first means that an author doesn't have the visual problems "in their face", the second means that when they do see them, they can think "I'll deal with that later". The first is achieved by making it necessary to compile a document. The second by providing a programming layer. These, TeX has in spades (unlike HTML).

But it is not necessary to go further. The reason being that whilst "separation of content and style" is a nice idea, it is not necessary to TeX-based document preparation in the way that it is for HTML-based systems. You cannot tell by looking at a PDF if the author used "separation of content and style" or not. You can with HTML. So when designing the "separation of content and style" in TeX, the focus is entirely on the author. If something makes it easier for an author to make fantastic documents, put it in. If it inhibits this, leave it out. If it helps some but not others, make it optional. Enforcing a rigid system is not beneficial, so TeX doesn't. In HTML, though, separation of content and style has a huge effect on how the reader experiences the document. Enough that it is worth enforcing - or seriously encouraging - it in document preparation. TeX, on the other hand, provides the facility but then leaves the decision up to the author.

Of course, no system is perfect. But that's because it's people who ultimately author documents and no matter what is written on the tin, we are always going to try to do something a bit different that the author didn't think of. That's where TeX's programming ability makes it more flexible than HTML. But it can get messy because you are doing something the creator didn't think of (or didn't approve of!). That's the price for flexibility.

-
"For a TeX author, it means that you deal with them at different times when writing the document but when the document is sent, the style is "baked" into it. But this latter view means that it is not necessary to separate them at the document level." - That's not entirely true. It's quite common for different journals to have different requirements. Baking the style into the document just makes it difficult to adapt to these requirements (even though the content will be virtually identical). Even with LaTeX, there are intermediaries between the author and the audience. –  naught101 Aug 27 '12 at 12:06
Not so. It's still for me to apply the journal "style" to my article when I submit it. The reader doesn't download my LaTeX file, and the journal style file, and then combine the two. Moreover, journal "style" files are often a combination of style and macros making them worse than both worlds. –  Loop Space Aug 27 '12 at 12:19
In most cases, the reader doesn't combine the HTML+CSS either: the browser does it automatically, based on the CSS that you've specified in the HTML. Regardless of who does the combining, the base content and the journal style still have to be combined, which is made more difficult by not having good separation of content and style at the authorship level. I don't doubt that the process of applying journal styles is unsavoury :D –  naught101 Aug 27 '12 at 12:32
Yes, but the browser is running on the user's machine. That's the difference. As author, I can modify my document to get the output I desire possibly within constraints laid down by a journal. I'm not saying that separation of C&S isn't desireable, nor that it wouldn't make some things easier. I agree with both. What I'm saying is that the comparison with HTML+CSS isn't really a valid one. –  Loop Space Aug 27 '12 at 12:35

Is this concept of separation of content and style used in the design of LaTeX? Is it just poorly implemented?

It is used, and it isn’t necessarily poorly implemented (see the other answers for a historical perspective). Rather, it’s implemented on a quite low level.

You can absolutely use a rigorose separation of content and styling in LaTeX (and in fact I highly advise doing this). But in order to do this you need to take advantage of LaTeX’ capability of defining macros.

LaTeX has a few semantic macros such as \chapter and \emph (there are of course many more). There are document classes and packages which supply you with many more options. For instance, The KOMA-script classes provide a whole slew of macros to customise the look & feel of the semantic macros provided by LaTeX.

But in practice, which semantics you need depend very much of the type of document you’re writing. So there are document classes like scrlttr2 which provide semantic macros for the specific task of writing a letter, but those are the exception: Rather than providing a host of highly domain-specific semantical macros, LaTeX provides a language for building domain-specific macros.

Ultimately, your document should be free of physical layout macros, and use semantic macros exclusively. \textbf? Nope, use a macro describing why you want bold text.

Because they are so domain-specific, most macros you’ll need will probably be written by yourself. That’s why many LaTeX packages supply you with the tools to make this as easy as possible. For instance, there are packages to customise the display of figures (or to create custom figure types; see caption or float); there are packages that facilitate writing powerful macros (etoolbox and most of LaTeX3). And there are packages for many special use-cases such as highlighting source code.

With those, it’s relatively straightforward in most cases to put together a simple set of semantic macros which can be used throughout the document. Still, the macro definitions of my master thesis take up about one sixth (in SLOC, comments removed) of the complete document.

-
This answer has not received enough attention! –  Jubobs Feb 19 at 15:47

I certainly agree that separation of structure and style is one of the fundamental advantages of LaTeX and ConTeXt. That said, in practice it is difficult to avoid mixing them entirely. It turns out that only very simple documents can have style and content completely separated. A real life case of an even modestly sized book, almost always requires some last moment fine tuning, which effectively destroys their separation. For me as a publisher the most practical solution to achieve 100% separation is to always keep the contents in an xml file which defines the structure of the document and have all the style related instructions in a ConTeXt file. ConTeXt happens to be a very practical xml processor. Of course you can easily create a LaTeX file using XSLT out of your xml and use LaTeX if you prefer. In this case you should put all the style related instructions in your xsl file.

-