Ikiru Design

Weeks have a way of getting away from me. Last weekend I was thinking I’d get a post up about my first WordPress plugin, a stand-alone implementation of the Kaleidoscope Mini Quilt, by Tuesday. Suddenly I look down and realize that it’s Sunday and I’ve not written such a post and not updated the plugin’s page beyond a goofy first draft.

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.

Are, in rough order of nobleness:

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.

I wrote this back at the end of May 2008 and didn’t publish it. When I thought about posting something similar a few days ago, I was surprised to find this nearly complete set of thoughts. I’ve decided to post this version, and will probably add some further thoughts on the topic soon.

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.

I’ve been thoroughly neglectful about updating this blog over the last few month.

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.

Over the weekend, I decided to finally install a copy of the WordPress trunk — that’s the currently-being-worked-on version for those not familiar with the term. For need of something to write on that new installation, I noted my first impressions of it. It seems relevant to share as the WordPress team is now soliciting advice about its menu structures.

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.