Sustainable Markup: How to be a themer in Drupal.

I’ve been thinking a lot lately about how we could be doing things better and not just in the Drupal way. But Drupal is what I’ve decided to focus on first. I’ve been wracking my brain over how we can improve our process, how we can build more efficient sites faster and better for the client, and how we can give ourselves a tool kit.  And then it hit me, we’ve been approaching designs in Drupal all wrong this last year. Don’t get me wrong, we didn’t do anything "wrong", we just didn’t make it easier on ourselves.

We’ve been a Drupal shop for over a year now and we are definitely still maturing our Drupal approach. We are still cutting our teeth, so to speak. And I think that we may be reinventing the wheel all too often.

Of course, the hilarious piece of this whole epiphany of mine is that it is completely obvious. Every day I/we use the term “theme” or “theming” and we even call ourselves themers, yet we don’t theme, we skin. We even talk about themes that other people built in Drupal, and I look at Zen and Garland all day long – and still it didn’t hit me.

A “theme” as defined in Merriam Webster’s Dictionary is “a subject or topic of discourse or of artistic representation”. And subjects and topics shouldn’t break down, and if they do, it will break off into a whole new topic or representation and generally isn’t shoe horned into the original representation.

In Drupal, “to theme” means to abstract or override the look and feel. But really in Drupal, to theme means to create a tool kit, to create a design that is an overlay to your core functionality, and is sustainable. Yep, it’s everybody’s favorite word – “sustainable”. The theme needs to be something that lives and grows with ever evolving functionality.

So let’s get back to our current method of “skinning” instead of theming.  I’m finding that we are more reactionary in our CSS/theming approach on a site than tactical, and I suspect lots of other people are too. We're missing a solid formula for our themes. This is what Zen does, it’s what Garland does, and it’s what any good themer who contributes a theme back to Drupal does.

The first reason why I think developers tend to lean away from creating a real theme or tool kit is not always an intentional one, but is because most of us come from a background of building our own markup and CSS, never having it dictated to us.

The hardest challenge for me in Drupal was to stop trying to rewrite it, and no, I don’t mean hacking core. When I started my first theme or “skin job” ;), the first thing I wanted to do was rename every class and id to my own preferred name. It was so bad that I renamed our version of Zen’s “page” container to “pagewrapper”. That should have been my first warning sign. Thankfully, over time, I began to trust Drupal and learn to skin (notice I didn’t say theme) Drupal, use the theme templates as is, and not fiddle with the markup, classes, or structure, but to instead write my CSS based on what Drupal gave me. In return it made me a much more skilled web developer. When you have to work with what the CMS (Drupal) is giving you, you rely on your wit and start to learn some pretty nice CSS tricks. In case anyone’s wondering how you would ever do such a thing…it's called Firebug, and it is awesome. No web developer or themer should be working without Firebug or the Web Developer toolbar.

For those who don’t know, at Palantir we often collaborate with design firms to build a site, which is why it is even more important that we wrap our head around this idea of a theme. An extensible design, a design tool kit that continues to evolve, without the help of a HTML/CSS developer is the ultimate goal; a design or theme that stays intact as you add new content and new layouts to your site.

Two specific examples of this in Drupal are Views and Menus. Often, we style view blocks, menu blocks, and view pages once we display them, and man, does it always need it. My question is…can’t we figure out an approach that always lets you drop a menu in a region and have it look acceptable? Or add a new table view to the site and have it follow the design thread?

When you look at Zen’s stylesheets you’ll notice that the CSS has been built for 1 column, 2 column, 3 column, and blocks in any of those regions. You can’t just design for what appears, you have to design for all outcomes, and especially one that involves a view block in an area where you never thought it would go.

Do I have a solution? Well, maybe not a solution but perhaps an approach to get us there quicker. After working with the latest version of Zen for D6 (a fairly well-developed toolkit), it has become incredibly apparent to me that we need to plan better for the site and all the legs, arms, and other appendages that could occur. Granted, we're often working within a limited design, but I wonder why we don't style along with our semantic markup. We're pretty good about laying out semantic sites, but are we styling them semantically? Or are we seeing a title that should be purple on this page and blue on another? In other words, H1s should serve a specific function and they should always be distinct. And H2s, well, they should also be somewhat prominent and not 10px in font size – because is that going to hold up in your design, and be extensible? Drupal structures items with H2s all the time…for good reason - we can’t abandon that reasoning, we need to embrace it and theme/design for it.

I think that the reason for this missed opportunity is that too often as web developers we are focused on designing a site and not a framework. If we were designing a theme to contribute back for any site, we might be forced to address some of these semantic structure decisions.

Aside from shifting our focus, another approach that we at Palantir recently adopted is the use of an interactive prototype. This prototype is essentially a Drupal site, with FPO content, and all the content types needed by the client, styled in Zen, with a little bit of light wireframing design, i.e., grey outlines. So the first phase of our project is finally asking the client to nail down what they want on their site and how they want users to enter that data and retrieve that data. We then let Drupal do the work, and let the designers theme the output, NOT vice versa. How does this help? If you have the ability to do this interactive prototype before designs are even created, you can then use the wireframed prototype in Drupal as a stepping stone for the design. The beauty of Zen is that even with its scaled back CSS, it maintains a framework and upholds semantic markup.

Like I said, for some this might be obvious, but for others who’ve been missing the point like me, this brings a whole new focus to my approach to theming for Drupal. So I hope to embrace that role as themer and build toolkit into every site I work on. No more skinning, time to theme.