A little over a year ago, I posted a series of images of Ninja Turtles that the then employees of Disqus drew.

Now, there are more people at Disqus. And with that comes more Ninja Turtles. In no particular order, here they are.

We’re using the jQuery template plugin at Disqus for several of our pages, and it waas getting annoying that Vim wouldn’t properly highlight parts of the template language.

As such, I’ve created a fairly small and rudimentary syntax file for Vim 7.1+ that will color some basic elements of the template language.

Get it here: https://github.com/dz/jQuery-Template-Vim-Syntax

I say Vim 7.1+ because that’s what I use, and I haven’t tested with anything older.

Note that if Django HTML is enabled, it assumes you have a Django syntax available.

At the office at Disqus earlier today, several of us tried our hands at drawing a Ninja Turtle. Here they are!

Ben

Daniel

DZ

Chris

Jarod

Jason

Mac

Today was my last day at Threespot. Starting on May 17th, I will be working for Disqus as a software engineer.

I will miss the people at Threespot dearly, and not just because I’m losing a supremely awesome lunch mate.

But the future is bright, and I’m really excited to get started on improving a truly neat and interesting service. It’s built with my favorite programming language, and uses my favorite application framework.

Wish me luck!

Putting attributes of a selector on one line have been advocated by several high-profile people in the web development field in the past, but uniformly, I’ve felt that the benefits they claim derive almost entirely from a lack of understanding of their tools.

There are a bunch of articles written on the subject, but let’s take this famous one from orderedlist.

The chief reasons to use this method are:

• Easier to scan selectors

• Less lines to scan through to find the selector

With the primary drawback being:

• Harder to scan for attributes

I’m going to add to the drawbacks list later. But for now, let’s take a look at the benefits.

Why are you doing this manually?

I’ll admit that putting CSS all on one line does make it easier to see selectors. Take this, for example:

The selectors are genuinely harder to take in at a glance when compared to a one-line version.

(Of note, I’m using Textmate in this example because it’s typically the editor of choice for many front-end developers writing CSS. But the techniques here also apply to vim, emacs, or any other decent programming editor)

But, what happens if I press command-shift-T?

I get:

This, essentially, duplicates the one-line CSS advantage by using built-in functionality that any capable programmer’s editor provides: the symbols list.

This symbols list has some distinct advantages when compared to the list provided by the ondline-technique: the symbol list is searchable, is filterable, and is completely automatic. Meaning that in the image above, if I wanted to only see those selectors relevant to #feature, typing feature into the input will filter the symbols being displayed.

All without having to sacrifice formatting.

The hidden drawbacks

There are some drawbacks not in the article that I wanted to mention.

Line-level diffs and patches

It’s not uncommon to have a line be very long due to the length and number of attributes on a selector. This means that when viewing source diffs or changeset diffs in your SCM of choice, it becomes increasingly harder to discern exactly what changed.

Syntax coloring helps, of course, but even then, many systems do not show character level changes within a line in a robust manner.

Out of sight, out of mind

Let’s face it, unless you program in a maximized window, most of us will not be able to see the entire one-line selector without scrolling horizontally. This is fine at first, but can become a liability during CSS debugging.

I’ve seen, firsthand, several instances where a bug was not realized because the faulty attribute in question was beyond the horizontal scroll.

Most programmers hate long lines that cut out of view with a passion for good reason.

Speaking from experience

The one-line approach was used at Threespot on a couple projects, so I’m not completely making all of this up. The additional drawbacks were real, practical issues that we faced when dealing with CSS that needed to be managed, shared, and maintained.

Learn your tools

I can’t stress this enough. The articles advocating the one-line technique are certainly acting in good faith, but is promoting the sort of manual optimization that is completely unnecessary given robust editors.

Optimization through source formatting is an important area to consider. But let’s not forget the other big area: your tools.