A brief exchange on Twitter with Jen Simmons (@jensimmons) and Morten Heide (@mortendk) about how to best incorporate a site logo into a Drupal theme got me cogitating on this question. Jen tweeted:

...What should go is the habit of hardcoding content into the theme. #separationplease #drupalwtf

—@jensimmons

"Content"? Hmmm. This got me pondering: Is a logo "content" per se? My immediate response was in the negative. But upon further consideration, I don't think it's all that clear cut; I'm definitely less certain today than I was yesterday.

This post is a bit of thinking out loud on this question. Comments welcome! (But no need to shout #wtf, okay?)

Content or architecture

To me, "content" in a Drupal site is the content, as in nodes, comments, image uploads, embeds, etc. The content is the information. Come back to an article on kitten care a year from now and the content will be the same (or at least it should be).

The logo, on the other hand, is a graphic component of the user interface as well as the branding. The logo is the visual representation of the site identity. It may change and evolve, as logos do, as user interfaces do.

But functionally the logo in the web application is really a part of the site's architecture. The logo is "home." Redesign the site, revamp the logo, change its colors, replace it altogether — it is still "home" in terms of the functionality of the application. In that sense, it is fundamental architecture.

When planning, designing and developing a custom website, the theme is custom, a part of the entire design that includes architecture. (At least, this is the assumption I'm working from.) One typically does not move a logo around on a page willy nilly. One typically does not swap out the logo for another — not unless you're also changing the theme as well, as part of an entire redesign. The logo is a part of the whole user interface, the whole user experience, the whole compositional balance of the page. Conceptually it's hard for me to split out the logo as represented on the page itself as somehow apart. Logos have their own separate life, yes, but in a user interface context matters. One might even argue that the entire user interface is all a part of the branding, with the logo just playing one part. One might....

One of the advantages of a Drupal site is that a site administrator can actually manipulate the site architecture without touching code. This helps site building happen much quicker than it would otherwise. This admin control over architecture also can be handy for site owners, even if used only once or twice in a year. And it constitutes configuration stored in the database.

But does that make architecture "content"?

Drupal is very good at blurring the lines between functionality and presentation because of this paradigm. In puritanical (small "p") terms, it's undesirable, this blurring the lines. But in terms of usability and convenience for site owners, it ends up being empowering. Site menus can be modified, added to, deleted from. Blocks can be repositioned. The user interface, in other words, ends up being extremely malleable and subject to the whims of any user with the appropriate administrative permissions.

But is it content? I guess it depends upon what you mean by content. In terms of interaction design, I tend to view the site logo as a component of the entire user interface design, as part of the architecture in terms of functionality.

In Drupal, by default the logo can be uploaded from within the Drupal admin interface, and in that regard it's something like the other architectural elements that are exposed in the Drupal back-end. But the logo's purpose is locked in Drupal core. It links to the website "home page." The administrative control of the logo is restricted to determining what graphic will be presented as the logo. In other words, the logo ends up being merely the visible face of core Drupal functionality, the site architecture.

However, in terms of design, the logo is ideally integrated in the entire page design, and ideally is not simply a drop-in graphic, swappable at a whim. What's more, how that logo appears — i.e., what that logo's graphic image might be — depends upon the site design, which in turn is greatly affected by the device for which the theme implementation is intended. For example, if handheld compatibility is being addressed, the logo on a site viewed in a desktop browser will almost certainly be different from the logo used for users viewing on a handheld device. This makes Drupal core's logo upload functionality too limited and requiring either alteration or bypassing, because when the logo is uploaded into Drupal, you just get the one logo per theme. To swap out the logo for different platforms and devices, you'll need to do some fancy theme coding to load a different image (not easy for most), use simple CSS to force-resize the image (not considered best practice), or load a completely different theme (which is often not desired).

One way to avoid this is to skip Drupal's logo upload paradigm and load the logo's graphic as a background image. This way the logo can be easily swapped through use of @media queries in CSS for different sizes and aspect ratios, to complement responsive theming for tablets and handhelds. Incorporating site logos into web design via background images using CSS is a common practice for many web designers and developers. It certainly makes it easy to do things like :hover states and other user-feedback goodness.

But maybe that's not the best approach. For one thing, it clearly treats the logo graphic as not content. What if it is?

In terms semantic

There's some interesting debate on this.

Keith on Shubox ponders the question, considers the possibility that the site logo can be considered content. He argues that for SEO reasons a logo loaded as an image can have an alt value. This doesn't convince me because the link tag that can be displayed with a background image (the logo itself) can have alt values, too.

Stack Overflow bats around the question with some very nice discussion.

One assertion that comes up is that the logo is content semantically. Again here I'm not entirely convinced — not when it comes to interaction design (for the reasons I describe above). However, I do see the site name, which may or may not even be printed on the visible page, as semantically critical. But the logo? Not necessarily. In many ways, the semantic web is not much interested in graphic logos, but rather the identities the logos represent. —Especially if you consider that logo on the same site at the same URL may be different depending upon the device you're viewing it with.

Still, the Stack Overflow discussion and other Google hits leave me questioning my assumptions. (Oh, and Google itself loads its logo in an <img> tag as content.) I'm open to convincing on this score. However...

In terms practical

In another tweet in our brief exchange, Jen noted that if the logo is loaded on a website as a background image, "nothing will print."

#facepalm

It's a good point: A logo set as a background image will not print if the browser is not set to print background images, and there's no guarantee that it will. And whether you offer printer-friendly alternative pages or try to remedy the matter in print.css, it's a challenge that wild and wooly browser-world does not make easy to solve.

In other words, the background-image approach for logo placement may well serve easy adaptability to a wide variety of devices, platforms and resolutions, it risks a #fail when it comes to presenting the logo on dead trees.

(And if the logo is missing, it will be missed, which again raises the notion that logos may indeed be content after all.)

So in terms of Drupal theming, maybe the logo refrain is: don't worry, print $logo, be happy.