The Incomplete Divorce

Published 21 years, 2 months past

Doug Bowman’s observations on the separation of presentation and content are well made, and illuminate an oft-overlooked corner of the whole standards debate.  Even with some semantic correction, we still have room for discussion.

My semantic correction is that we aren’t trying to separate presentation and content, but presentation and structure.  Doug makes this point throughout the latter part of his post, but I think this is the important thing to state right up front.  Without content, it’s very difficult to have any presentation, except maybe a blank browser window (very minimalist, but not necessarily useful).

Even there, however, the divorce is not complete and never can be.  I’ve been saying this in public presentations for a while now, and it bears repetition here: you can have structure without style, but you can’t have style without structure.  As Doug observes, you have to have elements (and, also, classes and IDs and such) in order to apply style.  This is absolutely the case, and it should come as little surprise, really.  If I have a document on the Web containing literally nothing but text, as in no HTML or other markup, just text, then it can’t be styled.  Presented, yes, using the browser’s defaults for showing raw text.  But not styled.

This is also why I’ve argued that the document structure is dependent on your presentational needs.  Document structure is like the support beams for a building.  The final layout and appearance of the building will depend very heavily on the shape those support beams create.  If you ignore that, and assemble the beams with no thought toward the final product (not following the blueprints, as it were), the best you can hope for is an inefficient, almost unusable building.  In the worst case, the building will utterly collapse as soon as you try to add anything useful to the structure.

This has been a minor issue in HTML, but XML throws the issue into sharp relief.  Consider the following fragment of XML: 

<city name="Cleveland" state="Ohio">23</city>

Okay… any idea what that number represents?  No, probably not.  What’s worse is that if I hand that element to a user agent, it will display the element’s content: 23.  The user won’t even have the attribute values to give them what little hints you got by looking at the source.  They just see the number 23.

That’s because attribute values don’t get displayed, while element content does.  Yes, we can use CSS generated content to make the attribute values show up, but how crazy is it that the following would be needed to make the display more useful? 

city:before {content: attr(name) " " attr(state) ": ";}

And then, if you wanted to make the bits of data lay out like a table—you can’t.  Oh, sure, you could get the generated content into one layout piece, and the element content into another, but you can’t get the city name and the state name into separate cells.  Even if you could apply display: table-cell to the generated content, you can’t split it into different cells.

We can argue that this illustrates limitations in CSS, and to a degree that’s true, but to do so misses the point entirely.  There will always be some limitation we can’t overcome, something the styling language of the moment can’t make possible.  What I’m talking about is the fact that presentation is inextricably bound to structure, and document authors ignore that connection at their peril.  Let’s return to that XML fragment and restructure it to be more intelligent: 

<city region="midwest">
  <name>Cleveland</name>
  <state>Ohio</state>
  <hightemp scale="c">23</hightemp>
</city>

Now, not only do we have more actual content to be displayed by default, but we have more elements to actually style.  So we might turn the above into a table-like structure, complete with some useful cues for the user, like so: 

city {display: table-row;}
city > * {display: table-cell; width: 33%;}
hightemp[scale="c"]:after {content: " degrees Celsius";}
hightemp[scale="f"]:after {content: " degrees Fahrenheit";}

Now, thanks to our structure, we can make the display much more useful for the user, and understand it better ourselves.  We can even style the city and state differently now, whereas before that was impossible.  We’ve also been able to use an attribute value to affect presentation.  I included the attributes to show that attributes aren’t at all useless, or even have to stay completely out of the presentation.  They can be quite handy.  However, the region attribute is a good example of data that has to be carefully considered.  If we ever want to display a city’s region next to its name, then it’s probably a good idea to use an element (like <region>...</region>) instead of an attribute.  If we just want that information in the data structure for purposes of transformation, or to style descendant content without actually displaying the region’s name, then an attribute makes far more sense.  For example: 

city[region="midwest"] {background: green; color: white;}
city[region="northeast"] {background: purple; color: white;}

If we’re going to do that kind of thing, treat the region almost like it’s a class, then we definitely want it as an attribute.  If it were an element, with the region name as content, we’d have no way to style it (or anything else) based on its content.

What it comes down to is that structure is critical to presentation, with or without the style—although intelligent structure makes styling lots easier.  Contrary to what some may have claimed or implied, you can’t just create an arbitrary structure with no consideration toward its presentation.  If you want something on the screen, it needs to be element content.  That may not be ideal, but it is inescapable.  Structure may be able to break up with style, but style still needs and depends on structure in a big, big way.  Personally, I’m not sure it can ever be otherwise.

Comments are closed.