Coding for Content

In: Columns > View Source

By Garrett Dimon

Published on April 23, 2007

Strongly inspired by the work of Edward Tufte, I recently reworked the design of my personal site to focus on content and ideas rather than on decoration or visual effects. I’ve already discussed my approach to the visual design of the site, but now I’d like to share what’s going on behind the scenes.

It all started with one simple goal—an almost obsessive focus on content. That quickly translated to design ideas, but the visual framework was merely the tip of the iceberg. If I was truly going to focus on content, I had to be honest with myself—I needed to improve my content development process. This included several aspects: the writing itself, the complexity of the publishing process, and the lack, in my former design, of a good system for providing examples to illustrate my ideas. The last one was the most challenging part of improving my process. It involved creating a framework that would enable me to consistently and efficiently embed images and related content.

In fact, most of the time spent on this redesign was spent creating the personal markup patterns that I would use from article to article. This would enable me to spend more time thinking about the images and content, and less time fiddling with how to work them into the code. I wanted clean semantic markup, but I also wanted a logical framework that was simple enough to understand, yet flexible enough that I wasn’t overly boxed-in.

Designing the Framework

The first step was establishing the grid and dimensions for the page. The primary motivation behind the redesign was to easily associate specific images with related content in the text. Since I knew that I’d be relying heavily on images and the image sizes would be fixed, I decided to go with a fixed width of 760 pixels, or 760px. Given that the full width is dedicated to the main content and there isn’t a sidebar, I felt pretty comfortable with the decision. Comfortable as I was, I wasn’t thrilled with this decision because it fixes the width of the page and doesn’t scale with the text. However, I knew that I could, and still can, go back and make changes later. I chose to make the two columns 66% and 33% respectively to maintain a nice even 2:1 ratio.

The first column is 506 pixels, or about 66%, and the gutter, or second column, is 254px, or about 33%. The widths specified for the content column are a little less than 66% in order to allow for a margin between the two without using padding unnecessarily. The second column doesn’t function as a sidebar. At times, it would be white space, other times it would contain single images narrow enough to fit within the column, and other times it would allow wider images to extend beyond the confines of the main content column. At this point, I knew I had numerous choices for image sizes. I wanted to quickly sketch up my options so that I could understand just how many I had if I subdivided the columns and created a more complex grid. I took a few moments and put together the following options in Photoshop without worrying too much about precision at this point.

Clearly, I didn’t need ten different options for images, and if I did, I could always add them later. I ultimately narrowed it down to three sizes—small, medium, and large. That was all I really needed, and while the additional options would have added significant flexibility, they also would have led to an inordinate amount of overhead and additional code. It just wasn’t worth it. The three I chose easily worked within the grid I had already established, as shown below, and, as we’ll see shortly, this made the integration of the images rather straightforward.

At this point, my image sizes were constrained to three simple, reasonable choices, but I saw an opportunity to gain some added flexibility and variety. For the two smaller images, I wanted to be able to easily choose whether the images were on the left or right. That way, I could add some variety to the appearance of the content without adversely affecting the grid or introducing any unnecessary complexity. So, with some simple formatting and adjustments, I have more than enough options for image placement to handle whatever I can throw at it.

Choosing the Markup

So, I’d worked out what I was doing, but I still needed to figure out how I was going to do it. I knew I had several things to consider in my approach to markup for the images, or “figures” as we’ll refer to them from here on out. We’ll go through—step by step—to create what I’ve begun to call a personal markup pattern.

You can think of a personal markup pattern as a sort of microformat that solves a problem unique to your situation. Ideally, a personal markup pattern could easily evolve into an official microformat, but that’s a rather involved process, and one of the primary requirements for patterns to become official microformats is that they solve existing real world problems. By really thinking through the patterns we use, using them repeatedly, and honing them over time, we are constantly testing and validating our ideas. This enables future discussion and consideration to be based off of a real need and the creation of a pragmatic solution. So, I put what may seem to be an inordinate amount of thought into the markup I use—it all has the potential of serving a broader purpose. In this case, I anticipate my efforts will only contribute to the discussion rather than serve as the foundation of any actual microformats.

We’ll follow my thought process as I went about designing my markup pattern. Since it’s the most important piece of content in this pattern, I started with a simple image.

<img src="/images/Image.jpg" alt="The alternate text for my image." />

I knew I’d need captions, but I also knew that I didn’t want them to be required for every image. So, it was important for the captions to be optional elements that could easily be removed without affecting the rest of the content.

<img src="/images/Image.jpg" alt="The alternate text for my image." /> <small>This is a very interesting image that's related to my content in some fascinating way.</small>

Now, for the more observant out there, you might be questioning my use of the small tag, and that’s perfectly reasonable. However, in this context, small made sense as a sort of footnote to the image. So, while small as a word may imply presentation, I’m comfortable using it to mark up a small block of related but supplementary text.

Moving on, the image and text would have to be structurally and visually related, so they needed a container to tie them together. Since I planned on using images as inline content, rather than sections of their own, I chose to use a span. Of course, depending on context and personal preference, we could just as easily use something other than a span, such as a div or p.

<span class="figure"> <img src="/images/Image.jpg" alt="The alternate text for my image." /> <small>This is a very interesting image that's related to my content in some fascinating way.</small> </span>

You’ll notice I also added a figure class. This is how I group the CSS properties that are shared among the different size figures such as border or other stylistic aspects. In addition to this class, I needed a way to denote which size image I was using. While I wouldn’t normally want to use presentational classes, this was a unique situation. I chose to use small, medium, and large for the classes, but, in order to slim down, I used s, m, and l.

<span class="figure m"> ... </span>

Now, I’m sure at least a couple of you realize that I’m potentially fudging a little by using classes that imply presentational meaning, but I’d like to assert that I’m actually not. The image sizes are fixed. They will not change. Thus, relative to each other, small, medium, and large, are appropriate words for describing the images because they are actually describing fixed attributes of the content.

I explored several options, including Chris Messina’s proposal and Dan Cederholm’s implementation, but I ended up making my decisions based on what made sense in the limited context of my site. If worse comes to worse, I can always go back and update my approach.

Next, virtually all figures would be related to some specific point in the body of content, so I needed some text that clearly communicated the relationship. I started by determining the small piece of text that would go inline with the body content, and decided on a simple span with a class of reference.

<span class="reference">(Figure 1)</span>

Naturally, I needed a similar reference point with the caption and figure. Given its location inside of the figure span and the small element in the context of the markup pattern, I left the reference class off the figure markup.

<span class="figure m"> <img src="/images/Image.jpg" alt="The alternate text for my image." /> <small><span>Figure 1</span> This is a very interesting image that's related to my content in some fascinating way.</small> </span>

I also knew that some situations would benefit from having a clickable image, so I knew that I could easily add an anchor tag around the image without affecting the other elements. Here is an example of the code with the optional anchor tag included.

<span class="figure m"> <a href="http://garrettdimon.com"><img src="/images/Image.jpg" alt="The alternate text for my image." /></a> <small><span>Figure 1</span> This is a very interesting image that's related to my content in some fascinating way.</small> </span>

For the finishing touch, I needed a way to indicate when the medium and small images should be floated the opposite direction from their default location. I added an optional class of alt to indicate alternate positioning, and I was finished. It’s important to note that seemingly obvious choices such as right and left are inappropriate because they convey presentational choices. Using alt just implies that this is an alternate layout and enables maximum flexibility in the future, should I decide to flip the horizontal orientation of my site.

<span class="figure m alt"> ... </span>

Using CSS, I did some calculations to determine the actual image sizes and account for border widths, to arrive at the following basic style for my images.

While everything seemed perfect, one small issue popped up as I began writing my first posts. I was going to have situations where the image didn’t need, or shouldn’t have, a border. So, I had one more scenario to cover. I gave myself one more option with a clean class that would remove the borders and associated styling.

So far, the use of this class has been limited to images that I’ve used in the gutter. As the example below illustrates, their widths vary, and they don’t always require additional text. So with a little variation, I have a format that’s consistent, flexible, and enables me to quickly add figures and additional context to my writing.

Some Final Thoughts

I’m very happy with the end results, but there are a couple of things that leave a little to be desired. I’m comfortable with my use of the small tag, but, semantic arguments aside, it doesn’t look so hot in a feed reader. While I personally don’t feel that a feed reader should be used as anything more than a notification technology, I understand that there is an audience that desires to read full posts in a feed reader. I don’t believe they can be accommodated entirely, but it does bother me a little that small renders as an inline element and doesn’t create a new line of text below the images.

Another aspect that leaves me a little uneasy, with that 20/20 hindsight, is my use of small, medium, and large. It’s perfect for me now, but should I want to add some more options for figures in the future, it might be challenging. I could use xs, s, m, l, and xl, but that would most likely involve updating the existing s and l classes since l is already as big as I can fit on the site. That said, if the width expands and I introduce more columns in the future, the addition of 2 sizes at the fringes may play out perfectly well.

With the exception of those two challenges, I’m happy with the framework, and it’s well worth the additional upfront time that I invested. It makes it virtually painless to include images and discuss visual ideas in a more concise, and dare I say, engaging, way. I’d love to see more discussion and, ultimately, the creation of a microformat for accomplishing this.

Related Topics: Content, CSS, HTML, Information Design, Programming