¶ Content and Presentation Are 3 · 18 January 2006 essay/tech
At the moment, the tools for online publishing were mostly designed by software people for an audience of other software people, so it shouldn't be too surprising that by real (i.e., pre-/non- online) publishing standards most of them are not only fairly terrible in particulars, but basically comprehensively alien and unresponsive down to the conceptual model.
The reason the HTML-tables-vs-CSS-blocks war wasn't over ten minutes after CSS was invented, for example, is that the CSS float/span/margin/escape model chose (more in ignorance than defiance, I'm sure) its own internal geometrical cleverness over the potential applicability of centuries of conventional information design. The most basic tool of scalable information design is and has always been the layout grid. CSS is capable of producing a simple layout grid, but not simply. Arguably it's even harder to recognize a page layout by reading its CSS than it is to write the CSS. Structural elements are structural by convention if you're lucky, coincidence if you aren't, and certainly not by nature, and are unavoidably cluttered by non-structural formatting elements.
An HTML table isn't a good tool for page layout, either, but for the most part a simple layout grid can be expressed by a simple HTML table, and with decent code-indentation it is possible to more or less grasp the presentation structure of a simple table by looking at its code. The fact that tables require the content and the structure to be intertwined is a huge problem, and the fundamental misconception of the scheme emerges the moment any kind of table-nesting is required for page-structural and/or content-structural reasons. The non-programmer's mental model of a box is an actual box. You can put small actual boxes inside larger ones. If you forget to put a bottom on a small box inside a large box, you get a bottomless small box inside a normal large box, not a deformed small box falling out of the bottom of a mangled large box. Nobody, not even a programmer, intuitively thinks of object construction procedurally, and nobody but a programmer (and not most of those) would want to.
Ironically, painfully, the closest thing in current web technology to simple modeling of simple presentation structure is technically the most flawed: frames. I would recommend their use for almost no public purpose, and frameset code is no pleasure to look at, either, but at least frame definition is separated from content (too separated, in fact, but separation is still a good idea), and its grammar operates by explicitly specifying structure from the outside in (with recursion, albeit awkwardly), rather than calculating it by implication from the inside out. If frames had been defined as page (and sub-page) elements pre-declaring layout structure, rather than window elements that contain content pages by reference, we might have had something.
While we're redoing the layout model, though, we also need to fix our basic misunderstanding of the natural structure of repeatable content presentation. Any remotely enlightened programmer "knows" that content should be separated from presentation, but these are actually three things, not two: content, presentation structure, and actual formatting, and in practice the formatting can usually be further separated into content formatting (the formatting of the information unique to this content node) and page layout (the site-identity and navigation and other framing stuff displayed around it but conceptually invoked from context).
Take this furialog entry itself, for example. Its content structure includes a title, a display date, a publication timestamp, a set of tags and a content block. This content structure is then mapped into a presentation structure for this web page which is quite a bit simpler: just a header and a body. The title, display date and tags are concatenated into a single formatted block for presentation purposes, and the timestamp is not (in this format) presented at all. The formatting rules, then, are applied to the presentation structure, not the content structure. This is important, because elsewhere on this site content with very different content structures gets mapped into the same presentation structure, subject to the same formatting rules, and thus it is possible for me to define a single rule-set that drives the middle layers of the production of all my content, a single page-layout that drives the outer layers, and appropriate extensions to which the sub-formatting of special-purpose inner blocks like tables and photosets can be delegated.
The usefulness of RSS, similarly, is largely due to the fact that it defines a common presentation structure into which dissimilar content structures may be mapped. Different feed sources may put semantically different and/or compound information into the title and description fields, but the writing software doesn't have to know or care about the formatting rules, and the reading software doesn't have to know or care about the content structure. The drawback of using presentation structure as an interchange medium, of course, is that the reading software can't get the original content structure even if it could do something interesting with it. Human readers can re-interpolate it, but for the machines RSS tends to be lossy.
This was also, maybe obviously, the original design concept for HTML: standardize a presentation structure that can then act as universal intermediary between content and screen. RSS gets away with its limitations because it's an alternate channel, but as the web emerged, HTML was the web, and universal intermediation quickly proved unsatisfying in both directions: writers couldn't exercise enough control over formatting when they needed or wanted to (and programmers often assume "want" is always the right word here, but publishers understand that publishing is different than just writing), and machines couldn't add enough processing insight without finer-grained and/or domain-specific data schema.
Here, then, are some of the elements of the new model I want, some of what, from twenty years of working with information in both publishing and software spheres (and this isn't what I thought after ten, so maybe it won't be what I think after forty, but is that because I change, or because the world does?), I believe the whole system needs in order to fulfill its potential as a medium at once for direct human communication and human understanding supplemented by computer reasoning:
- Not only should all meaningful content begin in its own schema, but this machine-parsable content structure should, inherently and automatically, underlie and accompany the human-visible presentation and formatting of all information. Imagine, if this were our only problem, adding an Elemental XML section to every HTML page, so that each page would carry its pre-presentation data in addition to all of its other markup, and splitting the View Source command into View Presentation Code and View Source Data to offer different tools for each. (Microformats are a similarly motivated effort, establishing presentation-structure conventions for particular kinds of content structure, but conflating the two kinds of structure is only reasonable as a short-term tactical compromise in a system where there's no good way to separate them, anyway.)
- The mapping of content structure into presentation structure must be so trivially easy, and such an obvious entry into a richly distributed universe of sophisticated standard lexicons and templates, that nobody will even be tempted to try to skip the step by pretending that their content doesn't have any other structure than its presentation. Imagine, as you're publishing something, that you could chose dynamically from not only your own repertoire of formats and the templates provided by your authoring software, but from a social universe of templates, of all granularities, available from anyone who has one to offer. The laborious specific control of your own formatting, or the flexible custom extension of your presentation structure, should be optional opportunities for the motivated, not required burdens of participation.
- The layout model should be based on recursive containment from the outside in (probably with layers, for graphic depth). Exceptional behavior, like violating margins, must be declared explicitly, not arise from routine errors in normal use. It should be trivial to map one element of presentation structure into one formatting container, to flow multiple elements of presentation structure into one formatting container, or to flow one or more elements of presentation structure through an arbitrarily linked series of formatting containers. We've learned a lot about UI and usability since Quark and PageMaker were invented, and not everything we ever wanted to do in books and magazines applies the same way on a screen or in an interactive environment, but in many ways the screen world is only now approaching the point where print was before computers, so as is already beginning to sink in about typography, more old lessons apply than not.
- Where the new medium has new abilities, our tools should be granting new powers to us, not demanding new chores. AJAX is a clever retrofit of what should have been a native idiom. Forget paging vs scrolling, Google Maps is how everything offscreen should work, the computers dealing with computer constraints like bandwidth and memory without bringing people into issues that don't concern people. And if content were encapsulated intelligently, it wouldn't take Flash or iframes or scripts to make a piece of a page do things a whole page can already do. The web is a bad application environment kludged onto a bad publishing environment, and it ought to be a composite environment in which publishers realize that sometimes they are publishing applications and experiences and devices, not just pictures and words.
- The separation of content, presentation structure and formatting is necessary for everyone's purposes, not just the auteurs and the programmers and the machines. Good, reusable, maintainable presentation design, even when it's done by dedicated designers, should always work first from presentation structure to formatting rules. The handcrafting of individual exceptions should be an elaboration on a framework of rules, not a repetitive substitute for making the effort to understand patterns. I see way too much CSS code that specifies individual pixel-unit fonts and margins and paddings for every single id-numbered div in an entire page (or, worse, for every id-numbered div in a whole set of pages, so that the style-sheet can be "reused" across all of them). Sometimes this is a result of having misused the (X)HTML to model the content structure, rather than the presentation structure, so that the formats and the selectors don't line up right, but I bet it's more often just laziness. It's always faster to add a pixel than to generalize a rule about why, but it takes an incredibly tiny number of exceptions to complicate a rule-set so irretrievably that it can only be modified by further exceptions. For all but the rarest purposes where chaos is the order, the fewer rules the better, and the square of the fewer exceptions the better.
But fine. No matter what you credit as partial precedence, ubiquitous electronic publishing and communication as social infrastructure are at best in their adolescence, and it's amazing we've gotten this far with these primitive tools. The willingnesses to restart and rebuild are in our character, just as surely as myopia and impatience are our curses. Generations are how we learn.
So yes, this means starting over, but the new ways, when they're right, are easier than the old ones, and we only shrink from them out of fear of change. In place of the current HTML/CSS information foundation we will have data (content structure), mapping (content structure to presentation structure), page layout (the containers through which the presentation structures flow) and formatting (typography, color, spacing, ornamentation and illustration within those containers). Any of these can be implied from defaults (set by the reader, writer or both), included by reference to external sources, included by recursion, included conditionally by context, or defined inline. Most of this will still be mediated by tools for most people, but the tools will be simpler and more powerful, and will let us focus more on what we're saying to each other, and less on how.
And since the new way delivers both the formatting and the semantics, this will be a practical revolution that actually subsumes a theoretical one, better human communication interleaved with better machine communication, and thus the foundation for both better shopping and the dream of the internet being something qualitatively more profound and transformative than shopping.
The reason the HTML-tables-vs-CSS-blocks war wasn't over ten minutes after CSS was invented, for example, is that the CSS float/span/margin/escape model chose (more in ignorance than defiance, I'm sure) its own internal geometrical cleverness over the potential applicability of centuries of conventional information design. The most basic tool of scalable information design is and has always been the layout grid. CSS is capable of producing a simple layout grid, but not simply. Arguably it's even harder to recognize a page layout by reading its CSS than it is to write the CSS. Structural elements are structural by convention if you're lucky, coincidence if you aren't, and certainly not by nature, and are unavoidably cluttered by non-structural formatting elements.
An HTML table isn't a good tool for page layout, either, but for the most part a simple layout grid can be expressed by a simple HTML table, and with decent code-indentation it is possible to more or less grasp the presentation structure of a simple table by looking at its code. The fact that tables require the content and the structure to be intertwined is a huge problem, and the fundamental misconception of the scheme emerges the moment any kind of table-nesting is required for page-structural and/or content-structural reasons. The non-programmer's mental model of a box is an actual box. You can put small actual boxes inside larger ones. If you forget to put a bottom on a small box inside a large box, you get a bottomless small box inside a normal large box, not a deformed small box falling out of the bottom of a mangled large box. Nobody, not even a programmer, intuitively thinks of object construction procedurally, and nobody but a programmer (and not most of those) would want to.
Ironically, painfully, the closest thing in current web technology to simple modeling of simple presentation structure is technically the most flawed: frames. I would recommend their use for almost no public purpose, and frameset code is no pleasure to look at, either, but at least frame definition is separated from content (too separated, in fact, but separation is still a good idea), and its grammar operates by explicitly specifying structure from the outside in (with recursion, albeit awkwardly), rather than calculating it by implication from the inside out. If frames had been defined as page (and sub-page) elements pre-declaring layout structure, rather than window elements that contain content pages by reference, we might have had something.
While we're redoing the layout model, though, we also need to fix our basic misunderstanding of the natural structure of repeatable content presentation. Any remotely enlightened programmer "knows" that content should be separated from presentation, but these are actually three things, not two: content, presentation structure, and actual formatting, and in practice the formatting can usually be further separated into content formatting (the formatting of the information unique to this content node) and page layout (the site-identity and navigation and other framing stuff displayed around it but conceptually invoked from context).
Take this furialog entry itself, for example. Its content structure includes a title, a display date, a publication timestamp, a set of tags and a content block. This content structure is then mapped into a presentation structure for this web page which is quite a bit simpler: just a header and a body. The title, display date and tags are concatenated into a single formatted block for presentation purposes, and the timestamp is not (in this format) presented at all. The formatting rules, then, are applied to the presentation structure, not the content structure. This is important, because elsewhere on this site content with very different content structures gets mapped into the same presentation structure, subject to the same formatting rules, and thus it is possible for me to define a single rule-set that drives the middle layers of the production of all my content, a single page-layout that drives the outer layers, and appropriate extensions to which the sub-formatting of special-purpose inner blocks like tables and photosets can be delegated.
The usefulness of RSS, similarly, is largely due to the fact that it defines a common presentation structure into which dissimilar content structures may be mapped. Different feed sources may put semantically different and/or compound information into the title and description fields, but the writing software doesn't have to know or care about the formatting rules, and the reading software doesn't have to know or care about the content structure. The drawback of using presentation structure as an interchange medium, of course, is that the reading software can't get the original content structure even if it could do something interesting with it. Human readers can re-interpolate it, but for the machines RSS tends to be lossy.
This was also, maybe obviously, the original design concept for HTML: standardize a presentation structure that can then act as universal intermediary between content and screen. RSS gets away with its limitations because it's an alternate channel, but as the web emerged, HTML was the web, and universal intermediation quickly proved unsatisfying in both directions: writers couldn't exercise enough control over formatting when they needed or wanted to (and programmers often assume "want" is always the right word here, but publishers understand that publishing is different than just writing), and machines couldn't add enough processing insight without finer-grained and/or domain-specific data schema.
Here, then, are some of the elements of the new model I want, some of what, from twenty years of working with information in both publishing and software spheres (and this isn't what I thought after ten, so maybe it won't be what I think after forty, but is that because I change, or because the world does?), I believe the whole system needs in order to fulfill its potential as a medium at once for direct human communication and human understanding supplemented by computer reasoning:
- Not only should all meaningful content begin in its own schema, but this machine-parsable content structure should, inherently and automatically, underlie and accompany the human-visible presentation and formatting of all information. Imagine, if this were our only problem, adding an Elemental XML section to every HTML page, so that each page would carry its pre-presentation data in addition to all of its other markup, and splitting the View Source command into View Presentation Code and View Source Data to offer different tools for each. (Microformats are a similarly motivated effort, establishing presentation-structure conventions for particular kinds of content structure, but conflating the two kinds of structure is only reasonable as a short-term tactical compromise in a system where there's no good way to separate them, anyway.)
- The mapping of content structure into presentation structure must be so trivially easy, and such an obvious entry into a richly distributed universe of sophisticated standard lexicons and templates, that nobody will even be tempted to try to skip the step by pretending that their content doesn't have any other structure than its presentation. Imagine, as you're publishing something, that you could chose dynamically from not only your own repertoire of formats and the templates provided by your authoring software, but from a social universe of templates, of all granularities, available from anyone who has one to offer. The laborious specific control of your own formatting, or the flexible custom extension of your presentation structure, should be optional opportunities for the motivated, not required burdens of participation.
- The layout model should be based on recursive containment from the outside in (probably with layers, for graphic depth). Exceptional behavior, like violating margins, must be declared explicitly, not arise from routine errors in normal use. It should be trivial to map one element of presentation structure into one formatting container, to flow multiple elements of presentation structure into one formatting container, or to flow one or more elements of presentation structure through an arbitrarily linked series of formatting containers. We've learned a lot about UI and usability since Quark and PageMaker were invented, and not everything we ever wanted to do in books and magazines applies the same way on a screen or in an interactive environment, but in many ways the screen world is only now approaching the point where print was before computers, so as is already beginning to sink in about typography, more old lessons apply than not.
- Where the new medium has new abilities, our tools should be granting new powers to us, not demanding new chores. AJAX is a clever retrofit of what should have been a native idiom. Forget paging vs scrolling, Google Maps is how everything offscreen should work, the computers dealing with computer constraints like bandwidth and memory without bringing people into issues that don't concern people. And if content were encapsulated intelligently, it wouldn't take Flash or iframes or scripts to make a piece of a page do things a whole page can already do. The web is a bad application environment kludged onto a bad publishing environment, and it ought to be a composite environment in which publishers realize that sometimes they are publishing applications and experiences and devices, not just pictures and words.
- The separation of content, presentation structure and formatting is necessary for everyone's purposes, not just the auteurs and the programmers and the machines. Good, reusable, maintainable presentation design, even when it's done by dedicated designers, should always work first from presentation structure to formatting rules. The handcrafting of individual exceptions should be an elaboration on a framework of rules, not a repetitive substitute for making the effort to understand patterns. I see way too much CSS code that specifies individual pixel-unit fonts and margins and paddings for every single id-numbered div in an entire page (or, worse, for every id-numbered div in a whole set of pages, so that the style-sheet can be "reused" across all of them). Sometimes this is a result of having misused the (X)HTML to model the content structure, rather than the presentation structure, so that the formats and the selectors don't line up right, but I bet it's more often just laziness. It's always faster to add a pixel than to generalize a rule about why, but it takes an incredibly tiny number of exceptions to complicate a rule-set so irretrievably that it can only be modified by further exceptions. For all but the rarest purposes where chaos is the order, the fewer rules the better, and the square of the fewer exceptions the better.
But fine. No matter what you credit as partial precedence, ubiquitous electronic publishing and communication as social infrastructure are at best in their adolescence, and it's amazing we've gotten this far with these primitive tools. The willingnesses to restart and rebuild are in our character, just as surely as myopia and impatience are our curses. Generations are how we learn.
So yes, this means starting over, but the new ways, when they're right, are easier than the old ones, and we only shrink from them out of fear of change. In place of the current HTML/CSS information foundation we will have data (content structure), mapping (content structure to presentation structure), page layout (the containers through which the presentation structures flow) and formatting (typography, color, spacing, ornamentation and illustration within those containers). Any of these can be implied from defaults (set by the reader, writer or both), included by reference to external sources, included by recursion, included conditionally by context, or defined inline. Most of this will still be mediated by tools for most people, but the tools will be simpler and more powerful, and will let us focus more on what we're saying to each other, and less on how.
And since the new way delivers both the formatting and the semantics, this will be a practical revolution that actually subsumes a theoretical one, better human communication interleaved with better machine communication, and thus the foundation for both better shopping and the dream of the internet being something qualitatively more profound and transformative than shopping.