Observe:

An incredibly long standing issue, that keeps popping up, gets a handful of follow-ups, none of which actually address or even mention any of the technical problems that need to be solved.

Instead, all it gets is a bunch of "+1 Subscribe" follow-ups. Whenever I see such a comment, it tells me this:

I really want this feature, but I'm not prepared to do anything about it. I won't spend any time educating myself about it, exploring the problem space or prototyping possible solutions. I fully expect others in the community to solve it, while I reap the benefits.

Go ahead, call me cynical and misguided.

One of the major things that really bugs me about the web is how poor the average web programmer handles strings. Here we are, changing the way the world works on top of text based protocols and languages like HTTP, MIME, JavaScript and CSS, yet some of the biggest issues that still plague us are cross-site scripting and mangled text due to aggressive filtering, mismatched encodings or overzealous escaping.

Almost two years ago I said I'd write down some formal notes on how to avoid issues like XSS, but I never actually posted anything. See, once I sat down to actually try and untangle the do's and don'ts, I found it extremely hard to build up a big coherent picture.

But here we are now, and I'm going to try anyway. The text is aimed at people who have had to deal with these issues, who are looking for a bit of formalism to frame their own solutions in.

Update: Google's DocType wiki has an excellent section with instructions for escaping for various contexts.

I finished designing and building this year's edition of LeuvenSpeelt.be, a site that promotes student theater at my old university. You can read about the background in my previous blog posts.

The site is a simple Drupal installation with heavy content and theme work. The design is heavy on graphics and built as an experimental semi-fluid layout that adapts to different screen resolutions. Peripheral design elements are shifted in or out of the browser frame to make more space for content as needed.

Tools used: Photoshop, Illustrator, 3D Studio Max, TextMate. Uses the beautiful Fontin font available freely from Jos Buivenga's exljbris foundry.

And no, no easter eggs this year.

Various people have prodded me to explain my recent involvement in Drupal, or rather the lack of it. Unfortunately, I haven't found a way to do so in a way that is constructive and tactful, especially not when it comes to other contributors. Like Soylent Green, Open Source is made of people, and it's these people who are at the basis of a mountain of frustration that has driven me off.

According to Ohloh, Drupal 6 core now consists of 8% JavaScript. This is quite a lot.

Drupal and JavaScript haven't always seen eye to eye though.

While the first clean and consistent usage of JavaScript in core was the textfield autocompleter and accompanying drupal.js base (committed a little over two years ago), this was not the first line of JavaScript in Drupal core.

The Yaroon theme for example had a little JS dropdown navigator in 2001, while the Goofy theme used JavaScript to compress its gigantic table-based markup—yes, we were n00bs at one time too. In fact it took until January 2003 (with the retiring of the Goofy theme) for core to go back to plain PHP, HTML and CSS.

From that point on, JavaScript was shunned and suggesting it as a solution to a problem was sure to cause grumpy voices to rise. So it's not surprising that in 2005, a lot of people were skeptical about the proposed JavaScript features for Drupal 4.7. Still, the new incarnation was written with the clear mindset that everything must degrade gracefully without it, and that the methods used should be accessible, extensible and clean. The code got committed and was eventually released in May 2006.

Even so, it really wasn't until we included the jQuery library in Drupal 5 core that a significant amount of Drupal contributors started working with JavaScript in their modules and themes, as it lowered the barrier to entry for browser scripting massively.

Given all that, I'm quite impressed with this 8% figure for core. Slowly but surely, JavaScript in Drupal has gone from ugly duckling to shining star.

8 tips for the aspiring Drupal developer

Open source is really great. You get to cherry pick from some of the best software out there and build neat stuff with it, fast. Most open source projects will also encourage you to contribute your own work back to the project. Supposedly, so others can benefit from your work.

While that's often an easy, karma-scoring move, it can have some unintended, annoying consequences. For example, people might start sending in bug reports for your code or may offer suggestions on how to improve it. Even worse, meddling know-it-alls may even offer to 'help' with development and do things with it that you never intended. Some projects, like Drupal, even trick you into such forced participation, by automatically supplying issue trackers, RSS feeds, revision control and other, undesirable community interaction.

Luckily, there are several things you can do to keep those pesky contributors away altogether. You can participate in open source without suffering any of its extended effects. Here are some concrete tips for the aspiring Drupal developer. Of course, a true creative will find novel ways of keeping their open source involvement to an absolute minimum!