So, I created a gem, Chlorine. It’s very simple: With just 3 lines of configuration, you can say, “I want to delete everything but lib/ and sass/ in my public/stylesheets folder every time I start my server in development” mode. Pretty handy, I’d say. Use with caution, of course.

Now, why not IE? IE has actually had a lot of power for many years, in the form of filters, and it seems like you should be able to transform anything an arbitrary number of degrees using a Matrix Transform. But, I have no idea whether it’s even possible to do that in Sass given a number of degrees. The documentation baffles me. If you can find an example of using IE filters to do rotation to an arbitrary number of degrees (not just multiples of 90), please post a comment about it.

I should also mention the cssSandpaper library, which looks very exciting. You define a -sand-transform CSS property and it translates it to whatever the browser needs. Demo here.

It adds two new jQuery functions, isInDOM and notInDOM, which do just what you’d expect. For instance, $foo.remove().notInDOM() is always true. Simple, right? I hope you find it useful.

So I created a simple little jQuery plugin to make my code just a bit more DRY. It adds a function called doAndBind to your jQuery objects. As the name suggests, doAndBind does two things: It executes the given functions right away, and it binds them to the given event. (Note that in jQuery, event functions like click(func) are just wrappers around bind(eventType, func). bind is all you need.) For instance, with this plugin I can say (in CoffeeScript):

$(window).doAndBind 'resize', ->
 $('#stickyFooter').css {marginTop: $(window).height() - 100}

Ah, sweet syntactic sugar.

The plugin should be capable of handling all of the forms of the bind() function described in the API docs, but please let me know if you encounter any problems. Here’s the download link: jqDoAndBind

Yes, I am duly embarrassed. But it’s harder than it sounds.

By default, if you draw a 1px line in Raphaël, you get something fuzzy, thick and grey, even when you (superfluously) specify stroke: 'black' and 'stroke-width': 1. It turns out that this is due to SVG’s subpixel precision and anti-aliasing gone awry, and that there are two fixes:

1. Shift the line by 0.5px. This is the approach that gRaphaël takes when it draws axes.
2. Set the path’s shapeRendering to 'crispEdges'. I discovered this issue, which suggested that it should be the default behavior for Raphaël.

The latter option seems much cleaner to me, so I’m going with it for now. I’m a little wary, though, because why does Dmitry himself use Method #1? And what happens in IE?

I’m rooting for CoffeeScript to become a mainstream language, and mainstream languages need an ecosystem of tools in order to catch on. There are already plugins for it in TextMate, Emacs, Vim and IntelliJ, and some cool stuff that makes using CoffeeScript in Rails apps a breeze.

The patch for CoffeeScript support in GeSHi can be downloaded from this ticket. I’m sure it’s not perfect (yet), but it’s one small step toward CoffeeScript world domination.

You see, in Twenty Sassy, I had some block comments of the form

/*
* LAYOUT: Two columns
* DESCRIPTION: Two-column fixed layout with one sidebar right of content
*/

This was no problem in Sass 3.0.5, but under 3.0.9, it utterly broke the CSS. How? Well, instead of rendering as the CSS block comment you’d expect, it now renders as

/*
 * LAYOUT: Two columns
 *
 * DESCRIPTION: Two-column fixed layout with one sidebar right of content
 *
 */ */

and that trailing */ wreaks utter havoc. You can have a block comment /* like this */, but you can’t put */ on its own line.

Next time, Sass, how about a compiler warning?

But where to begin? The Twenty Ten source is well-commented (good job, WP team), but it’s also verbose and unorganized. There’s no map telling you, “OK, if you want to change this, do that.”

So, let’s tweak the stylesheets. There are four of them: style.css, editor-style.css, rtl.css and editor-style-rtl.css. These last two are just adaptations of the first two for right-to-left text (e.g. Arabic); they’re used in place of the first two depending on your blog’s language setting. I’m going to ignore them for now. editor-style.css is, as it suggests, custom styles for the visual editor. So if you’re modifying Twenty Ten, you should start with style.css and then, once you’re happy with the aesthetic, update editor-style.css to match.

One problem: style.css is 1355 lines long! So I did a quick sass-convert style.css style.sass, which worked beautifully, but the result was still 1100 lines long. 1100 lines of styling!? What blog needs that? Inspired by Chris Eppstein’s Refactor My Stylesheets: Digg Edition, I decided to go through it, organizing and tightening the code while making it easier to understand and modify. The result, Twenty Sassy, can be found on Github. All of the stylings have been preserved, as have the semantic comments (those that are meaningful to the WordPress Theme Directory). More importantly, variables you’re likely to want to modify have been moved up to the top.

There’s still a lot of room for improvement, but it’s a decent first pass. Instructions can be found at the Github repo. Enjoy, and please fork!

function walk(holder, key) {
  var k, v, value = holder[key];
  if (value && typeof value === 'object') {
    for (k in value) {
      if (Object.hasOwnProperty.call(value, k)) {
        v = walk(value, k);
        if (v !== undefined) {
          value[k] = v;
        } else {
          delete value[k];
        }
      }
    }
  }
  return reviver.call(holder, key, value);
}

becomes

walk: (holder, key) ->
  value: holder[key]
  if value && typeof value == 'object'
    for k of value
      if Object.hasOwnProperty.call value, k
        v = walk value, k
        if v != undefined
          value[k] = v
        else
          delete value[k]
  return reviver.call holder, key, value

I haven’t tried to change the actual structure of the original code, but I may in the future. This was exceptionally readable, neatly commented JavaScript code in the first place; rewriting it was very straightforward.

This was mainly a learning exercise, but I’ve uploaded the results to Github as JSON.coffee. Try it out, fork it, make it better. Perhaps it should be trimmed down to a tight stringification engine; jQuery gives you JSON parsing, but leaves you to look elsewhere when you need a string.

var obj = {1: 'A', 2: 'B', 3: 'C'};
for (var x in obj) {
  console.log(x);
};
// Console output: 1, 2, 3

Coming from Ruby or Java (5+), you’d expect the output to be A, B, C. (Python’s for...in syntax behaves the same way on dictionaries, though not on arrays.) That is, you expect x in obj to assign each value of obj to x. Instead, JavaScript iterates over each key. If this doesn’t worry you, consider this:

var arr = ['A', 'B', 'C'];
for (var x in arr) {
  console.log(x);
};
// Console output: 0, 1, 2

Do you see what’s going on here? Internally, arrays in JavaScript are just hashes from numerical indices to values. This is a common point of confusion in JavaScript, and has led to several techniques to work around it:

1. Just use the key

The most direct approach is to plug the key into the object to get each value:

var arr = ['A', 'B', 'C'];
for (var x in arr) {
  console.log(arr[x]);
};
// Console output: A, B, C

There are two problems with this: First, the code isn’t very clear to readers. It doesn’t say “I’m iterating over keys, but what I really care about are the values.” (Renaming x to key would help a bit.) Second, there’s a small performance hit from each arr[x] call; this might be an issue in performance-critical loops that reference the same value repeatedly. You can correct this by putting var value = arr[x]; at the top of the loop.

2. Use an auto-executing function

A slightly more sophisticated approach is to define an anonymous function that takes the key from each loop iteration:

var arr = ['A', 'B', 'C'];
for (var x in arr) {
  (function (value) {
    console.log(value);
  )(arr[x]);
};
// Console output: A, B, C

Of course, this is a lot of boilerplate. Which brings us to…

3. Use jQuery

jQuery lets you get rid of the confusing for syntax altogether by using the built-in each function, as follows:

var obj = {1: 'A', 2: 'B', 3: 'C'};
$.each(obj, function(key, value) {
  console.log(key + ':' + value);
});
// Console output: 1:A, 2:B, 3:C

Now we’re talking! Just one line of code that lets us loop over both the keys and the values of any collection. Of course, we can do one better with…

4. CoffeeScript

In CoffeeScript, the for...in syntax is reserved for arrays and iterates over values rather than keys, as you’d hope:

arr: ['A', 'B', 'C']
for value in arr
  console.log value
# Console output: A, B, C

Beautiful! But what if we need to iterate over an object’s keys? Well, then we use of instead of in.

obj: {1: 'A', 2: 'B', 3: 'C'}
for key of obj
  console.log key
# Console output: 1, 2, 3

And what if we’d like to get the keys and values at the same time? We just put two comma-separated variables before of:

obj: {1: 'A', 2: 'B', 3: 'C'}
for key, value of obj
  console.log key + ':' + value
# Console output: 1:A, 2:B, 3:C

No more function wrappers! Note that for...in is meaningless in CoffeeScript when applied to a non-array; you should nearly always use for...of.

Concluding caveats

for x in has another JavaScript quirk you need to be aware of: It iterates over not only items attached to an object directly, via obj.property = or obj['property'] =, but also those added to its prototype, as in obj.prototype.property =. This is especially confusing if you use a library like Prototype that extends the built-in JavaScript types; for instance, because it adds functions to the Array prototype, using for x in [1, 2, 3] after including Prototype will iterates over more than 3 items!

jQuery’s each is smart about this, using hasOwnProperty internally to filter out prototype items, as does CoffeeScript.