SonSpring

Sass for Designers

Nathan Smith — Sun, 28 Aug 2011 18:48:29 +0000

CSS

For more on Sass, read The Sass Way and follow @TheSassWay on Twitter.

Note: Throughout this post, when I say “Sass” I mean “Sass and Compass.”

This is not a post saying…

~~“If you’re still building websites without Sass, you’re doing it wrong.”~~

This is a post saying:

“If you haven’t tried Sass/Compass, please do before dismissing it.”

My Lawn…

Clint Eastwood in Gran Torino

If you are anything like me, then as a designer you are also probably a bit of a curmudgeon, though perhaps you consider it perfectionism – and justifiably so. You have honed a specific workflow you adhere to because that is what works, dang it. Woe unto anyone who suggests you are not doing things in the best possible way, right? Yes, exactly! Except, well… no.

I believe my first reaction to Wynn Netherland, when he told me I ought to try Sass and that perhaps I would see a boost in productivity, was something along the lines of: “Bah, get off my lawn” — a reference to the cantankerous character played by Clint Eastwood in Gran Torino.

I came to realize that his suggestion was not a subtle way of saying “I know something you don’t know” (though he did), but more of a friendly nudge towards greater efficiency. He was just being a good neighbor, so to speak.

So, I am writing this post in an attempt to get designers out there (who are also already CSS savvy) to try Sass and Compass. I aim for this to be the article I wish I had read when I was first contemplating Sass but (at the time) did not consider it worthwhile. I could not have been more wrong.

FUD

There seem to be a number of false assumptions that designers get hung up on when it comes to the topic of CSS preprocessors. I know such misconceptions exist because I myself had these doubts ruminating in the back of my mind, and have seen others express similar sentiment, without actually having tried Sass. I hope to clear some of those up here…

Myth:

Using the command-line is hard
Using the command-line is inconvenient
I must learn both Sass and Compass
Sass requires me to know Ruby
Sass requires a foreign syntax
Sass only works in Ruby on Rails
Sass is always white-space sensitive

Fact:

Using the command-line is not scary
Using the command-line is infrequent
Sass and Compass go hand-in-hand
Sass doesn’t require Ruby knowledge
Sass is just CSS syntax, with extras
Sass runs on Ruby (already on OS X)
— outputs flat CSS, to use anywhere
Sass itself is white-space sensitive
— SCSS is not, use either one

Think of it this way… As a designer you have undoubtedly worked on some project using PHP, Django, Rails, etc. You do realize PHP is a recursive acronym that means PHP: Hypertext Preprocessor — don’t you? Somehow, it is perfectly fine to preprocess HTML for productivity gains. Why should CSS be off the table?

Setup

Windows:

On Windows, you will first need to run the Ruby Installer.

Linux:

On Linux, Rails Ready provides several Ruby essentials – read more here.

OS X:

This “just works” on a Mac, because Ruby is installed by default on OS X.

Gem Install

Note: The ~ symbol is an alias to username on OS X and Linux. If using Windows, replace ~ with %USERPROFILE% in the following command-line examples.

For the sake of brevity, and server language agnosticism, let’s say you want to use Sass on a flat-file HTML site. To install Compass, which comes with Sass, just open up your favorite command-line utility, such as Terminal.app and type…

Windows:

gem install compass

Linux + OS X:

sudo gem install compass

Next… Actually, that’s it! Compass and Sass are now installed.

New Project

Still got Terminal open? Good, just a few more minor things to type.

To create a SCSS project named “my_project” on your desktop, do this…

compass create ~/desktop/my_project

Or, to create a Sass project named “my_project” on your desktop, type…

compass create ~/desktop/my_project -x sass

Regardless if you specified Sass (or defaulted to SCSS) as your preferred syntax, you will see a directory named “my_project” on your desktop, with a config.rb file inside. Really, this is all you need to get a Compass project going. You will see the various options nicely explained in the “#” comments.

config.rb file:

# Require any additional compass plugins here.

# Set this to the root of your project when deployed:
http_path = "/"
css_dir = "stylesheets"
sass_dir = "sass"
images_dir = "images"
javascripts_dir = "javascripts"

# You can select your preferred output style
# here (can be overridden via the command line):
# output_style = :expanded or :nested or :compact or :compressed

# To enable relative paths to assets via
# compass helper functions. Uncomment:
# relative_assets = true

# To disable debugging comments that display the
# original location of your selectors. Uncomment:
# line_comments = false

preferred_syntax = :sass

Now that you’re done creating the project, you won’t need to type “compass create” again until you want to create an entirely new project. Or, if you’re like me – you can tweak your newly created project files and save them to reuse later as starting point for new projects. After which, all you’ll have to do is…

Compass Watch

Now that the “my_project” directory exists, go into it…

cd ~/desktop/my_project

Then tell Compass to watch for changes to your *.sass (or *.scss) files…

compass watch

As changes are detected in your *.sass (or *.scss), new *.css file(s) will be compiled on-the-fly. Once you’re satisfied with how things have shaped up, you can hit Ctrl-C to stop the watcher, and go deploy your flat CSS.

Syntax

You can use either the Sass or SCSS syntax, and can even have *.sass files and *.scss files in the same project, as long as you don’t mix the syntax within the same file. You can also @import flat *.css files into a *.sass or *.scss file. It all compiles down nicely into flat *.css file(s).

Sass and SCSS differ only in that SCSS syntax is a “super-set” of CSS3 — just a fancy term that means all regular CSS still works fine inside of SCSS — and curly braces and semi-colons are still valid and required.

Whereas in a Sass file, curly braces and semi-colons are not only unnecessary, they’re invalid. That might sound like crazy talk at first glance, but after having tried both, I can say I greatly prefer Sass to SCSS. But to each his/her own.

At it’s core, Sass syntax can be thought of as simply CSS without {, }, or ;. In fact, if you do a find-and-replace, substituting nothingness for those characters “”, you’ll be all set to start converting flat CSS files into Sass.

By way of example, here is the same code in SCSS and Sass, and what it would look like compiled (or written long-hand) in CSS…

SCSS:

// This comment is not output to CSS.

/* This comment is output to CSS */

#foo {
  font: {
    size: 13px;
    family: 'Helvetica Neue', Arial, sans-serif;
  }
  .bar,
  .baz {
    border-width: 1px;
  }
  .bar {
    border: {
      style: solid;
      color: #369;
    }
  }
  .baz {
     border: {
      style: dotted;
      color: #693;
    }
  }
}

Sass:

// This comment is not output to CSS.

/* This comment is output to CSS */

#foo
  font:
    size: 13px
    family: 'Helvetica Neue', Arial, sans-serif

  .bar,
  .baz
    border-width: 1px

  .bar
    border:
      style: solid
      color: #369

  .baz
    border:
      style: dotted
      color: #693

CSS:

/* This comment is output to CSS */

/* line 5, ../sass/screen.sass */
#foo {
  font-size: 13px;
  font-family: "Helvetica Neue", Arial, sans-serif;
}

/* line 10, ../sass/screen.sass */
#foo .bar,
#foo .baz {
  border-width: 1px;
}

/* line 14, ../sass/screen.sass */
#foo .bar {
  border-style: solid;
  border-color: #336699;
}

/* line 19, ../sass/screen.sass */
#foo .baz {
  border-style: dotted;
  border-color: #669933;
}

Compression

You’ll note in the example above that the line numbers for each selector are written out in the CSS file, via comments. This is helpful if you combining multiple files via Sass importing, because unlike the typical @import in a flat CSS file, Sass will combine multiple files into one. This style of commenting helps you trace the origin of a style, in case you wanted to debug.

When deploying to production once everything is solid, there is little need for these comments (nor indentation and line breaks), because browsers will render the code with or without them. Thankfully, all it takes is setting one option in your config.rb file, and everything will be minified auto-magically…

output_style = :compressed

This yields code that is difficult to read for humans, but is perfectly optimized to save precious bytes, and is perfectly parsable by any given browser…

#foo{font-size:13px;font-family:"Helvetica Neue",Arial,sans-serif}#foo .bar,#foo .baz{border-width:1px}#foo .bar{border-style:solid;border-color:#369}#foo .baz{border-style:dotted;border-color:#693}

You’ll even notice that every instance of “;}” has been replaced with “}” because CSS does not require a semi-colon on the last rule of each block. Little things like this add up, potentially resulting in a significant reduction of overall file-size. This equates to faster page loading, which we all know is pretty important.

Compass

Even if the aforementioned features were all Sass was capable of, it would be worth looking into. At the risk of sounding like an infomercial salesman… But wait, there’s more! Where Sass left off, Compass goes to the next level.

Chris Evans as Captain America

Gradients

How many times have you attempted to remember the puzzling syntax for a CSS3 gradient? Though similar in implementation, the code to produce it is maddeningly different depending on the browser.

This is where Compass truly shines, providing mixins that output this code for you. With Sass, most of it you write yourself, but Compass is great at bleeding edge CSS3, for which no human should have to remember the syntax.

This terse, logical Sass/Compass code:

@import compass/css3

#foo
  +background(linear-gradient(#fff, #ccc))

Turns into this ridiculous assortment:

/* line 3, ../sass/screen.sass */
#foo {
  background: -webkit-gradient(linear, 50% 0%, 50% 100%, color-stop(0%, #ffffff), color-stop(100%, #cccccc));
  background: -webkit-linear-gradient(#ffffff, #cccccc);
  background: -moz-linear-gradient(#ffffff, #cccccc);
  background: -o-linear-gradient(#ffffff, #cccccc);
  background: -ms-linear-gradient(#ffffff, #cccccc);
  background: linear-gradient(#ffffff, #cccccc);
}

Experimental SVG

You can even set an “experimental” flag, to have Compass output SVG for you. This is great for browsers like IE9 and older versions of Opera, that understand how to render an embedded base64 encoded image, but can’t natively draw CSS3 gradients. A simple variable set to “true” outputs the necessary code.

If you set $experimental-support-for-svg: true…

@import compass/css3

$experimental-support-for-svg: true

#foo
  +background(linear-gradient(#fff, #ccc))

A base64 encoded SVG string is output…

/* line 5, ../sass/screen.sass */
#foo {
  background: url('data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4gPHN2ZyB2ZXJzaW9uPSIxLjEiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PGRlZnM+PGxpbmVhckdyYWRpZW50IGlkPSJncmFkIiBncmFkaWVudFVuaXRzPSJ1c2VyU3BhY2VPblVzZSIgeDE9IjUwJSIgeTE9IjAlIiB4Mj0iNTAlIiB5Mj0iMTAwJSI+PHN0b3Agb2Zmc2V0PSIwJSIgc3RvcC1jb2xvcj0iI2ZmZmZmZiIvPjxzdG9wIG9mZnNldD0iMTAwJSIgc3RvcC1jb2xvcj0iI2NjY2NjYyIvPjwvbGluZWFyR3JhZGllbnQ+PC9kZWZzPjxyZWN0IHg9IjAiIHk9IjAiIHdpZHRoPSIxMDAlIiBoZWlnaHQ9IjEwMCUiIGZpbGw9InVybCgjZ3JhZCkiIC8+PC9zdmc+IA==');
  background: -webkit-gradient(linear, 50% 0%, 50% 100%, color-stop(0%, #ffffff), color-stop(100%, #cccccc));
  background: -webkit-linear-gradient(#ffffff, #cccccc);
  background: -moz-linear-gradient(#ffffff, #cccccc);
  background: -o-linear-gradient(#ffffff, #cccccc);
  background: -ms-linear-gradient(#ffffff, #cccccc);
  background: linear-gradient(#ffffff, #cccccc);
}

This can potentially add file-size and as such is (smartly) an opt-in feature, because the $experimental-support-for-svg flag defaults to false unless you specifically enable it. Still, it’s pretty cool to know it’s there.

Border Radius

Without belaboring the point of how cool Compass is, let me show one more CSS3 example. Adding a border radius is trivial enough, since the syntax is somewhat similar (aside from vendor prefixes), but what if you only wanted to round three out of the four corners of an element? It gets a bit more tricky, because browsers differ: “…top-right-radius” vs. “…radius-topright” etc. Compass to the rescue!

You just type this…

@import compass/css3

#foo
  +border-top-left-radius(4px)
  +border-top-right-radius(4px)
  +border-bottom-left-radius(4px)

Compass does the heavy lifting…

/* line 3, ../sass/screen.sass */
#foo {
  -moz-border-radius-topleft: 4px;
  -webkit-border-top-left-radius: 4px;
  -o-border-top-left-radius: 4px;
  -ms-border-top-left-radius: 4px;
  -khtml-border-top-left-radius: 4px;
  border-top-left-radius: 4px;
  -moz-border-radius-topright: 4px;
  -webkit-border-top-right-radius: 4px;
  -o-border-top-right-radius: 4px;
  -ms-border-top-right-radius: 4px;
  -khtml-border-top-right-radius: 4px;
  border-top-right-radius: 4px;
  -moz-border-radius-bottomleft: 4px;
  -webkit-border-bottom-left-radius: 4px;
  -o-border-bottom-left-radius: 4px;
  -ms-border-bottom-left-radius: 4px;
  -khtml-border-bottom-left-radius: 4px;
  border-bottom-left-radius: 4px;
}

The Hard Sell

What’s that, champ? You have all that fancy CSS3 syntax memorized already? Right… I bet you do. Keep telling yourself that. Seriously though, even if you know all those keystrokes, who in their right mind wants to type all that?

Okay, fine. I will up the ante. Compass also has support for image sprites. You know that PSD or PNG file you maintain with tons of little icons, where you cleverly count the number of pixels each is offset from the top-left of the document? You can quit doing that, and instead have multiple, separate files that Compass will combine into one single HTTP request.

Sass also has a slew of color functions that can act upon colors, so that you don’t have to painstakingly recolor things in Photoshop, and retrieve hex values via the color dropper. If you want to darken something 10%, just do it…

#foo
  color: darken(#369, 10%)

Which yields…

/* line 1, ../sass/screen.sass */
#foo {
  color: #264c73;
}

Oh, and get this… Sass supports math, and Compass adds enumeration. That means you can create loops that spit out numerically incremented code, perfect for making custom vertical grid dimensions. For example, the 960 plugin.

There is even a plugin to establish a baseline horizontal grid, called vertical rhythm, allowing you to achieve the (oft sought, rarely realized) goal of uniform line-height throughout an entire page. It’s not automatic, but it certainly gets you further than you might get manually adjusting margin and padding.

Apps

Currently, there are two apps that can be used to basically simulate “compass watch” to check for changes to *.sass and/or *.scss files and convert them to CSS. Also, I know of at least one other app that’s in progress, currently undergoing a private beta test. The two apps available today are:

Compass.app
— built in: JRuby
— open source, on GitHub
— cost: $7.00 compiled
Scout
— built in: JRuby + Adobe AIR
— open source, on GitHub
— cost: free

Done

I could go on and on, but instead I will let you go read more about Sass and Compass in detail. I will say this: If you are a designer who prides yourself on writing efficient front-end code, then I would encourage you to give ‘em a shot. Worst case scenario, you end up back writing CSS the way you have been doing it. Best case scenario, you have another skill to add to the ol’ arsenal.

Just think of Sass (and Compass) like the “jQuery of CSS.” Those who understand the fundamentals of CSS will always have an edge over designers who don’t code at all. A solid tool like Compass in the hands of a master CSS craftsman only serves to make him/her all the more effective, further widening the gap.

JavaScript Interview Questions

Nathan Smith — Wed, 08 Jun 2011 05:05:34 +0000

JavaScript

I was perusing my list o’ RSS feeds this evening — Yes, I’m one of those people who still read RSS — and happened upon a list of JavaScript interview questions posted by James Padolsey. This reminded me that I had a few questions tucked away from when I was contacted by a Meebo recruiter a few years ago.

I didn’t apply for the job, because I was working at the (now defunct) startup Viewzi, and I didn’t want to uproot from Dallas and move to California. Just for kicks, I asked the recruiter if it’d be okay if I went ahead and tried my hand at their code questions anyway. After which, the recruiter replied:

You aced the puzzlers, well done! Are you sure you don’t want to be considered for our JavaScript / Front-End Developer position? If you ever have the itch to move to CA, be sure to let me know!

Since a few years have elapsed since then, I am hoping that it is kosher for me to share these questions, along with the answers I provided…

1. When does div.setAttribute('###') not equal div.###?

Answer:

When you’re trying to set an element’s class attribute, IE has issues. Therefore, it’s better to use .className instead of .setAttribute(). There is also an issue with .setAttribute() and style in IE, so .style should be used.

// Don't do this:
el.setAttribute('class', 'foobar');

// Do this instead:
el.className = 'foobar';

// Don't do this:
el.setAttribute('style', 'color: #000');

// Do this instead:
el.style.color = '#000';

2. What’s the difference between these two statements:

var x = 3;

x = 3;

Answer:

The first puts the variable in the scope of whatever function it was defined. The second places the variable in global scope. It can potentially cause collision with other variables with the same name. Therefore, the keyword var should always be used when defining variables, and an anonymous function should be used as a closure if need be, encapsulating multiple functions which can share access to the same set of variables. That makes sure the variables stay sandboxed, accessible only by those functions which need them.

3. What’s the difference between:

!!(obj1 && obj2);

(obj1 && obj2);

Answer:

The first returns a “real” boolean value, because you first negate what is inside the parenthesis, but then immediately negate it again. So, it’s like saying something is “not not” truth-y, making it true. The second example simply checks for the existence of the obj1 and obj2, but might not necessarily return a “real” boolean value, instead returning something that is either truth-y or false-y. This can be problematic, because false-y can be the number 0, or an empty string, etc. Simple existence can be truth-y. A “real” boolean will only be true or false.

4. Write a one-line piece of JavaScript code that concatenates all strings passed into a function. (Note: Formatting added for readability)

function concatenate() {
  return String.prototype.concat.apply('', arguments);
}

More on that here…
http://sitepen.com/blog/2008/05/09/string-performance-an-analysis

5. What do these two examples have in common?

Short Answer:

Both create potential memory leaks, especially in Internet Explorer.

Example 1:

var obj = document.getElementById('adiv');

document.getElementById('adiv').ptr = obj;

Long Answer:

This is bad practice, because you first assign a DOM element to a variable, but then you assign that same element to a (nonexistent) property of the element itself. This creates a sort of circular logic loop, and will negatively impact performance.

Example 2:

function assignClick() {
  var el = document.createElement('div');

  function handleClick() {
    el.innerHTML = 'clicked!';
  }

  el.attachEvent('onclick', handleClick);
}

Long Answer:

This example will only work in Internet Explorer, because it employs the proprietary .attachEvent() method. Granted, .innerHTML ~~is also proprietary~~ (now a standard), but unlike .attachEvent(), .innerHTML is widely supported in all modern browsers. To make this example more cross-browser friendly, the W3C standard .addEventListener() should attempted first, and if it does not exist, then try .attachEvent() as a fallback.

HTML5 in Drupal 7

Nathan Smith — Sun, 22 May 2011 02:49:19 +0000

Content Management

I have been meaning to write this post for awhile. A few friends have asked me to explain how to do HTML5 in Drupal 7, via Twitter. Another concerned individual, having found a passing reference to it in a book review, even emailed:

“I urge you to start producing this post just as deeply as you explained basic 960 principles. How I enjoyed reading it. It was like a chat with a soulmate! It is a rare opportunity to read background on why things are the way they are. In my mental system, why is the key ingredient to know what are you doing.”

So, without further ado, here it is…

Intro

In addition to HTML5, I will cover how to remove some of the generated markup Drupal spits out by default, and how to override default system CSS. I will also provide a few tips on how to get some quick-win page speed boosts.

Before we dive in, I just wanted to mention that this won’t be a comprehensive how-to on building a Drupal 7 theme. For the sake of brevity, I won’t be covering the HTML5 Tools module, which endeavors to add features like new HTML5 form elements to Drupal. Instead, I will focus on trimming the XHTML glut that Drupal still instinctively wants to include, stemming from its earlier days.

Remember — back before the W3C declared XHTML 2.0 is dead, heralding HTML5 as the future — when we all used to put type="text/css" on tags, as if we’d ever used a <style> tag that wasn’t CSS? Oh how silly we were! Yet we thought we were so cool, appeasing the validator. Then HTML5 came along, paving cowpaths, exposing the tedium of so many practices we’d once thought necessary.

Structure

When you first install Drupal, you will see a top-level directory named themes. Common sense would tell you that this is where you should store your own theme related files. In this case, common sense is wrong! In actuality, the directory you want to play in is sites. This is all about you and your particular site(s), and therein is another themes directory that will house your theme(s).

Note: Drupal can handle multiple domains via a single codebase, hence the “sites” directory instead of “site,” but that’s beyond the scope of this article. If you’re interested, there’s a Multisite Drupal group dedicated to the topic.

The first thing you should do is create a *.info file with the name of your theme. Since my site is sonspring.com, and my theme is aptly named “SonSpring,” my info file is sonspring.info. Here are the contents (”;” comments out a line)…

; BASIC SETTINGS
name = SonSpring
core = 7.x

; FEATURES (intentionally blank)
features[] =

; REGIONS
regions[front_journal] = front_journal
regions[content] = content
regions[sidebar_first] = sidebar_first
regions[sidebar_second] = sidebar_second
regions[search] = search

; CSS
stylesheets[all][] = assets/css/override/kill/ctools.css
stylesheets[all][] = assets/css/override/kill/field.css
stylesheets[all][] = assets/css/override/kill/node.css
stylesheets[all][] = assets/css/override/kill/system.messages.css
stylesheets[all][] = assets/css/override/kill/system.menus.css
stylesheets[all][] = assets/css/override/kill/user.css
stylesheets[all][] = assets/css/override/kill/views.css
stylesheets[all][] = assets/css/reset.css
stylesheets[all][] = assets/css/override/keep/system.base.css
stylesheets[all][] = assets/css/override/keep/system.theme.css
stylesheets[all][] = assets/css/override/keep/search.css
stylesheets[all][] = assets/css/960_12_col.css
stylesheets[all][] = assets/css/text.css
stylesheets[all][] = assets/css/formalize.css
stylesheets[all][] = assets/css/site.css

; JAVASCRIPT
scripts[] = assets/js/master.min.js

Aggregation

If you’ve looked at any Drupal themes, the preceding code is pretty straightforward stuff, nothing too out of the ordinary. One thing you might have noticed is the override directory. Inside it are two other directories, kill and keep.

I learned this trick from Morten Birch Heide-jørgensen during one of his talks on Drupal theming. He calls his folder foad and the technique FOAD, short for “F*** Off And Die” – a clever way to get rid of system CSS files you don’t want.

If you name one of your own CSS files the same as one of the defaults, Drupal will include yours instead of providing its own. Thusly, everything in the kill directory is just an empty file, whereas everything in the keep directory is a CSS file that’s been only slightly (if at all) modified from its original defaults.

Now, you might be wondering: Why bother having a keep directory at all, if I’m reusing the very same code as the default files it contains? Here’s where it gets interesting. When you go to the Performance admin page, and turn on aggregation and compression of CSS files, Drupal will gather up all its default system stylesheets into a single file, and all your stylesheets into another.

That’s silly. But with my keep directory, I force those default stylesheets – along with my theme stylesheets – to be aggregated and compressed into one file.

Template.php – Section

Call it an old habit from my beginner CMS days using Textpattern, but for theming purposes I like to know what “section” of the site I’m on. Basically, that just means I am curious what foobar is equal to, in the following scenarios…

http://example.com/foobar

http://example.com/foobar?page=1

http://example.com/foobar/node/search%20term

So, at the beginning of my template.php file, I have a simple function that runs through and grabs me the first path fragment in the URL, does a simple switch/case, and returns a string that becomes the <body> ID.

<?php

function sonspring_section() {
  $section_path = explode('/', request_uri());
  $section_name = $section_path[1];
  $section_q = strpos($section_name, '?');

  if ($section_q) {
    $section_name = substr($section_name, 0, $section_q);
  }

  switch ($section_name) {
    case '':
      return 'section_home';
      break;
    case 'journal':
      return 'section_journal';
      break;
    case 'about':
      return 'section_about';
      break;
    case 'work':
      return 'section_work';
      break;
    case 'resources':
      return 'section_resources';
      break;
    case 'contact':
      return 'section_contact';
      break;
    case 'search':
      return 'section_search';
      break;
    case 'user':
      return 'section_user';
      break;
    case 'users':
      return 'section_user';
      break;
    case 'filter':
      return 'section_filter';
      break;
    case 'admin':
      return 'section_admin';
      break;
    default:
      return 'section_404';
  }
}

Template.php – Pruning

In my template.php file, I have a function called sonspring_process_html_tag. Obviously, if your theme is named “MyTheme” then your function would be named mytheme_process_html_tag. It simply unsets the variables for the type and media attributes on style, link, and script tags.

It also clears out CDATA comments, that only ever existed to satisfy the XHTML validator, because hardly anyone ever served XHTML as application/xhtml+xml. In the past, even though we all served XHTML as text/html, we still jumped through hoops by adding CDATA comments. Not so with HTML5.

// Purge needless XHTML stuff.
function sonspring_process_html_tag(&$vars) {
  $el = &$vars['element'];

  // Remove type="..." and CDATA prefix/suffix.
  unset($el['#attributes']['type'], $el['#value_prefix'], $el['#value_suffix']);

  // Remove media="all" but leave others unaffected.
  if (isset($el['#attributes']['media']) && $el['#attributes']['media'] === 'all') {
    unset($el['#attributes']['media']);
  }
}

In reality, XHTML always worked fine without the needless code. HTML5 just makes it official. By way of comparison, here’s the before and after of what Drupal would normally output by default, followed by the slimmed down result.

Before – XHTML

<link rel="stylesheet" href="..." type="text/css" media="all" />

<style type="text/css" media="all">
/* Code here. */
</style>

<script type="text/javascript">
<!--//--><![CDATA[//><!--
/* Code here. */
//--><!]]>
</script>

After – HTML5

<link rel="stylesheet" href="..." />

<style>
/* Code here. */
</style>

<script>
/* Code here. */
</script>

Template.php – Minification

Though this doesn’t pertain to HTML5 directly, I decided that while I was mucking about in the template.php file, I might as well add some HTML minification. Basically, the following code just strips out unnecessary whitespace and line breaks, saving a bit of file size where possible. If a page contains a <pre> or <textarea> tag, it is left alone, as to not affect code blocks or text typed in a form.

// Minify HTML output.
function sonspring_process_html(&$vars) {
  $before = array(
    "/>\s\s+/",
    "/\s\s+</",
    "/>\t+</",
    "/\s\s+(?=\w)/",
    "/(?<=\w)\s\s+/"
  );

  $after = array('> ', ' <', '> <', ' ', ' ');

  // Page top.
  $page_top = $vars['page_top'];
  $page_top = preg_replace($before, $after, $page_top);
  $vars['page_top'] = $page_top;

  // Page content.
  if (!preg_match('/<pre|<textarea/', $vars['page'])) {
    $page = $vars['page'];
    $page = preg_replace($before, $after, $page);
    $vars['page'] = $page;
  }

  // Page bottom.
  $page_bottom = $vars['page_bottom'];
  $page_bottom = preg_replace($before, $after, $page_bottom);
  $vars['page_bottom'] = $page_bottom . drupal_get_js('footer');
}

Block, Field, Region, Views

While it is technically possible to make use of HTML5 and RDF together, I have opted to simply leave this aspect out of my templates, as you will see shortly. As such, I have simply disabled the RDF module (enabled by default).

For the most part, Drupal only renders what’s in your templates. But there are a few areas where it tends to wrap things in <div> tags that you might not want. Thankfully, Drupal’s theme system makes it easy to remedy. The following is a list of files that I have created, which contain only the code necessary to generate your content, thereby overriding Drupal’s default output.

I have purposefully omitted the closing ?> tag, because it is considered a best practice (by both Drupal and Zend) to not close the <?php tag. Instead, the parser realizes the PHP code is finished when it has reached the end of the file. This prevents the unintentional injection of whitespace into a page. (Needless to say, ?> is still necessary when mixing PHP and HTML within the same file.)

Note: The templates that start with “views-” pertain to Views, a third party Drupal module that makes it easy to output lists of content based on various criteria.

block.tpl.php

<?php print $content;

Note: I have removed $item_attributes from my field.tpl.php file. This is used by the RDF module, and can potentially be utilized by third party modules, to add things like onclick="..." to various elements. I removed it because I am not using the RDF module, but your mileage may vary — read more.

field.tpl.php

<?php print render($items);

region.tpl.php

<?php print $content;

views-view.tpl.php

<?php

// Shorthand for if, then print.
// I write PHP like a JS hacker.
// Pager at the top, and bottom.

isset($admin_links) && print $admin_links;
$header && print $header;
$exposed && print $exposed;
$attachment_before && print $attachment_before;
$pager && print $pager;
$rows ? print $rows : $empty && print $empty;
$pager && print $pager;
$attachment_after && print $attachment_after;
$more && print $more;
$footer && print $footer;
$feed_icon && print $feed_icon;

views-view-unformatted.tpl.php

<?php

$title && print $title;

foreach ($rows as $id => $row) {
  print $row;
}

views-view-list.tpl.php

<?php

$title && print $title;

print '<ul class="list">';

foreach ($rows as $id => $row) {
  print '<li>' . $row . '</li>';
}

print '</ul>';

views-view-fields.tpl.php

<?php

foreach ($fields as $id => $field) {
  if (isset($field->separator)) {
    print $field->separator;
  }

  print $field->content;
}

HTML, Page, Node

Though the aforementioned files pertaining to block, field, region, and views are all technically templates, in that they end in *.tpl.php, the crux of the templating system revolves around HTML, page, and node templates.

Below, I have listed out the majority of my template code. You may notice I did not include my page‐‐front.tpl.php file. It is mostly hard coded because it does not change that often, with the only dynamic part being recent journal entries.

html.tpl.php

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta http-equiv="x-ua-compatible" content="ie=edge, chrome=1" />
<title><?php
  if (sonspring_section() === 'section_home') {
    print 'SonSpring by Nathan Smith';
  }
  else {
    print $head_title;
  }
?></title>
<!--[if lt IE 8]>
<script>
window.top.location = 'http://desktop.sonspring.com/ie.html';
</script>
<![endif]-->
<meta name="author" content="Nathan Smith">
<meta name="description" content="Personal and professional home of Christian web designer Nathan Smith." />
<link rel="alternate" type="application/rss+xml" title="SonSpring RSS" href="http://feeds.feedburner.com/sonspring" />
<link rel="shortcut icon" type="image/x-icon" href="/sites/all/themes/sonspring/assets/images/favicon.ico" />
<link rel="stylesheet" href="http://fonts.googleapis.com/css?family=Oswald" />
<?php print $styles; ?>
</head>
<body id="<?php print sonspring_section(); ?>">
<?php
  print $page_top;
  print $page;
  print $scripts;
  print $page_bottom;
?>
<script async="async" src="http://mint.sonspring.com/?js"></script>
</body>
</html>

page.tpl.php

<div id="wrapper">
  <?php include 'assets/includes/header.inc'; ?>
  <div id="main" class="container_12">
    <div class="grid_10">
      <h1><?php print $title; ?></h1>
      <?php $tabs && print render($tabs); ?>
      <div class="grid_7 alpha">
        <?php print render($page['content']); ?>
      </div>
      <div class="grid_3 omega aside">
        <?php $page['sidebar_first'] && print render($page['sidebar_first']); ?>
      </div>
    </div>
    <div class="grid_2 aside">
      <?php
        include 'assets/includes/fusion.inc';
        $page['sidebar_second'] && print render($page['sidebar_second']);
      ?>
    </div>
  </div>
</div>
<?php include 'assets/includes/footer.inc';

page‐‐search.tpl.php

<div id="wrapper">
  <?php include 'assets/includes/header.inc'; ?>
  <div id="main" class="container_12">
    <div class="grid_10">
      <h1><?php print $title; ?></h1>
      <?php
        $tabs && print render($tabs);
        $page['content'] && print render($page['content']);
      ?>
    </div>
    <div class="grid_2 aside">
      <?php
        include 'assets/includes/fusion.inc';
        $page['sidebar_second'] && print render($page['sidebar_second']);
      ?>
    </div>
  </div>
</div>
<?php include 'assets/includes/footer.inc';

Note: In node.tpl.php, I removed $attributes, $title_attributes, and $content_attributes, used for RDF. For a pristine node.tpl.php — source.

node.tpl.php

<?php
  !empty($content['upload']) && hide($content['upload']);
  !empty($content['taxonomy_vocabulary_1']) && hide($content['taxonomy_vocabulary_1']);
  !empty($content['links']) && hide($content['links']);
?>
<div class="node clearfix">
  <?php if (!$page) { ?>
    <?php print render($title_prefix); ?>
    <h2>
      <a href="<?php print $node_url; ?>"><?php print $title; ?></a>
    </h2>
    <?php print render($title_suffix); ?>
  <?php } ?>
  <?php if ($submitted) { ?>
    <?php if ($page) { ?>
      <div class="g_plus"><div class="g-plusone" data-size="small" data-count="false"></div></div>
    <?php } ?>
    <div class="meta mute">
      <span class="submitted">
        <?php print format_date($node->created); ?>
      </span>
      &mdash;
      Topic:
      <?php print render($content['taxonomy_vocabulary_1']); ?>
    </div>
  <?php } ?>
  <?php
    print render($content);
    print render($content['links']);
  ?>
</div>

Includes

For the sake of completeness, I figured I ought to finish by listing out the contents of my *.inc files, contained within an includes directory under assets. While these files could have just as easily been left in the higher level *.tpl.php files, to ease in maintainability and in an effort to adhere to DRY principles, I separated them out into their own files. By having the file extension *.inc, Drupal knows to disallow direct browsing, so they can only be used via inclusion in a PHP page.

header.inc

<div id="header">
  <div class="container_12">
    <div class="grid_3" id="ss_logo">
      <?php
        if (!$is_front) {
          print '<a href="/">';
        }

        print '<span>SonSpring</span>';

        if (!$is_front) {
          print '</a>';
        }
      ?>
    </div>
    <div class="grid_7">
      <ul id="nav">
        <li id="nav_journal">
          <a href="/journal">Journal</a>
        </li>
        <li id="nav_about">
          <a href="/about">About</a>
        </li>
        <li id="nav_work">
          <a href="/work">Work</a>
        </li>
        <li id="nav_resources">
          <a href="/resources">Resources</a>
        </li>
        <li id="nav_contact">
          <a href="/contact">Contact</a>
        </li>
      </ul>
    </div>
    <div class="grid_2">
      <?php
        if ($page['search'] && sonspring_section() !== 'section_search') {
          print render($page['search']);
        }
      ?>
    </div>
  </div>
</div>

fusion.inc

<a href="http://fusionads.net/" id="fusion_link">Powered by Fusion Ads</a>
<div id="fusion_ad"><span class="clear">&nbsp;</span></div>

footer.inc

<div id="footer">
  <div class="container_12">
    <div class="grid_4">
      &copy; <?php print date('Y'); ?> <a href="https://profiles.google.com/sonspring/about">Nathan Smith</a>. All rights reserved.
    </div>
    <div class="grid_4">
      <a href="http://www.firehost.com/?ref=spon_nsmith_sonspring" title="Secure Hosting" id="hosted_by_firehost">Hosted by FireHost</a>
    </div>
    <div class="grid_4 align_right">
      <a href="http://feeds.feedburner.com/sonspring">Subscribe</a> via RSS. Follow me on <a href="http://twitter.com/nathansmith">Twitter</a>.
    </div>
  </div>
</div>

Conclusion

While all that might seem like a lot of code at first glance, keep in mind that’s pretty much the entirety of my site’s theme (aside from CSS and light JavaScript). Once you get the hang of how it works, the Drupal theming system really not that difficult to understand. Plus, you’re learning real PHP, not pseudo code.

I wouldn’t say Drupal is perfect, but it offers extensibility via simple overrides. By far, it is the most intuitive approach I’ve found in my meandering quest for the ideal CMS. Hopefully this walkthrough has helped dispel the myth that Drupal’s learning curve is “steep,” or at least made the process seem less daunting.

This article has been translated into Ukrainian by Vlad Brown of Android Eclipse.

Adapt JS Explained

Nathan Smith — Sat, 14 May 2011 20:35:33 +0000

JavaScript

This explains the origins of, and how to use, Adapt.js – (skip to How to use)

First Off

Let me say specifically that Adapt.js does not purport to be Responsive Web Design. The definition of RWD, as Ethan Marcotte initially described it, specifically involves using both: fluid widths and @media queries. He has further clarified this point through discussions on Twitter, posts on his blog and public presentations.

I just wanted to be clear that I never tagged Adapt.js as “responsive” – and preemptively (before launching Adapt.js) assured Ethan privately via email that I would not attempt to muddy the waters. Nevertheless, some have made that association on their own. I emphasize this distinction because I don’t want Ethan’s RWD efforts (or book) to go the way of HTML5, where marketers grab ahold of the term, and repurpose it to mean whatever is bright, shiny, and new.

Waxing Poetic

If anything, Adapt.js heralds from back alleys of the old-school. It depends not on CSS3, but on properties that can be reliably detected using JS – across multiple versions of multiple browsers, on multiple devices. Considering that @media queries require a polyfill for older browsers, namely everything up to (and including) IE8, JavaScript has to be involved either way. That may seem like backwards thinking, but remember that JavaScript predates the existence of CSS anyway.

Don’t get me wrong, I certainly see the appeal of being able to manage everything via CSS. In fact, before learning JavaScript, I used to pride myself on really knowing CSS (before the days of CSS frameworks). After dabbling in JavaScript, I realized something. Now it’s a point I’ve made repeatedly, with aspiring front-end developers and designers, about rounding out one’s skill-set…

Mastering CSS is akin to building amazing things with Legos. Understanding JavaScript is like manufacturing Legos. Though related, they are simultaneously altogether different.

But I digress. When I first read Ethan’s post, I whipped up a (failed) experiment to see if specifying media="..." could be used to conditionally serve/block CSS files, based on browser width. If you’re curious, that can be seen here…

http://host.sonspring.com/media_queries

I was disappointed to learn that as with media="print" stylesheets, the entirety of the code is downloaded by the browser, on the off-chance it might be needed. Unlike the tech savvy web developers amongst us, the majority of the general public do not constantly resize their browsers looking for easter eggs.

Grey’s

So instead, I decided to let the idea sit on the shelf for awhile. Until, one evening while watching Grey’s Anatomy via Netflix with my wife, it hit me. If I am really concerned about testing for width, why not test for width, using an age-old technique? (“Old” is relative, when we’re talking about the Internet.)

So I grabbed my laptop and whipped up what ended up being a less than 1KB (minified) snippet of JavaScript that would conditionally create …

<link rel="stylesheet" href="..." />

… based on browser width. Over the next few evenings, I whittled down to the essential code. A few weeks later, based on a few requests via Twitter and GitHub, I added the ability to specify a callback function that fires as the page loads/resizes. This allows your code to take action once Adapt.js does its work.

Note: As cheesy as TV medical dramas might be, I mention that the idea came whilst distracted, because sometimes our most inspirational moments hit us when we’re not actively looking for them, but are engaged in passive thought.

How To Use

In all the following examples, feel free to drop the “px” suffix. It is just there to emphasize that the calculations done by Adapt.js are pixel-based.

At the bare minimum, if all you want is to serve just the CSS needed on page load, but not worry about browser resize and whatnot, all you’d really need is this:

var ADAPT_CONFIG = {
  path: 'assets/css/',
  range: [
    '0px    to 760px  = mobile.css',
    '760px  to 980px  = 720.css',
    '980px  to 1280px = 960.css',
    '1280px to 1600px = 1200.css',
    '1600px to 1920px = 1560.css',
    '1920px           = fluid.css'
  ]
};

Bear in mind, you needn’t use these naming conventions for your CSS files. “720.css” could just as easily be “peanut_butter.css” or any other name.

Now let’s suppose you want to put all your mobile styles in your main stylesheet, and only add extra styles above a certain width threshold. The following code is basically saying “If the width is greater than 760px, add desktop.css.” Adapt.js knows this, because it’s the last (only) entry in the range array.

var ADAPT_CONFIG = {
  path: 'assets/css/',
  range: [
    '760px = desktop.css'
  ]
};

If you want to adapt to browser resize and device tilt, add the dynamic flag.

var ADAPT_CONFIG = {
  path: 'assets/css/',
  dynamic: true,
  range: [
    '760px = desktop.css'
  ]
};

Callback

For JS you want to fire when the page resizes, specify a callback function.

var ADAPT_CONFIG = {
  path: 'assets/css/',
  dynamic: true,
  callback: myCallback,
  range: [
    '0px    to 760px  = mobile.css',
    '760px  to 980px  = 720.css',
    '980px  to 1280px = 960.css',
    '1280px to 1600px = 1200.css',
    '1600px to 1920px = 1560.css',
    '1920px           = fluid.css'
  ]
};

If you don’t want to swap CSS files, simply leave them out, and don’t specify path. That will still allow you take advantage of Adapt.js to trigger a callback function.

var ADAPT_CONFIG = {
  dynamic: true,
  callback: myCallback,
  range: [
    '0    to 760',
    '760  to 980',
    '980  to 1280',
    '1280 to 1600',
    '1600 to 1920',
    '1920'
  ]
};

HTML ~ Class Name

VIEW DEMO – Class Name

The callback is passed range index and width — myCallback(i, width). Based on that info, you could do any number of things. One common use case, I’m assuming, would be to add a class name to the HTML tag. That would allow you to make slight tweaks, via descendant selectors in your master CSS file.

For the sake of discussion, I’m using the function name myCallback. However, you could just as easily name your callback function myLittlePony, captainAmerica, or specify it as part of an application namespace like MY.app.adapt_callback.

In the example below, i is the index of the range array. Since arrays in JS (really, every language) are zero indexed, this means that the first one would be 0, the second would be 1, etc. Don’t blame me, I didn’t make the rules!

function myCallback(i, width) {
  // Alias HTML tag.
  var html = document.documentElement;

  // Find all instances of range_NUMBER and kill 'em.
  html.className = html.className.replace(/(\s+)?range_\d/g, '');

  // Check for valid range.
  if (i > -1) {
    // Add class="range_NUMBER"
    html.className += ' range_' + i;
  }

  // Note: Not making use of width here, but I'm sure
  // you could think of an interesting way to use it.
}

In your master CSS file, you could do style overrides, like so…

.foobar {
  /* Default styles here. */
}

html.range_0 .foobar {
  /* Style overrides for: 0px to 760px */
}

html.range_1 .foobar {
  /* Style overrides for: 760px to 980px */
}

/* etc. */

HTML ~ ID

VIEW DEMO – ID

If you prefer to use an id selector instead, assuming you don’t already have something like id="example_com" or id="example_org" on your HTML tag, you could define an extremely simple callback function. Like so…

function myCallback(i) {
  // Replace HTML tag's ID.
  document.documentElement.id = 'range_' + i;
}

That yields a stronger CSS selector to style against (id trumps class).

html#range_0 .foobar {
  /* Style overrides for: 0px to 760px */
}

/* etc. */

That’s just one example. Your callback could do whatever you want, allowing the file size of Adapt.js to remain lightweight. Just make sure to define your callback function before referencing the adapt.js file, so that it will be recognized.

That’s a Wrap

I think that about covers it. It is my sincere hope that Adapt.js will help alleviate some development woes. If you think I’ve left anything out, feel free to contact me and/or hit me up on Twitter. I will do my best to answer any questions.

How I Do Form Layouts

Nathan Smith — Thu, 12 May 2011 18:37:49 +0000

HTML

I originally posted this as a comment on Forrst, but since comments are only viewable by Forrst members, I am re-posting it here. Really, it’s no big deal, and is pretty old-school. I just figured it might help with people beating their heads against a desk, attempting form layouts using float. Hint: don’t bother.

Note: I’m not here to argue. I’m posting specifically because I was asked (by the author of this post/question) for my opinion via Twitter. :)

http://twitter.com/kom420/status/68728880294395905

Depends on the layout I need, but I usually just go the paragraph route. Unless I need labels side-by-side with form elements, in which case the varying length (of label text) makes floats a pain. In that case, I’d do…

Side-by-side layout

<form accept="..." action="..." method="...">
  <table class="form">
    <tr>
      <th>
        <label for="input_1">
          Label text
        </label>
      </th>
      <td>
        <input type="text" id="input_1" name="input_1" />
      </td>
    </tr>
    <tr>
      <th>
        <label for="input_2">
          Label text
        </label>
      </th>
      <td>
        <input type="text" id="input_2" name="input_2" />
      </td>
    </tr>
    <tr>
      <th>
        &nbsp;
      </th>
      <td>
        <input type="submit" value="Submit" />
      </td>
    </tr>
  </table>
</form>

Now, before anyone cries “unsemantic” — Note that this is about ease of maintenance. Floats with fixed-widths on labels only work so well, until the label gets longer. It’s just not worth the hassel to constantly re-visit the CSS because of form elements changing. I’m speaking from experience, having worked at a Fortune 50 company previously (and now a Fortune 10 co.), where that type of stuff is not always under your control.

Also worth noting, is that most (maybe all?) assistive devices (screen readers) go into a different reading mode when speaking form content, so the table does not throw off its interpretation. Instead, it reads label and input combinations.

For the CSS, to force the th to be as narrow as possible, I do this…

(See form example on Formalize.me for an approximation)

.form th {
  text-align: right;
  white-space: nowrap;
  width: 1%;
}

Stacked Layout

Oh, and if I’m doing a stacked approach, where each label is above its respective input, I do this…

<form accept="..." action="..." method="...">
  <fieldset>
    <legend>
      Group 1
    </legend>
    <p>
      <label for="input_1">
        Label text
      </label>
      <br />
      <input type="text" id="input_1" name="input_1">
    </p>
    <p>
      <label for="input_2">
        Label text
      </label>
      <br />
      <input type="text" id="input_2" name="input_2">
    </p>
  </fieldset>
  <fieldset>
    <legend>
      Group 2
    </legend>
    <p>
      <label for="input_3">
        Label text
      </label>
      <br />
      <input type="text" id="input_3" name="input_3">
    </p>
    <p>
      <label for="input_4">
        Label text
      </label>
      <br />
      <input type="text" id="input_4" name="input_4">
    </p>
  </fieldset>
  <p>
    <input type="submit" value="Submit" />
  </p>
</form>

With a bit of CSS (via sibling selector) to increase the spacing between the label and the input for browsers that understand it (Note: doesn’t work in IE6)…

br + input,
br + select,
br + textarea {
  margin-top: 5px;
}

Drupal 7 Module Development

Nathan Smith — Fri, 25 Mar 2011 22:44:15 +0000

Product Review

While I consider myself well-versed at the front-end theme aspects of Drupal, I had been wanting to delve a little deeper into its underpinnings, if only to understand how modules work. Deconstructed, Drupal is essentially a series of modules working together — be that “core,” the bare CMS — or “contrib,” third party modules available for download from drupal.org. So, in an effort to bolster my skill set, I recently read Drupal 7 Module Development, from Packt Publishing and found it to be an excellent resource.

If you have more than a passing interest in Drupal, then you are probably aware of the significance of such a talented group of developers collaborating on this book. The author list reads like a veritable who’s who in the subculture of Drupal…

Matt Butcher works for the New York Times Company on their ConsumerSearch site. Greg Dunlap works for NodeOne, an agency in Sweden. The rest of the authors are heavy hitters at Palantir, a development firm based in Chicago.

This book does not mince words, skipping past the whole installation process, because such information is readily available online anyway. What I like best about this book is that, after the requisite introductory chapter covering the broad strokes, it gets right into building a module from scratch, aptly named First, that outputs a list of all the currently installed modules. Chapter 2 also touches on code standards (covered here), as well as how to write automated unit tests.

Chapter 3 is all about theming, and not just at a superficial stylistic level, but also how to make use of powerful preprocess functions, that allow the theme layer to edit Drupal’s output before it reaches the browser. I have implemented such techniques to make my own site HTML5, rather than the default XHTML 1.0.

With module building and theming covered, chapter 4 jumps into how to theme a module, because modules themselves typically output a varying degree of markup themselves, and can (optionally) ship with CSS to handle any custom styling. Also covered is consideration for languages that read right to left, as internationalization has been a priority even since the earliest days of Drupal. Such cases should not be overlooked if you intend to make your module publicly available for reuse.

Chapter 5 draws back the curtain a bit, so to speak, venturing into the administrative interface. Some modules do not actually affect a site’s public look and feel at all, but instead are built to facilitate a content creation workflow and/or user management. This chapter covers how to write an admin module that makes use of Drupal’s email API, sending the user a warning message if he or she is deemed to be in violation of the site’s terms of service.

Chapters 6 and 7 cover how to work with custom content and field types, using artwork as an example of a special type of content (ch. 6), with the dimensions of each piece of artwork necessitating a custom field type (ch. 7). The authors are quick to point out that Drupal itself is versatile enough to handle such cases, without needing a custom module. However, they chose this as a faux case study, simply to explain building modules that handle custom content and fields.

Chapters 8 and 9 cover permissions and security, as well as node access. One thing I have always appreciated about the community of developers around Drupal is the dedicated security team. Chapters 8 takes the same mindset, that any anonymous site visitors could potentially be nefarious, and explains the best ways to ensure that you are not leaving your site vulnerable due to exploit vectors in your module. Additionally, chapter 9 talks about conditionally showing content to various user tiers, depending on if they have the necessary credentials to view it.

Chapter 10 is all about JavaScript, explaining that Drupal makes jQuery and jQuery UI available to you as a developer. For instance, via jQuery, Drupal automatically adds a draggable handle that makes any <textarea> resizable in all browsers, even those that don’t natively support it. When building your own modules, you can also tap into the convenience that jQuery affords. This chapter covers how to employ an Ajax approach to forms, rather than doing a full round trip to the server to refresh the entire page. It also touches on how to add translation via Drupal.t(), the JavaScript equivalent of Drupal’s PHP function t().

In chapter 11, working with files and images is explained. Whereas previous versions of Drupal required an additional module to be installed in order to manipulate images, as of Drupal 7, this functionality is built into core. As a module developer, you can tap into the native Image API, allowing users to manipulate graphics via a web interface. The authors explain the process of adding a watermark to a photo, as well as how to desaturate, rotate, and resize images.

You will love chapter 12 if you build a lot of Drupal powered sites, and find yourself repeatedly setting your preferred defaults each time. While not about module development, per se, it covers how to bundle modules and site configuration into what’s called an “install profile.” This allows you create a custom installation of Drupal, preconfigured with everything you would normally have to do anyway.

Basically, this book leaves no stone unturned. As if the aforementioned chapters weren’t already enough, at the end of the book, there are two appendices that cover databases and security, to be used more as a reference than a tutorial.

I would recommend Drupal 7 Module Development to anyone who has familiarity with building sites in Drupal, but wants to take their prowess to the next level. The collective expertise imparted in this book simply cannot be overstated.

Drupal 7 First Look

Nathan Smith — Sun, 13 Mar 2011 19:06:53 +0000

Product Review

I recently finished reading Drupal 7 First Look – written by Mark Noble of Drupal by Example, and published by Packt Publishing. I have to admit what while I was interested in learning more about Drupal 7, I was a bit skeptical about a book entitled “First Look,” concerned that perhaps it wouldn’t be substantive enough. However, since I have generally been pleased with the books I’ve read from Packt in the past, I decided this one might be worth reading.

I’m happy to say that this book not only lived up to it’s “at a glance” style title, but actually went into quite a bit of depth in several areas. While ideally suited to those who have some familiarity with Drupal 6, and want to know what’s changed in version 7, I believe this book would also be a good intro for those who are just starting to get into Drupal.

Noble aptly covered many facets of Drupal, from basic site building — configuring different content types and whatnot — to the new database abstraction layer, and building custom modules. The breadth of this book, and depth of its chapters, certainly quelled any uncertainty I had about the book possibly being just a high-level overview.

Anyway, without simply running through the table of contents, I did want to highlight a few parts of this book that were particularly beneficial to me. Namely, just about everything in chapter 5: Drupal 7 for Themers. Being a front-end developer by profession, this was of particular importance to me, because though I had thoroughly learned the ins-and-outs of theming for Drupal 6, there are significant differences in version 7.

For instance, rather than page.tpl.php and/or page-specific.tpl.php being the highest level template, there is now an html.tpl.php file. This makes it a lot easier to have shared aspects across multiple page templates. Namely, things in the <head>, whereas in Drupal 6 this would have been repeated across all page level templates. Now you need only specify your CSS and JavaScript once in the html.tpl.php file.

Additionally, page templates for specific areas of a site now include two dashes. So what would have been:

page-specific.tpl.php

… in Drupal 6 now has two dashes in the file name for Drupal 7:

page--specific.tpl.php

Little changes like this were documented well throughout the book.

I also appreciate how Noble broke down the various parts of a page template, specifically calling out region.tpl.php as something that could be modified at the theme layer. This, along with block.tpl.php enabled me to greatly simplify my site’s markup. Inspired by those quick wins, I even went so far as to revamp the output of the Views module, via the various views-*.tpl.php files it responds to.

Translation: My own site, powered by Drupal 7, now renders only the markup I have specified, with next to nothing auto-generated by Drupal. I would recommend Drupal 7 First Look to anyone looking to make the transition from Drupal 6 to 7, or those simply wanting a starting point for learning more about this robust CMS.

Joining HP

Nathan Smith — Mon, 03 Jan 2011 05:17:51 +0000

Personal

These past two years have been filled with great personal growth. From fumbling through learning how to be a father to our now 2-year old son, to working alongside some of the most talented and dedicated people I’ve ever known at Fellowship Technologies, I count myself fortunate and blessed.

Choosing to move on to another opportunity was not a decision I weighed lightly. It was a bittersweet send-off lunch this past December 22nd, saying goodbye to friends and coworkers. That said, I am also excited for the new challenges that await. I will be a UX Developer at HP — starting Tuesday, January 4th.

It all came about unexpectedly, with a hypothetical “Want to work for HP?” question posed to me by fellow designer / developer Wynn Netherland, whom I know from being a guest on his podcast and through local Ruby meet-ups. Initially, I was poised to give the typical recruiter response: “Happy where I’m at, thanks” — but I figured I ought to at least hear him out, lest I snub a friend.

The more he told me, the more interesting it sounded: Doing heavy JavaScript work as a front-end developer on a Rails team, with occasional travel and in-office meetings, but for the most part a work-from-home gig. Technology and remote work environment aside, the premise sounded pretty darn cool, too.

Basically, the customers of the apps we’ll be building are “ourselves” so to speak, creating tools for other developers to manage their usage of HP’s forthcoming cloud computing service. From what I gather, this intrapreneurial venture is being incubated as part of HP Labs, to eventually become a full product offering.

Ultimately, to borrow a phrase from The Godfather — I was presented with an offer that I couldn’t refuse. I will probably post about the job from time to time as I get more accustomed to it, but I figured I ought to blog about it here to make it “official” since several people have been asking me about my updated LinkedIn profile, and why friends were saying goodbye to me on Twitter.

Formalize CSS

Nathan Smith — Sat, 16 Oct 2010 19:30:01 +0000

CSS

Formalize CSS | View demo | Download | GitHub repo

Formalize CSS — Dress up your forms!

Intro

As designers, we are used to having quite a bit of control over how things are displayed in a browser. Sure, differing rendering engines don’t always agree on everything, but for the most part we can at least find ways to mitigate variance through workarounds, or by writing for the lowest common denominator.

By far, one of the most frustrating parts of dealing with browser inconsistencies has got to be forms. There are two distinctively differing schools of thought regarding (not) styling form elements. For the longest time, we’ve had people on both sides of the proverbial fence, neither group being particularly pragmatic.

Some designers advocate styling form elements to match the brand of a site. Others would tell you to leave them alone entirely, so that they adhere to the native look and feel of a given operating system.

That’s all well and good, except most browsers don’t mesh completely when it comes to OS consistency. Some browsers use a monospace font for textarea, and OS X neglects to style the border of textarea the same as text input elements. So what’s a designer to do? It’s a conundrum, for sure.

I would say that I fall somewhere in the middle of the two camps.

My Solution

I want some measure of control over form elements, without changing them so drastically as to appear foreign in a user’s operating system. Thus, my quest to find a happy medium, where browsers would generally agree and let me keep my sanity. The result is what I’m simply referring to as Formalize CSS.

I’ve attempted to bridge the gap between various browsers and OS’s, taking the best ideas from each, and implementing what is possible across the board. For the most part, this means most textual form elements have a slight inset, and all buttons look consistent, including the button tag.

I have also added a few niceties. All browsers that support box-shadow — even those on Windows and Linux — now have a light blue :focus border, ala OS X. Also, via jQuery I’ve added support for the HTML5 placeholder and autofocus attributes, for browsers that don’t yet handle it natively.

I’ve left untouched the input types of range and file. As far as I’m concerned, they are the pariahs of form elements — inconsistent and stubbornly resistant to styling. For those browsers that do actually support range, it’s a slider, but for those that don’t, it’s a text box. I’ve left it alone, with the assumption that when all browsers eventually handle range, they’ll do so as some sort of slider.

Make it Yours

Note: In the demo pages, I have not applied any widths, so that you can see how browsers would natively handle the various form elements. For instance, Opera styles some elements (url, email, datetime, datetime-local) considerably wider than others, a quirk I’ve not seen in any other browsers.

I have included utility helper classes at the top of the formalize.css file, which can be sprinkled in to add set widths to the input and/or select tags, such as: input_tiny, input_small, input_medium, input_large, and input_full (100% width). Feel free to change these, or delete them entirely. They’re simply meant to be suggestions, to show how you can resize elements if need be.

Unlike a framework such as the 960 Grid System — which is intended to be written against, but not altered — in general, Formalize exists just to offer some guidance as to how you might approach form styling. Nothing is set in stone. If you want to adapt it to more uniquely suit your needs, go right ahead.

WebKit

I debated whether to leave <select> alone, since I rather like how it looks in WebKit (Safari + Chrome) on OS X. However, since it’s the “odd man out” so to speak, I went ahead and styled it to look consistent across all browsers. For what it’s worth, this is how it would’ve looked in Safari on Windows anyway.

I’ve managed to wrangle the search input under control in WebKit. This means that Safari and Chrome will render search the same as a text input, but you still get a recent search list, and clear/reset [x] functionality. In case you’re curious, these magic lines of CSS undo WebKit’s native rounded styling:

input[type="search"] {
  -webkit-appearance: none;
}

input[type="search"]::-webkit-search-decoration {
  display: none;
}

IE6 & IE7

I even went so far as to add extra classes via JavaScript as styling hooks for IE6, since it doesn’t recognize attribute selectors like input[type=text]. Oddly enough, this involved duplicating styles, rather than stacking IE6 class names, because the presence of an attribute selector in a comma separated list of elements will cause IE6 to ignore the style rules completely. For example…

.ie6_button {
  /* This works in IE6. */
}

.ie6_button,
input[type="submit"] {
  /* This doesn't work. */
}

Needless to say, if you do not need to support IE6 (hooray), feel free to delete the entire section in formalize.css that pertains to it, because all those styles are duplicated just for that one browser. Really, you ought to drop IE6 anyway.

Additionally, IE6 and IE7 have faux box-sizing support added for <textarea> and class="input_full", so they can go to 100% width, and still have border and side padding applied. You can read more about box-sizing at CSS Tricks.

Thanks

Several people helped me make Formalize what it is. Namely, Anthony Short for pointing out that search is indeed conquerable in WebKit, and Chris Coyier for a tip on how to style the color of placeholder text. Additionally, thanks to Jonathan Snook for taking a screenshot in IE6 on Windows XP for me (just to double check IETester), and to John Saddington for snapping a shot on his iPhone 4.

Screenshots

Note: Formalize’s buttons differ slightly from these screenshots (now less round).

If you’re curious how things look in various browsers and operating systems, check out the attached screenshots. I have to say that while Opera takes the cake as far as raw functionality, it also sports the ugliest looking styles for some of the newer HTML5 form elements, the worst offender being datetime.

Why Drupal?

Nathan Smith — Thu, 05 Aug 2010 07:15:11 +0000

Content Management

Lately I’ve been asked in several different ways what essentially boils down to one question: “Why Drupal?” The subtext of the question is: “Why not some other system such as [insert your favorite CMS here]?” Allow me to explain…

Background

If you are familiar with the history of my site, you’ll know that once upon a time it ran on Textpattern, a designer friendly content management system that sports a templating system akin to the syntax of XHTML. I was so enamored with TXP, as the cool kids call it, that I even pushed forth an effort to write a book about it. Several coauthors and I labored on what became Textpattern Solutions.

Again, depending on how long you’ve known me, you might also recall that last year I built a proof of concept module for the ExpressionEngine CMS to consume the Fellowship One API. I even took the time to make a brief screencast.

Like many designers, I was impressed with the EE 2.0 admin interface demo’d at the SXSW conference a few years ago. At the time, the core version of EE was free for nonprofits. It seemed like a good system to encourage for church use. We even chose EE to power our Fellowship Tech Developer site.

Ironically, after presenting my EE module talk at the Dynamic Church Conference in 2009, the first responses were basically “What about Drupal?” As it turns out, many of our church customers are big proponents of open source.

At the time, I knew next to nothing about Drupal, but this spurred my curiosity. I knew that it could power large sites, and that the Geeks & God podcast guys loved it, but I didn’t really know much more than that. Coincidentally, 2009 was when interest began to pick up in the Drupal community around using 960.gs as a base for building themes. I was encouraged by Matt Farina to speak at the first ever Design 4 Drupal event in Boston, hosted by MIT. I ended up co-presenting with Todd Neinkerk of the Austin based agency Four Kitchens – video here.

It was there at the MIT Stata Center that I was immersed in the culture of Drupal for three days, and I began to see what all the fuss was about. The designers and developers I met were highly collaborative, eager to both teach and learn.

It should be noted that I have also attended a TYPO3 conference in Dallas, and found it to have a unique culture all its own. My friend Ron Hall is a huge fan of TYPO3, and helps to organize their North American conference. For whatever reason, TYPO3 is decidedly more popular in Europe, particularly in Germany.

Deep Dive

I have never been the type of person to purchase things on a whim. If anything, I tend to research products to a fault, spending weeks or months reading up on a particular topic. If memory serves, I have read four books on Drupal, three on EE and/or CodeIgniter, and two on TYPO3. Those books are…

Drupal

ExpressionEngine

TYPO3

Bonus: I also have on my bookshelf The Definitive Guide to Django.

Okay, maybe I am the type of person who purchases books on a whim!

Why Change?

Textpattern

So anyway, believe me when I say I like to have an informed opinion. The big question is: What made me leave Textpattern, after pouring in so many hours learning the system, and even more writing a book? I can say with all honesty, it was a “It’s not you, it’s me” situation. At some point, I realized that I had sort of tapped out the upper limits of what I knew how to build with Textpattern.

ExpressionEngine

So I began looking elsewhere. First I checked out EE, learning the ins and outs of how it handles layouts and modules. The way it works is not unlike how TXP does templates. I was intrigued by that possibility, coupled with things like their 1st party developed forum and member management modules.

But as we fleshed out the FT Developer site, I realized these modules (in 1.6.x) did not work like the rest of the system. Instead, it involved hacking away at heredoc strings. Elegance lost, if one was to build sites beyond what TXP could handle. Also, EE sent down headers to the browser before module code was output.

This meant we had a heck of a time getting OAuth to work. This is why no further development was done on our proof of concept EE module. That, and the change in EE 2.0’s licensing that does not allow for nonprofit usage free of charge.

Again, none of this is a fault of the CMS. EE is fine for what it’s meant to do.

TYPO3

Unlike TXP or EE, TYPO3 really shines as an application development platform and CMS hybrid. But it can be somewhat daunting just to get installed and configured correctly. Thankfully, there are efforts like the Web Empowered Church project helping to ease the learning curve, by providing users with guidance and starter templates. For me, what scared me off about TYPO3 was having to learn yet another pseudo syntax after having learned EE and TXP’s respective tags.

I came across this article…

— TYPO3 Wizard: Copyright Notice with Current Year

I remembered thinking: That’s a lot of steps. In PHP, it’s just one line…

<?= date('Y') ?>

It’s ironic that I was initially drawn to Textpattern because of it’s pseudo syntax, and because PHP seemed intimidating. Now I feel like an old man who can’t be bothered to learn a faux language, preferring instead to write straight PHP.

At this point in my career, investing time to learn something that only works within the confines of a particular CMS could be likened to learning Klingon. Yes, technically it’s a language. Yes, there are extremely zealous groups of people that are fluent in it. But outside of that “universe,” all that knowledge is no longer applicable. It’s tantamount to memorizing answers in Trivial Pursuit.

Learning PHP is like learning Spanish. Or English. Or some widely spoken language that will benefit you in more than just niche circles. PHP on the web is like white paint. It’s everywhere. It might not be as pretty as Ruby or as puristic as Python, but as a developer it is worth having at least a working knowledge of PHP.

Even 37signals, creators of Rails, used PHP for their book Getting Real.

What about WP?

I see this old debate flare up from time to time. Some say…

“WordPress is not a CMS. It’s just a blogging tool.”

Others rebut…

“Blog posts are content. WP manages blog posts. Ergo, it’s a CMS.”

Well, call it whatever you want but WordPress is not for me. Yes I know that it’s wildly popular. A quick comparison on Google Trends shows that the number of searches for WordPress easily outnumber those for Drupal related topics, by a staggering 10-to-3 ratio. So then, why not WordPress? Am I leaving money on the table by not listing WP theme development in my repertoire? Yes and no.

Commercial blog theme design is a saturated market for good reason. It’s not terribly difficult. In fact, I’d venture to say if I were in that line of work, I’d find it downright monotonous. While there is no limit to the level of visual detail one can incorporate into a blog design, the functionality only goes so far.

Blogging goes like this: Write a post. Upload a photo. Maybe a video. Or do a podcast. Let people comment on any or all of these content entries. Rinse, repeat. As designers, we’ve have become quite adept at cranking out themes to accomodate these basic user behaviors. This is where WordPress excels.

In fact, WP is so tailored to blogging that I liken it to a yacht. It is streamlined for that particular task. It allows people with varying levels of technical savvy to get a site installed and online posthaste. Or, via WordPress.com you can skip the install process altogether and opt for a hosted blog. While a sharp focus on blogging ensures that the famed “5 minute install” will continue to be a selling point, it also means that WP at its core isn’t meant for big sites.

Note: I mean “big” from an information architecture standpoint. I realize that with proper caching plugins and a good hosting setup WP can power sites with tons of traffic and an abundance of blog posts. While that’s all well and good, I’m interested in building sites and/or web applications that have both breadth and depth.

Continuing with the WP as yacht analogy, I’d say Drupal is an aircraft carrier. A ship that big can carry fighters, bombers, supplies, or even refugees in a humanitarian relief effort. What I see far too often is people trying to strap things onto their yachts and then wondering why they run into difficulties. Custom fields do not make for an ideal CMS workflow. I learned this with Textpattern.

Scope

At it’s core, Drupal is built for scalability. You can use it like I am on this site: humble blog, about section with sub-sections, portfolio, contact page, etc. It is also versatile enough to power sites like: Department of Commerce, Duke University, The Economist, Fast Company, UN Global Pulse, and The White House.

An extensive list of high profile Drupal sites is maintained by Dries Buytaert, creator of Drupal. While I’m on the topic: Dries is an extremely smart guy. He holds bachelor, master, and doctoral degrees in computer science. He cofounded Acquia, which focuses on providing enterprise level infrastructure and support for large Drupal sites. They are for Drupal what Red Hat is to Linux.

My reasoning for learning Drupal, when TXP was meeting the needs of my former site just fine, is that I want to constantly be pushing myself to learn more, and to increase the capacity of what I am able to build. I’m not one to seek out complexity just for kicks, like some Bloomberg pundit. I do enjoy taking something that otherwise might be complex, and breaking it down into digestible pieces.

Or, as the saying goes…

Q: How do you eat an elephant?
A: One bite at a time!

This is something Drupal allows me to do: Create hierarchical structures of content, helping to organize things so that users are able to find them presented logically. Though I know I’m not using it to its fullest on my simple site, I have peace of mind knowing that I’ve invested time in a system that can grow with a client’s needs. I can say with impunity: “Yeah, Drupal can do that.”

I think the ability to handle large scale websites is why you see Drupal agencies that employ anywhere from a handful to several dozen people, whereas people who build custom or commercial blog templates usually operate in smaller groups or as independent freelancers. The size of site dictates the manpower.

I keep an eye on these powerhouse Drupal agencies…

I am consistently impressed to see Development Seed building robust applications such as Managing News, MapBox, and Open Atrium atop Drupal. I also listen semi regularly to the Lullabot podcast hosted by founder Jeff Robbins, sometimes referred to as the “voice of Drupal” in the community. Lullabot was one of the first agencies to offer Drupal training, even before it was in vogue. They also have an extensive library of instructional videos covering a variety of Drupal topics.

So What?

What am I trying to convince you of? Nothing really. I just figured that since I am asked Why Drupal with increasing frequency, I should probably record my thoughts. If I’ve convinced you to try Drupal, great. If not, that’s fine too.

I used to feel a burden for my designer friends when I’d see them spinning their wheels, making yet another blog theme, for yet another client that wanted his/her blog to be the coolest thing ever. I would wonder about such friends: “Why do they paint themselves into a corner, just using a blogging tool? Don’t they know it won’t scale well as a CMS?” As I’ve grown older, and arguably wiser, I’ve learned not to worry about such things. Some people want to build blogs, and can make a decent living doing so. More power to ‘em.

Personally, I find myself yearning for more than re-skinning the same functionality. That’s partly why I love working for a company that builds web applications. I want to solve complex problems with simple solutions. When I do build sites, I want a CMS that meshes with my philosophy. For me, that means Drupal.