Archive for the ‘Ruminations’ category

A Mission Statement

One of the things that I constantly struggle with is the difference between all the different things that this site could, or perhaps should, be and what really drove me to make it in the first place. So this is a small public statement (for myself first and anyone else second) about what this site is and isn’t which will hopefully help me better understand and focus on it’s reasons for existing and what my goals are for it.

If there’s a single reason I maintain a website devoted to working with WordPress, it’s this: WordPress is the best tool that currently exists for internet publishing, and my primary goal today is to be an internet author (and by extension publisher). My goal, with all things I create is to make better WordPress tools that help internet publishers to makes better looking, more approachable internet content. Even if no one but me ever finds value in the things I create and share here, the tools and learning I put here will have helped me to become a better internet publisher.

It’s not about making money. It’s not about making the kind of things that get me copious internet traffic. It’s not about getting people to hire me to do things with WordPress for them. It’s about making better, more approachable, and thus more read, internet sites using WordPress. That’s it.

In Which A Poor Craftsman Blames His Tools

There’s a well-worn maxim very relevant to the life and death of this site: “only a poor craftsman blames his tools.”

The tool we’re talking about here is 2004 Compaq Presario X1000 laptop that has been my primary computer since that year. It runs Window XP, has 1.6 screaming gigahertz, and can barely stay usable if you try to do two things at once. (Don’t even ask about playing Flash videos smoothly.)

I’m too focused on other monetary goals to purchase a new computer until I really need one. But with regards to programming-type activities, I’ve been letting my computer’s deliberateness serve as my excuse to do nothing about getting better at them. This is due primarily to a fundamental misunderstanding of how real work gets done real workers.

Surely, I’m not completely wrong in the thinking that a faster computer running the Mac OS I’ve been lusting over pretty much as long as I’ve had this computer would increase my ability to do these things. Surely Coda’s a nicer piece of software than one can easily find for web design on Windows (especially when you’re unwilling to spend money because you intend to stop using it… sometime). But that’s not really the reason I’ve not gotten better at this internet creating thing.

To extend the opening idea, a craftsman very dedicated to carving wood will do it with rocks if that’s all he has. A man who insists that he can only make something interesting with $4000 of equipment has no real interest in making things with wood. We may be able to say he’s interested in the idea of making things with wood, but no one should be considered serious about a project he isn’t working on regularly. This is the hard truth that I’m still working on learning fully.

The Cascade

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.

Fieldnotes on a WordPress 2.7 Development Build

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.

A Few Weeks with WordPress 2.5

When WordPress 2.5 came out, I was thinking I’d offer a narrative of “how I stopped worrying and learned to love WordPress 2.5.” That ended up being a little dull. Instead, because we’re always told that the internet loves lists — and at this late date it seems unreasonable to offer something more comprehensive — I’ve got a short enumerations of the good and bad.


  • 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.


  • 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.