The Tude Abides

Emergent Task Planner

2012-12-19T11:11:00-05:00

For a few years now I’ve used David Seah’s excellent Printable CEO resources, to keep track of my activity across projects. I stopped doing it a while back for some reason, but recently rediscovered them, and decided they deserved a mention, particularly the Emergent Task Planner(ETP).

The ETP really is great to use, and the pads you can buy from Amazon are of extremely high quality. What I like most is how much it reduces the friction of plotting how I’ve spent my day. It’s dead simple to just pick up and start using. I have found the ETP to be an invaluable asset for logging of how I spend my time between different projects.

A word of caution: the ScanTron-phobic among us may wish to look elsewhere for suitable productivity tools, as the filling in of little ovals features prominently in these. But for the frictionless capturing of task-based information in the moment, I haven’t found anything else that works nearly as well for me.

Year In Review

2012-12-17T23:05:00-05:00

It has been a very busy year for my family and me. I suppose this post is something of an excuse for the lack of updates to this blog, so enjoy the rambling stream of consciousness below. I have no agenda here, other than to briefly recall the year’s highlights.

So 2012 happened. In the offing, I have been blessed to see my son William turn 3, and my marriage to Sarah turn 7. This year saw me turn 5 times the age of my marriage. Sarah and I sold our first home together and moved to our second.

Sarah participated in a 2-day watercolor workshop put on by PAFA. She had a great time, and came home full of inspiration for future art projects. Her paintings look fabulous.

My father is retiring this year, after 35 years of teaching and conducting research at the same university, which also happens to be my alma mater. It really is amazing to me how anyone can stay at one place for so long – literally my whole lifetime. He’s always been my inspiration, and I owe so much to him and Mom that I haven’t the words to express my full gratitude. I’m just proud to be their son.

I still play board games as often as I’m able, which isn’t a lot, but though the quantity of my playing has diminished, I feel the quality has increased – I’m more selective about my gaming experiences these days, as my time is a more precious commodity than it once was. I’ve been fortunate to make a number of dear friends through this misunderstood hobby.

This year also saw my first foray into the world of pencil-and-paper role-playing games. Some friends and I started a basic Pathfinder campaign. I find it pretty interesting and fun, though I’m still learning the ropes. I went with a pretty straightforward character since I’m new at it.

Professionally, I volunteered twice to be a TA for web development classes at GDI Philly. The first was for server-side programming with Node.js, and the second was an intermediate HTML & CSS class.

I am as much of a fan of Vim now as I ever was. I’m writing this post in Vim right now.

At my day job, I managed to get my fingers into an awful lot of different pies – heres a recap of the busy year I had at work:

Q1

Wrapped up my involvement leading front-end development for the brand-new redesign of the American Red Cross website, which eventually went on to a successful launch in September of this year. I’d been on the project since the kickoff in March 2011. If you donated to Hurricane Sandy victims this year, you likely used code that I wrote.

Q2

Built a revolutionary JavaScript proof-of-concept app with my talented co-worker at the time, Vick Aita. The proof-of-concept won my company the contract to develop the full application for the client. This work had me making several trips out to California, and one trip to Belgium.

Q3

My company kicked off 3 simultaneous responsive web design projects for customers in the media & entertainment space, and I was tapped to work across the projects with each team so that they could deliver consistently high-quality solutions.

Q4

As I continued to oversee our responsive web design development efforts, my focus shifted to some pressing departmental needs, such as documenting clearer development guidelines for our team, and helping to start a framework/pattern library of reusable components for future projects. I continued to support various client projects as the need arose. Toward the end of the year, I reunited with the aforementioned JS project from Q2, which is now in full development with a dedicated team.

May you all have a wonderful ending to 2012, and an equally promising beginning to 2013!

Developers Are Artists

2012-10-07T11:53:00-04:00

Software development is, in part, an artistic practice. As a developer, your brush is a keyboard; your canvas, a text editor. You derive satisfaction from crafting solutions to real problems, and it is your creativity that brings the solutions to life.

Beautiful Code

Development is necessarily a balancing act of competing concerns:

Performance
Scalability
Maintainability
Usability
Accessibility
Beauty

Yes, we care very much about beauty in our code, but unlike most other concerns, it is subjective by nature. Beauty is very much in the eye of the beholder.

Teaching how to design beautiful code is as challenging as teaching “the practice of software development.” Each of us is left to ourselves to figure it out, either by following the example of others, or stumbling upon it ourselves in a blinding aura of caffeine-induced revelation. More often than not, at least in my experience, it’s the former.

So… Artists?

As tempting as it is to draw upon the analogy of being “underappreciated in our time,” it is noteworthy that developers often experience a similar creative arc as artists of other disciplines. A great deal of code makes its initial appearance as a “s****y first draft,” to quote Anne LaMott. Before that, it may even have begun its life as a simple whiteboard doodle. Eventually, we revise and refactor that first idea as we gain a fuller understanding of the problem, and the best code eventually emerges. More often than not, it also happens to be more elegant code, the rough edges having been smoothed out, and the redundancy reduced. If all goes well, the developer can put down her brush at this point and take a step back to take in the full scope of her work.

$break-small: 320px;
$break-large: 1024px;

@mixin respond-to($media) {
  @if $media == handhelds {
    @media only screen and (max-width: $break-small) { @content; }
  }
  @else if $media == medium-screens {
    @media only screen and (min-width: $break-small + 1) and (max-width: $break-large - 1) { @content; }
  }
  @else if $media == wide-screens {
    @media only screen and (min-width: $break-large) { @content; }
  }
}

.profile-pic {
  float: left;
  width: 250px;
  @include respond-to(handhelds) { width: 100% ;}
  @include respond-to(medium-screens) { width: 125px; }
  @include respond-to(wide-screens) { float: none; }
}

In the example above (from The Sass Way), the respond-to Sass mixin provides a more attractive way to specify @media queries in CSS, abstracting away some of the ugliness for the author. Obviously, abstraction isn’t always the best course of action, but oftentimes the biggest reason for doing it is to end up with a cleaner codebase.

Beauty often takes care of itself.

We must remember that beauty in code is a means, not an end, to our satisfaction in development work. Most of us provide our services for hire. In practical terms, each of those other competing concerns has a real link to business value, and will tend to trump “beauty” when the two are in conflict. However, I find that if everything else properly accounted for, beauty will often take care of itself in the process.

We’ve been talking about this for a while now.

2007 – O’Reilly publishes the book Beautiful Code, a collection of essays by notable members of the profession on how they approach programming problems in ways they deem beautiful.
2008 – Jeff Atwood proclaims that Code Isn’t Beautiful in reaction to O’Reilly’s book, finding beauty not in the code itself, but in the ideas and algorithms beneath the surface.
2009 – Chris Coyier describes What Beautiful HTML Code Looks Like, focusing on how beauty in HTML is derived from craftsmanship.
2010 – Martin van Emden argues In Defense of Beautiful Code, demonstrating that there are ways to write the same code that are more beautiful than others.
2011 – Alberto Gutierrez discusses The Obsession With Beautiful Code, underscoring the dangers of pursuing beauty for beauty’s sake.

Gutierrez’ post particularly resonates with me, despite its being the least complementary to my point of view, because I have observed many of the tendencies he lists in myself as well as in many of my peers. Developers need to be aware that subjective coding style can be conflated with beauty on occasion, and it often has little to do with code quality. However, I do take issue with his claim that all code is crap.

While it is true that much of what we work on is, at best, ephemeral even if it does end up seeing the light of day, what we gain in experience will stay with us for future opportunities to create beautiful code.

KSS and Middleman

2012-01-10T15:11:00-05:00

I love the idea of building an “interactive style guide” for a website design. I really do. However, working in Agencyland, it can be extremely difficult to budget enough time for this kind of tool when seemingly higher-priority tasks pile up. Right or wrong, the utopian vision of a living style guide often becomes a foregone luxury in the throes of looming deadlines.

Assumes the reader understands the basics of Ruby and CSS.

Middleman

For an upcoming project at work, I’ll be leading the effort to author static HTML templates for a different group of software integrators to wire up to a complex back-end architecture (rhymes with Shmeb-shmere).

We are also going to be building a whole front-end stack with CSS and JavaScript to boot, so it makes sense to use a solid static framework to take the pain away from developing a massive amount of templates without any server-side help. The bottom line is that we need to be able to export flat HTML files that work the same as the development templates.

Enter Middleman, a loosely-coupled, yet carefully curated collection of Ruby libraries that all contribute to a framework that is much greater than the sum of its parts. I won’t go into all of its features here — you can visit the Middleman site for everything you need to know.

For our purposes, Middleman looks to be a robust platform on which to build our static site.

KSS

I am a closet fan of documentation specs like RubyDoc and JSDoc, but they often introduce a lot of heavy baggage for developers. TomDoc came on the scene not too long ago as a really simple doc spec that Githubbers use in their in-house Ruby code, and I was ecstatic when another Github guy, Kyle Neath, released his own KSS project in late 2011. I think I’ve subconsciously been yearning for this kind of CSS documentation support for some time.

KSS is a documentation spec for CSS (one of the first of its kind that I’ve heard of) that can be parsed by Ruby. This helps us do things like… generating an interactive style guide. It’s certainly not a silver bullet, but KSS will lower some of the administrative barriers to putting together helpful CSS documentation.

KSS-ing Middleman

I thought it would be a good idea to try to port some of the KSS example app code over to my basic Middleman app. The example shows several variations of form submit button styles, including states such as hover and disabled, which makes for an excellent use case.

The Styles

I’m using Sass and Compass, with Middleman, so I did a quick port of Kyle’s example button CSS to Sass with some appropriate Compass mixins. I found that KSS broke when used with the original terse Sass format, but it did work fine with the newer SCSS format. I’m not certain, but it’s possible that this issue may be resolved in KSS in the future.

Below is the result of porting the button CSS to _button.scss. The comment block at the top is where the documentation magic happens. You just describe what something is, specify a list of different states, and then reference a numbered section of the style guide. That’s it.

// Your standard form button.
//
// :hover    - Highlights when hovering.
// :disabled - Dims the button when disabled.
// .primary  - Indicates button is the primary action.
// .smaller  - A smaller button
//
// Styleguide 5.1.1
button {
  background-color: #f5f5f5;
  @include background-image(linear-gradient(#f5f5f5, #e5e5e5));
  border: 1px solid #ddd;
  border-bottom-color: #bbb;
  @include border-radius(3px);
  @include box-shadow(0 1px 4px rgba(0, 0, 0, 0.15));
  color: #666;
  cursor: pointer;
  font-family: "Helvetica Neue", Helvetica;
  font-size: 12px;
  font-weight: bold;
  line-height: normal;
  padding: 5px 15px;
  @include text-shadow(0 1px rgba(255, 255, 255, 0.9));

  &.primary, &.primary:hover {
    color: #fff;
    background-color: #8add6d;
    @include background-image(linear-gradient(#8add6d, #60b044));
    border-color: #74bb5a;
    border-bottom-color: #509338;
    @include box-shadow(0 1px 4px rgba(0, 0, 0, 0.2));
    @include text-shadow(0 -1px 0 rgba(0, 0, 0, 0.4));
  }
  &.smaller {
    font-size: 11px;
    padding: 4px 7px;
  }
  &:hover {
    color: #337797;
    background-color: #f0f7fa;
    @include background-image(linear-gradient(#f0f7fa, #d8eaf2));
    border-color: #cbe3ee;
    border-bottom-color: #97c7dd;
  }
  &:disabled {
    opacity: 0.5;
  }
}

You actually do need to manage the numeric structure of the style guide yourself. However, I appreciate that KSS makes you maintain control over the meaningful aspects of organizing a style guide, while making it possible to automate the tedious parts.

The Config

For the style guide to look nice on the front end, there is also a small amount of boilerplate CSS and JavaScript code to make some of the magic happen, so I pulled those files in and called them from a separate layout, layouts/styleguide.erb.

The KSS example app runs on Sinatra, and Middleman also basically runs on Sinatra with some abstractions on top, so setting up the configuration wasn’t too tough. After adding gem "kss", "~> 0.1.1" to the Gemfile and running bundle install, I added the following to Middleman’s config.rb file:

require "kss"
page "/styleguide/*", :layout => :styleguide do
  @styleguide = Kss::Parser.new('source/css')
end

helpers do
  # Generates a styleguide block.
  def styleguide_block(section, &block)
    @section = @styleguide.section(section)
    @example_html = kss_capture{ block.call }
    @_out_buf << partial('styleguide/block')
  end

  # Captures the result of a block within an erb template without spitting it
  # to the output buffer.
  def kss_capture(&block)
    out, @_out_buf = @_out_buf, ""
    yield
    @_out_buf
  ensure
    @_out_buf = out
  end
end

For all style guide templates, the above configuration exposes a variable containing a Ruby representation of all KSS-documented CSS in the site (because KSS parses all documentation blocks in the CSS). A couple of helpers are defined that the templates will have access to, in order to handle the generated style guide block.

Due to a bug in Middleman 3.0 beta, wildcard file paths did not set local variables correctly. This bug should be resolved in 3.0 final. Additionally, I suspect that the kss_capture helper is not exactly optimal for use with Middleman, but I haven’t taken the time to refactor the example code beyond simply getting it working. It was originally named capture in the example, but I renamed it to prevent conflicts with the existing Middleman capture helper, which I would have probably tried to use if it was available inside the config file.

The Templates

A partial template needs to be defined for rendering every style guide section. The template will be used by the styleguide_block helper defined in the config above: styleguide/_block.erb.

<div class="styleguide-example">

  <h3><%= @section.section %> <em><%= @section.filename %></em></h3>
  <div class="styleguide-description">
    <p><%= @section.description %></p>
    <% if @section.modifiers.any? %>
      <ul class="styleguide-modifier">
        <% @section.modifiers.each do |modifier| %>
          <li><strong><%= modifier.name %></strong> - <%= modifier.description %></li>
        <% end %>
      </ul>
    <% end %>
  </div>
  <div class="styleguide-element">
    <%= @example_html %>
  </div>
  <% @section.modifiers.each do |modifier| %>
    <div class="styleguide-element styleguide-modifier">
      <span class="styleguide-modifier-name"><%= modifier.name %></span>
      <%= @example_html.sub('$modifier_class', " #{modifier.class_name}") %>
    </div>
  <% end %>

</div>

In styleguide/buttons.html.erb, I added the following template call:

<% styleguide_block '5.1.1' do %>
  <button class="$modifier_class">Default Button</button>
<% end %>

Note that there is a single button element in the block. This is where the magic happens, because it passes the button to styleguide_block, which imports the styleguide/block partial for the style guide section.

The partial parses the KSS representation of the documented CSS for the given section of the style guide (5.1.1). It prints out the section number and SCSS filename, adds the documentation text to the page, cycles through each CSS modifier of button, and generates a new <button> tag for each modifier. The resulting section of the style guide will look like this:

The original basic button element is listed first, followed by accurate examples of all of its documented modifiers. The KSS JavaScript file fakes the pseudo-selectors :hover and :disabled.

Onward

For my project, at least, this is an encouraging proof-of-concept that I plan to take forward. In the meantime, it looks like there is a generous amount of potential in both Middleman and KSS, so be sure to check out each of these projects.

If you have used either Middleman or KSS, what has your experience been like thus far?

Update 2012-02-04

I have pushed my working code to a Github repo. Some of the gems are a little out of date, but I wanted to get my initial version up first, and then work through any issues that might arise from updating libraries. Please let me know what you think; I’m always open to suggestions for improvement.

After checking out the code, just run middleman like any other Middleman app, and browse to http://localhost:4567.

10 Vim Techniques for Novices

2011-08-04T08:37:00-04:00

Since I switched to Vim as my primary editor back in March of this year, I have discovered a wealth of useful tricks that help me get things done. Most of these techniques are truly indispensible, and should find a place in any Vim user’s quiver.

I should also note that at this time, I’m nowhere near expert-level in my Vim abilities, so this post is intended to share some commands, patterns, and configurations with other Vim users who are still getting their feet wet with the editor. Experienced Vimmers will already know all this stuff, and more power to them. This is for the Vim n00bs out there.

1. Open with Cursor at Last Edit Position

This one isn’t so much a technique as it is a preference. If you make a change to a file, and then re-open it later, the following snippet in your .vimrc will position the cursor at the last spot you made an edit prior to closing the buffer or Vim itself:

autocmd BufReadPost *
\ if line("'\"") > 0 && line("'\"") <= line("$") |
\   exe "normal! g`\"" |
\ endif

2. Visual Block Mode

You might know about Visual mode v, and even Visual Line mode V, but do you know about Visual Block mode? You can enter it with ^v (that’s CTRL-v), and then use Vim movement commands to select text in a box of columns and rows, rather than by lines. This can allow you to make some really powerful edits.

Other editors, such as TextMate, can perform a similar blockwise selection using the Alt/Option key. Well, MacVim can do the same thing. Hold down Alt or Option, and click/drag with the mouse. I want to caution you against relying on this too much, though. Vim is designed to reward you for keeping your fingers on the keys as much as possible.

3. Quick Letter Swap

If I accidentally type “teh” instead of “the”, the natural reaction would be to go back, select those two letters, and retype them, but there’s a simple way to swap any two adjacent letters:

Move the cursor to the first letter of the swapped pair (in this example, the “e” of “teh”) and type xp. This cuts the character the cursor is on, and immediately pastes it after the next.

4. Repeat Last Edit (the magic dot)

The glorious . is a very powerful command, and probably my most-often used in this list. Typing . in normal mode repeats your most recent edit. It’s dead simple to use, and just plain awesome in so many contexts.

5. Move and Edit by Text Object

At the root of Vim’s idiosyncratic design is a variety of ways to easily move around a text file and edit it effortlessly:

w and b move the cursor forward and backward by word.
( and ) move the cursor forward and backward by sentence.
{ and } move the cursor forward and backward by paragraph.

You can combine text objects with counts and actions to perform very powerful, concise edits.

One of my favorite commands is ciw, and the pnemonic for it is Change Inside Word. If I can get my cursor anywhere in a word, it doesn’t matter which character it’s on, a quick ciw will cut the whole word and change to insert mode so I can enter new text in its place. No awkward text selection or repetitive deletion keying. Just ciw and type the new word.

6. Delete, Yank, and Paste a Line

dd will “delete” a line, which is the same as cut.
yy will “yank” a line, which is the same as copy.
p will paste at the line below the cursor.
P or SHIFT-p will paste at the line above the cursor.

Any of these commands can be preceded by a numeric count: 10p will paste 10 times.

7. Easy Repeated Characters

Say I am working in Markdown format – which I often am; these blog posts are is written that way – and I want to use an underline-style H2:

This is my heading
==================

I would prefer not to have to type who-knows-how-many equals signs in a row. How annoying. Luckily, something like this is dead simple in Vim.

After typing your header, exit to normal mode and, with your cursor still on the line, type yyp to duplicate the line. The text now looks like this:

This is my heading
This is my heading

At this point, your cursor should on the first character of the second line. Type v$r= to visually select the text to the end of the line, and replace all the characters with equals signs. That’s it: the full command is yypv$r=

Update: Honza Pokorny pointed out a shorter alternative to this command: YpVr=

Update 2: Santosh Kumar observed that V may not be able to replace v$ in every situation, particularly if there is whitespace at the beginning of the line.

If you ever just want 80 stars in a row, say, to section off a part of source code, you could just type 80i*<Esc> – easy.

8. Quick Find

/ will switch to a mode that allows you to enter a search string for the current buffer. If you have the proper settings in your .vimrc,

Vim will even do an incremental search. When you have the search term you want, hit <Enter> and cycle forward through the search results in the buffer with n, and backwards with N.

? does the same thing as /, only in the reverse direction. You can also use * to quick-search the word your cursor is currently on.

For some sane defaults, here are some of my .vimrc search settings:

set hlsearch   " Highlight search matches
set incsearch  " Highlight matches as you type
set ignorecase " Case-insensitive searching
set smartcase  " ...but case-sensitive if expression has caps
set wrapscan   " Set the search scan to wrap around the file

" Press space bar to turn off search highlighting
" and clear any message displayed
nnoremap <silent> <Space> :nohl<Bar>:echo<CR>

9. Search & Replace in a Buffer

Few of us can really consider ourselves experts with regular expressions, but if you have ever used them for any kind of text processing task, you realize how incredibly powerful (and yes, sometimes befuddling) they can be. Regexes are used in Vim’s native search and replace.

It is necessary to specify a range when doing a search and replace, and generally, you will want the action to be global, so you would type :%s/pattern/replacement/g and hit <Enter>. Done. The % represents the entire buffer, while the s///g structure is the standard search and replace command syntax.

To search/replace within a given selection, first select your desired range in visual mode, then hit :. Vim will pre-fill your range as '<,'>, which means the current selection. Use the same s///g syntax as before to restrict the action to the selection you specified.

The trailing /g? That’s an option that I usually like to pass, as it tells Vim to replace all matches, not just the first one.

10. Project Search & Replace

It’s a common complaint: project search & replace – an operation that spans one or more files – is one of the few glaring weaknesses of Vim. Until there is better support for this feature in Vim itself, it is possible to pull off in an unorthodox way: don’t use Vim! Try this on for size (from the command line):

$ sed -i 's/pattern/replacement/' <files>

From within Vim, while in : command mode, you can use the same command, only beginning with a !. This pipes the command directly to a shell session and does the business. Note the relative consistency of sed’s search & replace syntax with Vim’s native one.

Passing commands from Vim to external programs is common, and often encouraged. Select some text and run the :sort command on it sometime – it actually calls the external sort program, which passes the sorted lines back to Vim.

My dotvim

I wouldn’t consider my Vim configuration to be anything special, but it’s mine, and I am always tweaking it (you Vim people know what I’m talking about). If you are curious about what I might have in there, you can feel free have a look at it – it’s on GitHub, of course, and all the plugins are set up as Git submodules with Pathogen.

Dive into Vim!

The nuts and bolts of how to use Vim are, of course, outside the scope of this article. VimCasts, PeepCode, and Vim’s built-in tutorial are at your disposal. That being said, I’m willing to attempt to answer most questions you might have about Vim, either on Twitter or via the comments.

OOCSS, For Great Justice

2011-07-17T13:55:00-04:00

In my previous post, I hinted at a growing concern with CSS performance. Among those pioneering ways to approach the issue of maintainable-yet-efficient CSS is Nicole Sullivan, who is perhaps best known for her open source Object-Oriented CSS project.

Object-Oriented? CSS?

I have to admit that when I first checked out out OOCSS, I guffawed. While it’s true that, at first blush, CSS does not have many of the traditional features of a genuine OO programming language, Nicole has been exploring ways in which CSS’ inheritance/cascade can be analogous to OO concepts.

It’s taken me quite some time to come around. There are things in the OOCSS code base that seem to fly in the face of commonly-accepted CSS best practices. It is precisely this kind of resistance in the community that must have prompted Nicole to deliver her latest talk this year at Webstock, entitled Our Best Practices Are Killing Us (slides).

Semantics Pitfall

For the past several years, I have been painstakingly crafting HTML and CSS under the banner of “best practices.” Currently, one such practice has been to aggressively scope CSS by content type.

Martin Sutherland describes this approach better and more succinctly than I could, but just recently recanted in favor of OOCSS. Martin had watched Nicole’s talk, and it appears to have had the same effect on him as it had on me. He writes:

One of the hardest hurdles to leap in coming to like OOCSS was the
somewhat heretical notion of adding “non-semantic” container elements
and apparently “presentational” classnames to my HTML.
Martin Sutherland www.sunpig.com/martin/archives/…

Martin goes on to propose (and I think he’s right on target here) that there are multiple layers of semantics that belong in HTML:

Structural semantics (core HTML elements)
Ontological semantics (domain-specific meaning beyond core HTML)
Visual semantics (representing visual intent)

Lest we forget, one of the core purposes of CSS is to communicate the visual semantics of an HTML document. Many developers, myself included, have written many projects’ worth of CSS that attempts to use only core HTML (structural) and domain-specific (ontological) semantics, while sidestepping the role that visual semantics ought to play, out of fear that we’d be introducing the ultimate evil into our source code, presentational classnames.

It is becoming more clear to me that we should not avoid the question of visual semantics in our CSS. The result of our having done so is visual style that is tightly bound to the content.

Now, hearken back to the primitive days of yore when it was commonplace (and accepted) to see <font>, <u>, and <center> tags in HTML source. It’s another example of presentation coupled with content, only in a more obviously wrong form.

Is the intertwining of visual style and content not one of the problems, nay, the problem, that CSS was intended to address in the first place?

It seems to me that many of us are doing it wrong when we refuse to implement some level of visual semantics in our CSS and HTML. Because of the belief that we’re following “best practices,” we are robbing ourselves of opportunities to abstract out common styles into reusable patterns, and our projects suffer for it.

For Great Justice

I’ve watched as some developers have begun to wrestle with the concepts of OOCSS vs. what we have come to know as the industry standard practice of writing CSS in recent years.

Watch Nicole’s OOCSS talks, and allow them ample time to marinate. Check out the source of the OOCSS project. I’m still in process myself, as I continue to look for ways to strike the delicate balance between appropriate visual semantics in CSS and blatantly presentational naming.

Not everything in OOCSS is a great idea to implement verbatim. Remember that it is proof of concept and a collection of patterns, not a CSS boilerplate. I am still mildly horrified every time I see how <b> tags are used for rounded corners in the module example, but I remind myself that the concepts are what make up OOCSS, not the specific implementation of the examples.

Finally, I have linked to Martin’s article on OOCSS in several places throughout this post. It really is required reading if you author CSS as part of your day job.

DNS Fail

2011-07-10T14:54:00-04:00

To those who tried to visit this site only to get a 404 error in the last 24 hours, I apologize. I believe DNS propagation was the culprit, and I jumped the gun by announcing that my post was up. I was able to view stephentudor.com just fine, but quickly found that several people, including my lovely wife, could not even get to the site initially.

By this time, it appears that most folks have been able to access it. If you can see this post, you’re fine. Otherwise, you’re probably in the camp that is left wondering why this joker posted a 404 URL to Twitter.

Again, mea culpa. I’ll know better next time :)

Responsible Sass Authoring

2011-07-09T13:04:00-04:00

In capable hands, Sass can do amazing things for your CSS. With Sass, you can use functions and variables that later get compiled into valid CSS. This can greatly reduce code repetition and the potential for mistakes.

For example, not that you would, but you could write some Sass like this:

(example-1.sass) download

// Set a couple of vars
$titleColor: #000
$titleSize: 24px

.article
  .title
    color: $titleColor
    font-size: $titleSize
  .alt-title
    @extend .title
    border-bottom: 1px solid lighten($titleColor, 80%)    // #ccc
    color: transparentize(lighten($titleColor, 20%), 0.1)
  .sub-title
    @extend .title
    font-size: round($titleSize * 0.85)    // 20.4px
    &:hover
      background-color: transparentize(change-color($titleColor, $red: 255), 0.8);

The resulting CSS might look something like this, depending upon how you set your Sass output style preference:

(example-1.css) download

.article .title,
.article .alt-title,
.article .sub-title {
    color: #000;
    font-size: 24px;
}
.article .alt-title {
    border-bottom: 1px solid #cccccc;
    color: rgba(51, 51, 51, 0.9);
}
.article .sub-title {
    font-size: 20px;
}
.article .sub-title:hover {
    background-color: rgba(255, 0, 0, 0.2);
}

Pretty cool, right? You can see that the @extend keyword can be a very powerful tool, bringing a quasi-object-oriented paradigm to our CSS. The same could be true for the nested selectors; you just have to refer to .article once, and let the indentation take care of the scope for you.

CSS Bloat

Over a year of using Sass every day at my day job has taught me this: Just because Sass allows you to do something, doesn’t mean it should be done.

Sass clearly offers many ways to make our lives easier as developers. The benefits of using it are obvious and many. @import is awesome; it lets us concatenate many development Sass files into one production CSS file if we wish. Variables and mixins can be amazingly handy.

Selector nesting, @extend, and parent-selector (&), while incredibly useful when care is taken, can also be prone to generate sub-optimal CSS when used carelessly, especially in cases where they are used in combination. Long-term, CSS that is compiled from Sass that abuses these features can quickly become extremely bloated and challenging to maintain. Let’s take a look at some examples of some really sad CSS. The examples I’m using are inspired by actual projects I’ve worked on (with some key edits to protect the innocent).

Note that I’m not blaming Sass itself for any of these problems. It’s quite simply that using some Sass features in a certain way can inadvertantly amplify poor CSS design decisions.

Case 1

Sass selectors that are nested like this:

(example-2.sass) download

#product
  .overview
    .header
      h2
        span
    .content
      .promo
        .header
          div
          .inner
            a
              span

will result in CSS descendant selectors that look something like this:

(example-2.css) download

#product {}
#product .overview {}
#product .overview .header {}
#product .overview .header h2 {}
#product .overview .header h2 span {}
#product .overview .content {}
#product .overview .content .promo {}
#product .overview .content .promo .header {}
#product .overview .content .promo .header div {}
#product .overview .content .promo .header .inner {}
#product .overview .content .promo .header .inner a {}
#product .overview .content .promo .header .inner a span {}

Yuck. I’m not going to go into why this is bad, but you don’t have to take my word for it; simply google ”CSS performance descendant selectors” and read up.

With Sass, this kind of CSS bloat is extremely easy to cause if you get carried away with selector nesting. Observe the redundancy and the verbosity of the generated CSS. If the developer had taken the time to carefully construct his selectors, he could have avoided the need for this many levels of descendants in his CSS.

To my great shame, that developer was yours truly.

Case 2

This one combines the @extend, nesting, and parent-selector features of Sass. @extend has been one of my favorite features of Sass ever since it was added. It lets you inherit the properties of one selector in another. Here’s how it can go awry, despite all the best intentions. The Sass:

(example-3.sass) download

.clearfix
  &:after
    clear: both
    content: '.'
    display: block
    height: 0
    line-height: 0
    overflow: hidden
    width: 0

.thing-1
  @extend .clearfix
.thing-2
  @extend .clearfix

// ...

.thing-99
  @extend .clearfix
.thing-100
  @extend .clearfix

In the Sass, let’s assume I extended .clearfix in 100 separate selectors at various places throughout my code. This is, unfortunately, a very realistic use case for something as commonly used as a clearfix, and as my project grows, it would eventually result in the following generated CSS:

(example-3.css) download

.clearfix,
.thing-1, .thing-2, .thing-3, .thing-4, .thing-5,
.thing-6, .thing-7, .thing-8, .thing-9, .thing-10,
.thing-11, .thing-12, .thing-13, .thing-14, .thing-15,
.thing-16, .thing-17, .thing-18, .thing-19, .thing-20,
.thing-21, .thing-22, .thing-23, .thing-24, .thing-25,
.thing-26, .thing-27, .thing-28, .thing-29, .thing-30,
.thing-31, .thing-32, .thing-33, .thing-34, .thing-35,
.thing-36, .thing-37, .thing-38, .thing-39, .thing-40,
.thing-41, .thing-42, .thing-43, .thing-44, .thing-45,
.thing-46, .thing-47, .thing-48, .thing-49, .thing-50,
.thing-51, .thing-52, .thing-53, .thing-54, .thing-55,
.thing-56, .thing-57, .thing-58, .thing-59, .thing-60,
.thing-61, .thing-62, .thing-63, .thing-64, .thing-65,
.thing-66, .thing-67, .thing-68, .thing-69, .thing-70,
.thing-71, .thing-72, .thing-73, .thing-74, .thing-75,
.thing-76, .thing-77, .thing-78, .thing-79, .thing-80,
.thing-81, .thing-82, .thing-83, .thing-84, .thing-85,
.thing-86, .thing-87, .thing-88, .thing-89, .thing-90,
.thing-91, .thing-92, .thing-93, .thing-94, .thing-95,
.thing-96, .thing-97, .thing-98, .thing-99, .thing-100 {}

.clearfix:after,
.thing-1:after, .thing-2:after, .thing-3:after, .thing-4:after, .thing-5:after,
.thing-6:after, .thing-7:after, .thing-8:after, .thing-9:after, .thing-10:after,
.thing-11:after, .thing-12:after, .thing-13:after, .thing-14:after, .thing-15:after,
.thing-16:after, .thing-17:after, .thing-18:after, .thing-19:after, .thing-20:after,
.thing-21:after, .thing-22:after, .thing-23:after, .thing-24:after, .thing-25:after,
.thing-26:after, .thing-27:after, .thing-28:after, .thing-29:after, .thing-30:after,
.thing-31:after, .thing-32:after, .thing-33:after, .thing-34:after, .thing-35:after,
.thing-36:after, .thing-37:after, .thing-38:after, .thing-39:after, .thing-40:after,
.thing-41:after, .thing-42:after, .thing-43:after, .thing-44:after, .thing-45:after,
.thing-46:after, .thing-47:after, .thing-48:after, .thing-49:after, .thing-50:after,
.thing-51:after, .thing-52:after, .thing-53:after, .thing-54:after, .thing-55:after,
.thing-56:after, .thing-57:after, .thing-58:after, .thing-59:after, .thing-60:after,
.thing-61:after, .thing-62:after, .thing-63:after, .thing-64:after, .thing-65:after,
.thing-66:after, .thing-67:after, .thing-68:after, .thing-69:after, .thing-70:after,
.thing-71:after, .thing-72:after, .thing-73:after, .thing-74:after, .thing-75:after,
.thing-76:after, .thing-77:after, .thing-78:after, .thing-79:after, .thing-80:after,
.thing-81:after, .thing-82:after, .thing-83:after, .thing-84:after, .thing-85:after,
.thing-86:after, .thing-87:after, .thing-88:after, .thing-89:after, .thing-90:after,
.thing-91:after, .thing-92:after, .thing-93:after, .thing-94:after, .thing-95:after,
.thing-96:after, .thing-97:after, .thing-98:after, .thing-99:after, .thing-100:after {
    clear: both;
    content: '.';
    display: block;
    height: 0;
    line-height: 0;
    overflow: hidden;
    width: 0;
}

First, there is a nesting issue. Because I nested &:after inside an empty parent selector, the generated CSS contains a huge list of selectors with no properties, then a second huge list with the clearfix styles. Plus, all these bogus selectors tend to clog up dev tools like Firebug, as shown in this screenshot:

Secondly, this could have all been avoided if I had been more pragmatic and simply used .clearfix (or another class – I commonly use .group) in the HTML to apply the CSS and make it semantically meaningful at the same time. Using @extend is not the correct choice for this particular pattern:

(example-4.sass) download

.group:after
  clear: both
  content: '.'
  display: block
  height: 0
  line-height: 0
  overflow: hidden
  width: 0

// That's right, I'm not using @extend here.
// It's almost like I'm using actual CSS \o/

(example-4.html) download

<div class="thing-1 group">
  <!-- stuff floated left -->
  <section class="primary-content">
    <!-- ... -->
  </section>

  <!-- stuff floated right -->
  <aside class="secondary-content">
    <!-- ... -->
  </aside>
</div>

Sass => CSS

I, for one, side with those who seek to balance CSS performance concerns with maintainability concerns. It’s important to remember that no matter what you do in Sass, it will eventually end up as CSS. Whether it does more harm than good will be up to you.

Ironically, though it might seem at first that we have veered too far towards the maintainability side of the spectrum with our CSS, it turns out that the status quo isn’t terribly well suited for either maintainability or performance.