Enter Kirk. Kirk is exactly the person who I want downloading my themes. After downloading and playing with one of my themes (blog.txt to be specific), Kirk e-mails me requesting some support for some specific but discreet task. I help. I’m happy to.

Kirk files tickets on my theme project pages for things that are broken or could be enhanced. Some I accept, some I don’t. He takes both well. I hear from him now and again. A happy user.

Here’s what separates Kirk from most users. Kirk e-mails me wanting to know how to disable the generator link. For security, he says. Regardless of whether or not I think this improves the security of his blog, I help. I describe the problem and set him off in the right direction.

For this, I make him a simple plugin he can upload based directly on what Peter Westwood documented on his blog. Easy as pie. Took me ten minutes. I slap it into a PHP file and send it along to Kirk knowing he’ll take it from there.

But what Kirk does is, instead of being satisfied after his problem was solved, he shares his experience and provides the solution for others.

Community. Here, here.

Special thanks to Kjell Knudsen for providing the Norwegian translation and the sandbox.pot file. Nokao has been kind enough to provide the Italian translation.

Subversion users can get the latest version from the Sandbox repository:

svn checkout http://sandbox-theme.googlecode.com/svn/trunk/

Kjell was kind enough to provide an outline on how to help translate on the Sandbox project home, Sandbox in Your Language. When you have your .mo and .po files ready to submit, just open a ticket on the Sandbox project home and I’ll email you for the files.

And I’m excited to be opening up the Sandbox to a wider audience—the non-English speaking world. A much wider audience.

Issue 48 resolves the stripping of whitespace in sandbox_globalnav(), the list of pages that occurs in header.php. Thanks to Adam.

Issue 49 resolves a problem with the new wp_link_pages() function parsing incorrectly.

Issue 51 fixes an i18n problem with translation of the text “and tagged” in single.php and attachment.php. Thanks to Lloyd.

Enjoy your holidays.

Please report any issues, bugs, or enhancement requests over at the Sandbox bug tracker.

If you’ve been watching the repository, you’ll also have noticed that in the 1.0 version, the previously packaged ‘skins’ have been changed. Instead they are separate downloads and are their own ‘theme templates.’

Additionally, you may have noticed that the packaging of Sandbox with WordPress has been slated for the 2.4 release and will be sadly missing from 2.3. Sigh. Yet if WordPress development continues at its break-neck rate that only means a delay of three months.

And we’re all quite aware of the pace I manage to work at.

If you’ve been watching the Sandbox repository, you may have noticed two branches now existing: v0.9 and v1.0. Let me explain.

Version 1.0 is designed specifically for WordPress 2.3 and utilizes its native support of tagging. That means additional semantic class names for tags. Additionally, there had been a number of functions that had to do a bit more work since they had to work seamlessly with WordPress versions 2.0.x, 2.1.x, and 2.2.x. Those have been simplified to be 2.3-specific. All deprecated tags have been dropped, too.

Version 0.9 is exactly the same as 1.0, except it retains some of those exotic functions and works with pretty much any WordPress version (at least 2.0.x and later). It doesn’t have any incorporated native tagging support. This version will remain around so that 2.0.x legacy users will be able to use the Sandbox as well.

For fun I’ve also added the milestone versions from v0.1 to v0.8 in the repository. These are quite entertaining if you’ve been following the development of the Sandbox for the past 13 months.

Finally, there are some bugs in v1.0. Mostly with tags. As developing for pre-release software is rather difficult, I’ve found.

You thoughts and comments on where the Sandbox stands are welcomed.

So before the release is finalized and designers of Sandbox “skins” begin receiving e-mails from confused, I thought I’d provide an working example of what has changed in versions and how it may apply to your skin.

First, to avoid confusion, let’s settle on the term “design” for what was previously called a skin. Why? It’s just a request. Call it whatever you what. It’s semantics, after all.

Anyhow, I first suggest you, designers, check out revision 24 in the Sandbox repository. Compare the changes in the Kubrick CSS file with the previous revision. That should give you an idea of what updates you might have to make due to changed structures and class names.

And of course, let me know what you think of the changes so far. Since May 5, 2007, I’ve managed to drop 20 commits on the Sandbox. It’s gotta be done sooner or later.

Have a look at the working copy of the source, tentatively for version 8.0, in the Subversion project home on Google Code.

I’m aiming to simplify things, but perhaps am a bit snow blind at this point. So how’s the markup? Let me know.

There are a few I’d like for more WordPress theme developers to consider standardizing across the board.

First of all, they are classes, so they shouldn’t semantically impact the content. This is important because if, in the future, some person shockingly decides to change themes, the content of their posts isn’t affected.

Image classes

First of these class would be image positioning classes: .alignleft, .alignright, and .center. Since the positioning and/or float of images should be determined by CSS in XHTML, I think these are probably the safest special classes to agree upon.

img.alignleft {
   float: left;
   margin: 0.5em 1em 0.5em 0;
}

img.alignright {
   float: right;
   margin: 0.5em 0 0.5em 1em;
}

img.center {
   display: block;
   margin: 0.5em auto;
   text-align: center;
}

I deleted the img element prefix from the descriptors above because I agree with Adam’s comment below. Still not sure about what to do about content columns.

An all-caps class

Another that I noticed first in Kubrick and have since seen all over the place is span.caps. I’m not sure why this came about, but I find it useful enough. It’s purely presentational.

span.caps {
   font-variant: small-caps;
}

This could also be text-transform:uppercase; with essentially the same use. A per theme choice, I suppose.

XFN relationship classes

I’m also adding XFN link classes to my theme revisions. Why? Because I’m fascinated with Microformats, frankly. I found these great microformat icons, notably the XFN relationship icons.

Now, there is a more technically accurate way to style links with XFN relationship attributes, as noted on the XFN intro page:

a[rel~="friend"]{
   background: url('xfn-friend.png') no-repeat center right;
   margin-right: 2px;
   padding: 2px 26px 2px 0;
}

But this, of course, requires the browser to be whooly CSS 2.1 compliant, i.e., handle CSS attribute selectors. And can we guess which browser doesn’t do this? (If you guessed IE, then you already knew the answer.)

Using attribute selectors in CSS can cause IE do all sorts of strange things, like ignore any inline selectors and following descriptors. Which means that not only will CSS not display an icon (as is set above) but might also screw up following CSS selectors. It’s touchy.

So this is my compromise. Which is fine, and forward-compatible:

a.xfn-friend {
   background: url('xfn-friend.png') no-repeat center right;
   margin-right: 2px;
   padding: 2px 26px 2px 0;
}

The downfall of this is that it would be undermined if the link had the class but not the rel="friend" attribute. Which would be deception by icon.

Anyhow, those are just the most minor of things I’ve been considering and I’d like to hear what others had to say on the subject.

This theme does some neat things. It has a PHP-generated gradient image for the banner now. But let me just say it doesn’t do it very well. I just got bogged down in this bit of code and frankly think that this is about the least elegant aspect of this theme.

Any suggestions? Poke around the source and please let me know how I might make this better. Otherwise, the theme is looking pretty good and will just go through minor revisions (I hope) at this stage.

Yesterday I caught Ryan Boren’s post about a new theme function, language_attributes(), which adds xml:lang and dir= attributes to the html element. Nice.

I’m working to get my themes working with both 2.0.x and 2.1. I came up with this simple solution to keep things working between versions:

<html xmlns="http://www.w3.org/1999/xhtml" <?php if ( !function_exists('language_attributes') || language_attributes() ) : ?>xml:lang="en-us" lang="en-us"<?php endif; ?>>

I invented the conditional PHP call. Right then. Copyright pending.

1. Sandbox skins/menu
2. The #globalnav option
3. Improving semantics
4. Simplify, simplify, simplify

1. Sandbox skins/menu

   The first question at hand is, why do we need a Sandbox Skins menu? There are issues related to the minimalist skins using @import to piggy-back off the main style.css, but perhaps we can do away with this menu and place the layout CSS in snippets in the readme.html.

   There’s also the possibility of changing the Sandbox Skins menu to become a Sandbox CSS menu, where CSS is added just like on WordPress.com blogs (with the upgrade). You can input and edit your CSS for the Sandbox. The CSS output would be immaculate and consistent.

   As we began talking about possibilities here, I was working on getting a site up for Sandbox skins. I’ve paused for the moment, though I know it will still be useful for the Sandbox, because we’re question how the Sandbox uses skins. What do you think?

   There are already quite a few skins for the Sandbox available:

   • Adam’s Unsleepable
   • Reaper-X’s ChinaRed
   • And Reaper-X’s X-Cuberik
   • Trevor’s k2 lite
   • Wank’s unique The Literary Life
   • Zeo’s Sandbox K2

   Keep in mind that these were all completed within seven days of first release of the Sandbox (and those are just the ones I found). Seven days with changes to the Sandbox? Well done all, and take that, Blogging Pro.

2. The #globalnav option

   Anyhow, we’re also wondering if we should just remove the “Global Navigation” option as set in the skin .css file. Perhaps we should just fix it there. It seems that part of the Sandbox beauty is making CSS “conditionals” with the dynamic classes.

   Could the same results be produced with CSS alone? Without necessarily making it a hard-coded option?

   In case you’re not familiar with this, there is an option for skin developers to set a “Global Navigation: Y/N” in the skin .css file. This allows the theme to produce a list of pages below the header and before the content. Blogs on WordPress.com using the Sandbox will always have the #globalnav enabled.

3. Improving semantics

   How can we improve the markup and the semantic nature of the Sandbox theme within the context of WordPress and blogging? Along these lines, we want to take advantage of sound standards (e.g., XHTML tags, XFN, hAtom).

   We’ve tried to make the Sandbox as semantic and forward-compatible as possible. The dynamic classes and the overall structure of the Sandbox make it friendly to beginners, actually. Not having to deal with PHP and focus on CSS (and images, too) is a great benefit to learners. So what are we forgetting? How could we improve the Sandbox’s semantic nature?

4. Simplify, simplify, simplify

   Andy said to me recently, A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away. Andy was, actually, quoting Antoine de Saint-Exupery. Both of them are correct.

   I’m always up to cutting stuff out. I despise bloat. This just increases the learning-curve and complicates its functions. This is a quesiton, but it’s also a context to consider when looking at the Sandbox. How can we make this whole process simpler? How can the user experience be more enjoyable?

   As I mentioned in my previous post, I think skinning the Sandbox is quite a lot of fun. It’s nice, for a change, to just use CSS and design something clever, creative. This is what we want to encourage: enjoying. So as we approach 1.0, how can we improve the Sandbox so that is enjoyable for the largest group possible? And yet remains terribly simple—on the inside and out.

5. And . . . ?

You’ve read though this. Now, get a cup of coffee or tea, have a smoke, whatever, and come back with your ideas. You’ve seen, hopefully, that Andy and I value your ideas and feedback. So bring it.