If you’re familiar with Kaleidoscope, you know it’s most unique feature is the algorithm that takes the date a post was published and determines a color that, based on some vague ideas of what colors fit what time of year, seems appropriate.

My original implementation of that was a large quilt-looking series of patchs that you can find on my archives page. And while I do like that — and the fact that it gives post names as well as colors — it requires someone to create and click to an archives page to see the best use of the algorithm.

The Mini Quilt was a way that I could have the quilt-looking array of posts, but offer it on every page of any WordPress blog, regardless of the existence of an archives page.

Well, I like the Mini Quilt, and I got a few requests from people who liked it too, so I built a plugin to allow anyone to add it to any widgetized WordPress theme. If also features simple but useful controls that allow you to quickly change patch size, and the number of patches in it to fit any size and show any number of posts.

To use it, you just need to search for the Mini Quilt plugin from inside your WordPress dashboard and install it (still from your dashboad — you’re using WordPress 2.7+, right?). Once it’s installed, activate the plugin and add the widget to your sidebar. It couldn’t be much simpler.

If you’re looking for more information before you take the above steps, you can try the plugin’s page here at Ikiru Design, or at the WordPress plugin repository.

1. Because no one else has made anything like this before and I’m sure it’ll be awesome.
2. Because no one has ever combined these feature sets and the combination will be legen — dramatic pause — dary.
3. Because this platform needs this type of software.
4. Because my version will be way better than all the others.
5. Because building it will teach me something.
6. Because I can do it too.

For better or worse, Cascading Style Sheets are meant to cascade. That means if you style an <h1></h1>, all thing elements enclosed in <h1> tags well inherent that h1 style. This is both incredibly useful and incredibly troublesome.

It nice that if you really do want all your <h1>s to look the same. The cascade assures that they do regardless of the <div> they’re under or the classes you’ve given them. It’s a problem because when you absent-mindedly use an <h1> tag without remembering that you’ve styled the attribute, you can get some wonky looking stuff.

There are two basic means to deal with this reality: containment and a laissez-faire “let it cascade” approach. The first has the advantage of meaning that you never accidentally have things cascade, but the disadvantage that your stylesheet may well end up incredibly verbose. The latter has the advantage that when used correctly it can give you surprisingly brief stylesheets, but while composing that sheet you may well fall victim to the aforementioned surprise cascade.

Before we get too far into the analysis of the problem, some basic understanding. A containment strategy will wrap everything in every ancestor class all the way down to the exact element you’re styling. This assures that you never have a single style cascading in an expected way, and will generally yield something like this:

#container #content .post .entry p {
margin: 1em 0;
font-size: 1.2em;
font-face: "Times New Roman", Times, serif;
}

Conversely, a cascaded style you only define what you’re styling in a loose and primarily pragmatic manner. The above might come out simply as:

.entry p {
font size: 1.2em;
}

This obviously assumes that face and margins were defined elsewhere. And though it’s not always going to be true, it’s a realistic possibility with a full-fledged cascade.

From a simple length perspective, there’s reason to assume that the latter method is better. But you never know when you’ll realize that you’ve already styled <p> to include font-size: 5em; or some such nonsense. In this case — and this is a unique problem for those sizing thing in ems — you’ll get a font size of 6ems, or around 60 pixels, certainly not what you wanted.

I’ve got a gut-level aversion to verbosity where it’s not necessary. But I don’t like being surprised by unexpected cascading bits either.

There is, I think, a way to split the difference. A managed cascade can allow for a reasonable number of “presets” while still leaving sufficient room to avoid the accidental cascade. Though I still think that browsers welcome movement away from crude text resizing and toward zoom will eventually render the use of ems for sizing completely obsolete, that day isn’t here yet. (And if it were, not all the issues in the containment versus cascade battle would be resolved.)

So for now, I think it’s best to contain as much styling as you feel is reasonable, while allowing some things to cascade. It’s an unconscious working assumption I’m sure more than a few designers already use, but it’s a conscious one I’m certain I’ll be helped by.

And though I earlier said I didn’t want to post about every release, I feel people might actually want to know that I have released a new version of Kaleidoscope at the WordPress.org Theme Directory.

It supports both threaded comments and pagination. I actually forgot about the existence of “sticky posts” until after I uploaded it, so I have no idea what, if anything,  needs to be done to support those.

It’s not the polished version I’ve been hoping to make, but it functions well for most purposes. And it offers support for the most anticipated features of WordPress 2.7, so I’ve no doubt that despite its shortcomings it’s worth releasing.

Just a note for those looking for threaded comments: you need to enable them (In Settings>Discussion) before you’ll see them. They’re turned off by default for the sake of backwards compatibility.

UPDATE (19 Jan 09) — In a heretofore unprecedented move, I actually dropped an even newer version yesterday, and it’s available. Major highlights: basic sticky post support, and lots of styles for obscure situations that no blog but the example at the theme directory is very likely to try.

It worth noting that I did this Saturday. Things have changed since. If you’re interested, popularly relevant information about development is at the WordPress Blog. More abbreviated notes, and up-to-the-day changes are tracked here.

Because some of my impressions make little sense without visuals, I’ve included a gallery of the most notable changes that have so far been made in the progress toward 2.7. (Sidenote: first time I’ve used the gallery in WordPress.)

And now my impressions, as originally noted:

I don’t really like how the new version smashes out the horizontal space. Though I doubt the change is nearly as big as it currently seems to me, it’s undeniable that the compose area fits fewer words per line than did previous (2.6-) versions.

The left side navigation has its pluses and minuses. I like that you can get to any page at all from it, but it’s also there even when you aren’t wanting to go to any page.

I think the term Utilities in the sidebar is misguided. “Manage” seemed to make more sense, and still does.

The built-in browse and install feature for plugins is pretty unquestionably cool.

The built-in upgrade to WordPress itself seemed to have failed on my one and only attempt. (It has since worked for me, the failure may have been a fluke.)

I think the ability to drag anything on the write page the sidebar is good, but it’s not as much customizability as I’d like. Will I ever be able to put a custom field on a post, without having to name that field every time? And be able to put that field right under the title field if I so choose? Until then any changes or not to the Write page will seem rather superficial to me.

There appears to have been few or no changes made to the Themes area thus far.

The dashboard has changed, but right now the utility of the “Inbox” and Quick Post sections, both sitting above the news boxes of 2.5+, are open questions.

Clearly there’s no small amount of work left before 2.7 “ships” in November (by current plans). That said, I’m amazed by all the great features slated for inclusion, and I feel so lucky to blog on such a constantly-improving platform.

The Problem: Incompatible Rules

During my work on Kaleidoscope, that’s the theme this site is running, I decided that a random post link in the footer would be nice. A quick search yeilded Matt’s Random Redirect Plugin, which was more than up to the job. Without a need to reinvent the wheel, I just borrowed the core functionality of Matt’s plugin function and dropped it into my theme’s functions.php file.

And on my personal test server, it worked well. And when I put it on the Ikiru Demo Blog, there too it worked fine. But I found problems on Ikiru Design. More frustratingly, those problems would sometimes seem to suddenly disappear. (It was only later that I realized that it was whether or not I’d logged in that was the cause of that disparity.)

As you may suspect from what I’ve said so far, Ikiru Design has the WP Super Cache plugin running (though it has rarely needed it). Looking desperately to figure out why my redirect link in the footer worked on the demo blog but not on the main one, I decided to look through their directories.

Solution One: Changing .htaccess

Mercifully, I noticed that the .htaccess files were drastically different sizes. And I remembered that SuperCache depends on your making changes to that file. And indeed, comparing the two showed these lines added to Ikiru’s .htaccess file:

# BEGIN WPSuperCache

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]

RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]
</IfModule>

# END WPSuperCache

I now understand what this does, but at first I didn’t. It looked like a mash of random characters. But I know enough about programming conventions to guess that an “!” means not. And I also know enough about this modern world to know to Google things I don’t understand. “RewriteRule” seemed a reasonable phrase to start with.

I’ll spare you the full narrative of the search, but I’ll explain what I learned. RewriteCond provides the conditions that determine whether or not a RewriteRule is used by the server. Essentially, if a user trying to access a given file on the server gets through all the conditions in the RewriteCond stack, they’ll be made to follow the RewriteRule.

In this case, that means that if their query string — that’s the ?s or ?p=187 or ?random that tells the server what dynamic features are wanted — doesn’t start with ?s, and if the user doesn’t have a cookie specifying that they’ve either logged in or commented, and if the proper static file has been generated, send them that static file. (You see essentially the same rules there twice, the top one is for if you’re using compression, the other for if you’re not.) This is exactly how Super Cache is advertised to work.

But it means that the server will ignore the query string ?random that Matt’s Random Redirect function relies on. So the user will get, as I was, the cached version of the index page. And they’ll get it before Matt’s plugin has had a chance to well, redirect them.

Having figured that this was what was probably happening, I felt reasonably hopeful that I could finally fix this week-old problem. After all, the random link was working when I was logged in — thus not making me follow the RewriteRule — but it was failing when I wasn’t.

So I added was this line to the RewriteCond stacks:

RewriteCond %{QUERY_STRING} !.*random*

This adds an exclusion, which says that if the url looks something like “http://www.ikirudesign.com/?random”, exclude the user from the RewriteRule. Uploading the modified file and opening the link from every conceivable page I could find showed that it was finally working.

Solution Two: Changing the Function

But this can’t be packaged into a theme. Fortunately, a usable but imperfect solution can be. The basic problem is that redirects break with WP Super Cache. The solution is to do this same thing without a redirect.

Essentially, all this take is simplifying Matt’s Random Redirect Plugin even further. The result was this function:

function sc_safe_random() {
	global $wpdb;
	$query = "SELECT ID FROM $wpdb->posts WHERE post_type = 'post' AND post_password = '' AND post_status = 'publish' ORDER BY RAND() LIMIT 1";
	$random_id = $wpdb->get_var( $query );
	return get_permalink($random_id);
}

This is essentially the first three lines of Matt’s function — which picks a random post from among those eligible on your blog — and adds a line that just tells it to pass the permalink for that post to the place where the function is called. Then you simply call the function for your random link, like:

<a href="<?php echo sc_safe_random() ?>">a random post</a>

This solution works, but it’s got a problem. If I were to click the redirect version into five new tabs from a single page, I’d receive five tabs each with a different random post in it. If I do the same with this version, I get the same post each time.

The likelihood of someone doing this is obviously questionable, but it’s a feature that I’d rather not lose. For that reason, I’m planning on making sure that I allow a user who doesn’t have WP Super Cache enabled, or who have implemented Solution One, to use the redirect version. Those who have Super Cache enabled, or who don’t mind the limitations of this second solution, would be able to continue to use it.

1. The theme now has an options page. Controllable are the accent color — at Ikiru Design that’s set to “orange” — which is used one the description in the header and the links in the footer, the display of default gravatars, the display of The Mini Quilt (see #2), and switching to Southern Hemisphere colors.
2. The Mini Quilt. The Mini Quilt is a smaller version of the Quilt that appears on Kaleidoscope archives pages. To fit, it sacrifices displaying the Post Titles — though you’ll see them on hover — in favor of offering many more posts than a basic Recent Posts widget would. (And if you want to display both, or have even more control of your sidebar, the quilt will also appear as a potential sidebar widget.)
3. The random post link in the footer is now compatible with WP Super Cache. Because the popular plugin changes a blog’s redirect rules, the old method — which required a redirect — would break when you ran the plugin. The new method, which gets rid of the need for a redirect, will help keep your server load down, and will let readers use the link whether you’re caching or note. (Also, I’m working on a post explaining two different workarounds for the problem.)
4. Fixed a number of visual “bugs”. Two different problems caused the layout of certain pages to break in 0.7.6, with the help of Babs, those are fixed. A number of little problems have been tackled.
5. Finally, and this may have been unnoticed by everyone but me, in previous version of Kaleidoscope (and every theme I’ve made for that matter) the search bar has been outside of the area in the sidebar that is replaced by widget. That is because I didn’t like the styling of the widget. But now I’ve overridden the styling of the widget, and am satisfied with it. Essentially, you finally have the freedom to put the search box where ever you want it in the sidebar.

These are some of things I’d been planning to do on Kaleidoscope and I’m glad to have finally gotten them out. I’m sure there are still problems lurking under the surface, and I’m sure a quick-eyed user will find them quicker than I. If you’re such a user, please drop me a line.

Oh, the download link! And here’s a link to Kaleidoscope’s listing in the WordPress Themes Directory.

I honestly don’t remember when I started working on it, but I wouldn’t be surprised to find out it began in January. That isn’t to say that development of this theme has been terribly difficult — though there were certainly parts I’ve struggled with — but also that I’ve simply been short on time I’ve been able to devote to the project.

It wasn’t until Friday, after what felt like a too-long wait, that I finally saw the then-current version, 0.7.6 in the newly opened WordPress Theme Directory. This release, as signified by it’s less than 1.0 status, is less than I intend to do with the theme. But I’m hoping that finally making the project public will force me to spend more time to add the last features that I’ve been waiting so long to build.

Enough about how my development process works however, let’s cover the highlights of the theme itself. The primary feature, the one for which it is named, is the algorithm that translates dates into colors. This is done with a few PHP functions which take advantage of cosine curves to generate colors that are generally suited to the time of year. Essentially, the three colors of the red-green-blue system commonly used in HTML, all peak at different times. The blue is at it’s height around January first, green peaks around April 1, and red peaks around September 1. All of these are estimates, as I’ve fudged a bit with the peaks and valleys of these curves to give me colors closer to what I want.

Taking advantage of this date-to-color algorithm, I’ve made my favorite feature, the quilt. The quilt is, as you may guess, a collection of differently colored squares to create a blanket to keep you warm… err, display your posts. Rather than use the month-divided list-style archives I’ve built for my themes in the past, I’ve made a single collection of all posts, with colors serving to give you a rough idea of the date. You can easily tell posts from January from those from August, and you can also tell posts from 2008 are different from those from 2005. Of course, this feature is also made even easier to understand by the fact that the post are themselves shown chronologically in the quilt. The real result of the quilt, however, is that you get a beautiful rendering of your archives.

There are many more little features in this theme. I’ve added a rather novel system to hide the default gravatars when a user hasn’t set them. Trackback are seperated from comments so they don’t break the flow of conversation. The whole archives page is prettier than any I’ve made. Heck, the theme itself is just prettier than any I’ve made. And page titles have a novel organization I’m rather fond of.

Mostly though, I’m glad to have finally put this out into the world. It’s still not done, but I simply can’t continue to sit on it. I’ll keep you updated about changes I make to it in the future, and I hope to write a few tutorials explaining the most interesting features of Kaleidoscope to anyone interesting in using them in a different context.

You can, of course, see a demo of the theme at the Ikiru Demo Blog. Be sure to look at the archives page. (Or you can just look around here, as it is the theme Ikiru Design is currently using.) There is also a demo, lacking an archives page, at the WordPress Theme Directory. And you can download the theme from there. You can find even more rambling about it at the theme’s page. And if you have anything to tell me about it — be it bug reports, complaints, or compliments — feel free to contact me.

As anyone who’s spent much time surfing the internet can probably tell you, a mailto: link is the kind that usually launches a user’s email client and has some information — at minimum an address, but subjects aren’t uncommon — already filled in.

It sounds benign enough, but I don’t like it. There are three essential problems with using mailto: links on today’s internet. The first is a problems for the publisher, the second is a problem for users like me, and the third is a problem for all users. Add those all up, and I’m rather certain that mailto: links should be used as little as possible.

The most obvious and well known problem is the one posed to the publisher. That is: for nearly as long as there have been spammers on the internet, they’ve built bots those go around and scrape information from mailto: links. With this information, they do what any sensible spammer will, send you offers to enlarge your penis, get rich quick, win the lottery, and — if you’re really lucky — sign up for totally disgusting forms of pornography.

No one wants this stuff, and so schemes have been imagined to combat the problem. Some are rather low-tech, like creating a broken mailto: link like “mailto:me[at]me[dot]com.” This can work, if the sender recognizes that you’ve broken the link and they need to fix it. A myriad of other, more complex, options exist and yet none of them offer much compelling reason for not abandoning the format altogether.

But honestly, I don’t really care about the problems a publisher has when they use mailto: links, I have a problem with the inconveniences they cause me.

The first of which, and admittedly a not completely common one, is that I use Gmail as my primary email client. As such, when I (inadvertently) click a mailto: link the computer launches the default email client which I’ve never used nor configured. This means that I get a useless program launch that lets me compose an unsendable email.

There are work around for this, of course. One of the more elegant is offered for the forthcoming — but already widely used — Firefox 3. Gina Trapani explains how a few mildly technical steps can make the browser launch Gmail for mailto: link. But this isn’t something that the average user of a web-based email client is likely to know about or do, so it hardly solves this problem for those who want to use the mailto: link.

The last gripe was already touched on, but has broader implications than I earlier suggested. I can think of few things worse than navigating around a site and inadvertently launching another program — whether or not I regularly use that program.

This is usually a result of poor design, but not always. To my mind, the greatest sin is when a site puts a mailto: link in main navigation controls. This wasn’t too abnormal a decade ago, but mercifully convention now say that such a link should never launch an external program without warning. Some have yet to get that memo about conventions, however.

Though I personally dislike curmudgeonly exhortation from anyone, including myself, sometimes it just feels necessary. Mailto: links are a poor invention when they work perfectly, and a hideous invention when they don’t work properly.

Personally I’m a fan of contact forms — like the one I use. There are a lot of plugins that make it easy to build one for WordPress, the most noted of which is cforms II. If that’s too much, you can also simply create a separate page that says Contact, and offers an email address there. Or you could simply make explicitly clear that your email address is behind a mailto: link. I’d certainly prefer seeing the inelegant “Contact Me (mailto:)” to the deceptive “Contact Me.”

Of course as just a random internet curmudgeon, there’s little reason for you to follow my advice. I accept that. But don’t tell me I didn’t warn you when you receive an angry email from a curmudgeon like me.

Good

• A New Look — Though I wouldn’t say that all aesthetic changes made to WordPress redound to the good, I’m satisfied. The new colors are nice, the dashboard’s been improved, and everything feels better.
• Much Better Tag Integration — This is a direct descendant of the above point. Now a list of entries shows the tags. Now we get tag suggestions. And the ability to edit tags as a group. All of these are big improvements over the piecemeal support for tags that felt tagged on to 2.3.
• Better Media Integration — Though I’ve heard — and share — some discontent with the new Flash uploader, it’s nice that it was rethought. The ability to easily upload many pictures, and to easily create galleries are nice changes.
• Crucial or Trivial Bonus: Plays nice with Safari/WebKit — Anyone who tried using Safari with WordPress before will understand what a nice change this is. Anyone who hasn’t tried will think this is a silly point.

Bad

• The Bugs — This may be based solely on the fact that I use custom fields, but I’ve been having terrible trouble with both scheduling posts and the unnecessary creation of extraneous drafts. These sins can be forgiven, but I am getting rather impatient waiting for a fix.
• The New Look — A lot of changes to the Write page are for the better, but the dearth of white space on the right side confounds me. Catergories were there previously, and I think there was a number of good reasons for that. Tags, I think, should go there as well. But neither’s there. As I sidenote: I’m not really a fan of this Lucidia Grande business in the editor either.
• Change is Hard  — This is more a personal problem, but a lot of people (myself included) have been and slow to accept 2.5. This innate resistance to change is both irrational, and a waste of time.

I’m certainly not going back, and am even less likely to change blogging platforms, so all of this is essentially trivial. But now you know.