• "Red dot fever enforces a precision into your design that the rest must meet to feel coherent. There’s no room for the hereish, nowish, thenish and soonish. The ‘good enough’." Dingdingding. +5 points to Taylor, as usual. Place, not location.
  • "TinkerKit is an Arduino-compatible physical computing prototyping toolkit aimed at design professionals. The interest in physical computing as an area in development within the creative industries has been increasing rapidly. In response to this Tinker.it! is developing the TinkerKit to introduce fast iterative physical computing methodologies to newcomers, and particularly design professionals." Standardised modules, standardised connectors, Arduino-compatible. I remember Massimo showing me his keyboard-emulating board ages ago. Nice to see Tinker productising the platform, too.
  • "The buttons are designed to look very similar to basic HTML input buttons. But they can handle multiple interactions with one basic design. The buttons we’re using are imageless, and they’re created entirely using HTML and CSS, plus some JavaScript to manage the behavior." Dark, dark voodoo, but very impressive – and excellently explained by Doug Bowman. It's nice to see Doug blogging again.
  • "If 2009 is going to see the emergence of high-quality browser-based games, then 2009 is going to be the year of Unity. It has: lots of powerful features; iPhone support; Wii publishing; a developing community; quality developers using it; and an upcoming upcoming PC version. In short, it is about to make a major splash. I feel compelled to jump in with it — the indie license is cheaper than the Flash IDE."
  • "bash completion support for core Git." Ooh. This looks really, really nice.

So the CSS Redundnacy Checker has done a fair bit of traffic recently. Wow, etc. I hope it’s turning out to be useful. I’ve committed a few minor fixes, and there could be more improvements to come thanks to some useful feedback. I’ll be getting in touch with people about it over the next few days, I hope.

When I sat down to write the tool, I knew it would only be possible with a decent CSS parser (because you need a proper parser, and can’t do this with regex magic). The two that leaped to mind immediately were Hpricot and jQuery. In the end, I went with the former, because a commandline script seemed a good starting point, and something that could be built open in many ways.

In the comments thread, Tom at WorkingIdea alerted me to his jQuery-powered CSS Redundancy checker. It’s a Greasemonkey script with built-in jQuery that dumps redundant classes either to the Firebug console or to a Javascript console if you don’t have Firebug. Sounds like it might not be quite as fast as the Ruby one – or as flexible – but if you don’t have Ruby installed or just want to run something from your browser, it’s a great idea. And it’s the same principle as my script – harnessing somebody else’s CSS parser in a really simple way.

So now there are two ways into the same usefulness. It only seemed fair to link this up, given what a neat solution it is – and how close I came to doing it myself.

(Incidentally, the reason there’s not an online version of my script is because it is a slow process, and I’d have to write some kind of queueing solution on the frontend, and it could all get messy fast. It’s not for that. Get it yourself, run it locally; there are instructions on setting it up for people who don’t have Ruby in the README).

There comes a point in every developer’s life when your realise the problem isn’t your work, but the tools you’ve got to hand. Toolsmithery is an important part of the job, and so I spent a few hours yesterday crafting a tool useful to any front-end developer.

The result is the CSS Redundancy Checker.

When you’re writing HTML, over time, your CSS files begin to fill up a lot. If you’re working on a large project, you might even end up with several people contributing to the CSS file, not to mention refactoring each other’s work. The result is a directory full of HTML files, and a very large CSS file.

What tends to happen is that not ever selector in the CSS file actually applies to your HTML; many are rendered redundant by refactoring, or by changes in HTML. But when you’ve got a 70k+ CSS file, it’s not easy to check precisely which selectors aren’t in use any more.

Enter the CSS Redundancy Checker. It’s a very simple tool, really. You pass in a single css file, and either a directory of HTML files, or a .txt file listing URLs (one to a line). It then proceeds to look at each file in turn, and at the end, list all the selectors in your css file that aren’t used by any of the HTML files.

That’s it. I’m pretty sure it’s accurate, and it should work with most CSS files. Most of the magic isn’t down to me, but down to _why the lucky stiff‘s marvelous Hpricot HTML parser. The script itself is about 50 lines of reasonably tidy Ruby. You’ll need Ruby, and Hpricot, in order to run it. There’s more full documentation over at the Google Code site where I’m hosting it. Please add any issues there, or get in touch if you want to contribute.

Things it doesn’t do: listing line numbers of where the selectors are. I wrote that functionality on the train this morning, but I can’t find a way to make it 100% accurate, so thought it best to leave it out – inaccurate line numbers are of no use to anyone. If you can come up with a way that works, let me know. Also, at some point I might turn it into a Textmate command. All in good time, though.

The need for the tool came out of a large project we’re working on at NPG, but I felt it would be useful to pretty much any HTML developer. So I’ve released it to the world. Let me know what you think, and do spread the word. You can get it via svn checkout, for now:

svn checkout http://css-redundancy-checker.googlecode.com/svn/trunk/ css-redundancy-checker

To cut a long story short: the slides for the talk I gave earlier this week are now available. You can find out more about the talk on the talks page of this site, or you can download the PDF (1.5mb). It should be fairly self-explanatory.

(A brief summary for those of you unable to scroll or click: it’s a client-side-developer’s perspective on Rails, and how to integrate client side development into the build process).

Getting Naked

05 April 2006

So apparently it’s Naked Day today. Strip away your CSS, show off your white bits.

It’s only right I join in, given that my day-job now is writing the leanest, most accessible XHTML/CSS I can, and that, more to the point, I spent a fair while trying to make this site vaguely accessible if you can’t see the stylesheet. So here we are. Raggedy-bits and all. The stylesheet will automatically switch back to its “International Klein Blue” look on the 6th April.

(The site is, of course, now back to normal)