On theme typography and language detection

As both a font geek and a theme geek, I was of course happy to see Drew’s update on typography in Twenty Twelve. But the part that really made me happy was this bit:

I had some concerns about the default web font settings. What about non-western languages? Those users would be out of luck if we had Open Sans turned on by default. They would see a bunch of empty space and garbled characters when they switched to Twenty Twelve. Not a very accessible or friendly experience.

So what to do? I proposed turning Open Sans off by default, and allowing users to switch it back on from the Theme Options menu. Nacin jumped in and suggested we use language detection to turn the font on or off. Non-supported languages would have the font turned off by default and supported languages would have it turned on. Nacin’s idea represented the best of both worlds — awesome!

I spent an entire past career worrying a whole lot about multi-language computing: encoding conflicts, crappy character rendering, input methods, and everything else that comes with it. And as much as I love the brave new world of web fonts and play with them on any project where I can find a reasonable excuse, it distresses me to see how many widely-used web fonts don’t even bother to support the extended-latin range, let alone any other alphabets.

(Open sans has extensive Greek and Cyrillic — not just Russian — support, in the condensed variant as well as the text. I’m such a hopeless sucker for a good condensed.)

The detection/default trick is even cooler, and I’d love to see a similar approach to smart default-setting become a common practice. The option to change it is there, even if the average English-speaking user never stops to think that it’s for anything other than aesthetics or load time: but the theme is making a reasonably intelligent stab at rendering the site without ugly mystery characters from the very first load.

We are all noobs

Michael reminded me of this:

https://twitter.com/#!/tw2113/status/201006820070920193

but as you can see if you go follow the ensuing twitter conversation, it’s a rant that I can go on about for way more than 140 characters. So I will.

It’s incredibly common for people in any kind of support environment, or really any kind of tech learning space, to start off a completely reasonable and intelligent question with “hey, so I’m a total n00b, but…” and end even even a perfectly successful interaction with “oh god I’m such an idiot”. And I’m pretty sure that it’s all down to one really, really bad assumption and the consequences that follow from it:

  • The world is divided into two kinds of people, which for now I’ll call noobs and rockstars1.
  • Since there’s nothing in between the two, there must be some kind of infinite gap.
  • So a noob must obviously be a horrible thing to be.
  • Therefore, ohmygodohmygod I suck.
  • If I have a totally reasonable question, I need to crawl in to the channel/forum/classroom and immediately show my belly like a puppy afraid of being savaged.

And they have some very good reasons to do so. People can be real assholes, and nerd spaces have a longstanding rep for being incredibly unforgiving about any perceived stupidity. So playing submissive puppy is an understandable response: after all, why would you want to expose yourself to getting ripped apart by the pack?

It’s not just in support venues, either. If it weren’t for this kind of attitude, we wouldn’t have huge-selling book series on “… for Dummies” and “… for Complete Idiots”. (No offense to friends who have published in both series!) We certainly wouldn’t fall back on tired old tropes like “so simple your mom can do it” — aside from the nasty sexism, it assumes that there’s a whole class of non-technical people out there who are just fundamentally  incapable of getting anything hard.

And so if I think (or just secretly fear) that I’m on that side? Yeah, you bet I’m going to feel like the mere fact of having a question is something deeply shameful 2.

Meanwhile, for rockstars, the whole noob vs. rockstar thing is just as destructive (if not quite as obviously so at first: after all, they’re on the winning side of the equation). If it’s only the noobs who need to ask questions, then if I admit my ignorance on anything, I must secretly be a noob! Oh the shame! Better just not ask and admit weakness… And that way lies a nice self-defeating case of impostor syndrome, for the less confident among us; or the kind of junior dev arrogance that Garann talks about, for the otherwise inclined.

The fact is, learning doesn’t happen without a lot of painful and embarrassing bumping up against the stuff we don’t know, and it’s neither easy nor comfortable to be in that position. I’d even go so far as to say that’s why we learn: the sense of accomplishment that comes from mastering something you couldn’t handle an hour or a decade ago is a powerful driver to get through a painful process, but on an even more basic level, no longer having that awful pit-of-the-stomach feeling is even more so. Unless we’ve convinced ourselves that it’s impossible; in that case, most people just give up and avoid whatever it is that’s making them feel this way.

You’re a noob. I’m a noob. Hell, I’m a noob about all the things that people sometimes try to call me a rockstar about. We need to stop dividing up the world this way. And don’t let me catch you saying things like that about your mother.

  1. I have just as much of a problem with the “rockstar” side of the equation, but that’s a different rant
  2. The flip side is the bully who fronts expertise by calling other people noobs. If you haven’t figured it out yet, don’t do that.

Backwards compatibility for WordPress 3.4 headers and backgrounds

As I mentioned in the previous post, the new versions of WordPress custom headers and backgrounds have some great new features, but they require WordPress 3.4. That’s no problem if you’re already steering your custom development towards 3.4 (and you should be), but if you’re building themes for distribution, you can’t be sure that all your users are going to upgrade on the first day or even month.

Michael Fields, Automattic Theme Wrangler and all-around smart theme guy, pointed me toward the latest version of P2, which has a rather nice way of handling the backwards compatibility issue for just this case: (This function is called within theme setup)

function p2_setup_custom_header() {
	$args = array(
		'width'               => 980,
		'height'              => 120,
		'default-image'       => '',
		'default-text-color'  => '3478e3',
		'wp-head-callback'    => 'p2_header_style',
		'admin-head-callback' => 'p2_admin_header_style',
	);

	$args = apply_filters( 'p2_custom_header_args', $args );

	if ( function_exists( 'get_custom_header' ) ) {
		add_theme_support( 'custom-header', $args );
	} else {
		// Compat: Versions of WordPress prior to 3.4.
		define( 'HEADER_TEXTCOLOR',    $args['default-text-color'] );
		define( 'HEADER_IMAGE',        $args['default-image'] );
		define( 'HEADER_IMAGE_WIDTH',  $args['width'] );
		define( 'HEADER_IMAGE_HEIGHT', $args['height'] );
		add_custom_image_header( $args['wp-head-callback'], $args['admin-head-callback'] );
	}
}

Elsewhere in the theme setup function, P2 also uses:

	$args = apply_filters( 'p2_custom_background_args', array( 'default-color' => 'f1f1f1' ) );
	if ( function_exists( 'get_custom_header' ) ) {
		add_theme_support( 'custom-background', $args );
	} else {
		// Compat: Versions of WordPress prior to 3.4.
		define( 'BACKGROUND_COLOR', $args['default-color'] );
		add_custom_background();
	}

That’s taken direct from P2 — you’ll have to make adjustments for your own themes: change the slugs, set up the options you want to use, etc.

I can’t think of any reason you couldn’t wrap both function_exists() checks into one conditional, but I’m inclined to keep them separate — it’s easier to read, easier to override in child themes, and if one extra check is a performance concern, it’s time to add a second hamster to your hamster wheel…

(On the other hand, I’m not a fan of holding on to backward compatibility beyond a couple of core versions back. There are a lot of themes out there still checking if widgets are supported, and at that point it’s just cruft. Be nice to your code.)

Flexible headers in WordPress 3.4 themes

As of WordPress 3.4 Beta1, theme authors can allow custom header images with flexible heights, widths, or both.

In other words, instead of being limited to a fixed size determined by the designer, as you’re already familiar with:

With flexible headers, you can allow users to upload smaller or larger headers without having to make a child theme or (worse) hack your theme, like so:

How to do it:

Image header support in 3.4 no longer uses all the constants that had to be defined in previous versions — HEADER_IMAGE_HEIGHT, HEADER_IMAGE_WIDTH, HEADER_TEXT_COLOR and the like are now gone. Instead, all the header support options are included in a single array, and enabled with a call to add_theme_support() in your theme’s functions.php file.

This is how the array looks in the theme I used for the screenshots above:

// Add support for flexible headers
 $header_args = array(
 'flex-height' => true,
 'height' => 200,
 'flex-width' => true,
 'width' => 950,
 'default-image' => '%s/images/headers/path.jpg',
 'admin-head-callback' => 'mytheme_admin_header_style',
 );

 add_theme_support( 'custom-header', $header_args );

If flex-height or flex-width are not included in the array, height and width will be fixed sizes, replacing the old HEADER_IMAGE_HEIGHT and HEADER_IMAGE_WIDTH. If flex-height and flex-width are included, height and width will be used as suggested dimensions instead.

Don’t forget to remove any references to the old constants in your template files — in my header.php, I simply replaced.

<img src="<?php header_image(); ?>" width="<?php echo HEADER_IMAGE_WIDTH; ?>" height="<?php echo HEADER_IMAGE_HEIGHT; ?>" alt="" />

with:

<img src="<?php header_image(); ?>" height="<?php echo get_custom_header()->height; ?>" width="<?php echo get_custom_header()->width; ?>" alt="" />

For reference, here’s the full set of options and their default values, as found in /wp-includes/theme.php. Note that the other header image options like text, text color, and randomization are available in the same add_theme_support() call by setting only the options you need:

$defaults = array(
'default-image' => '',
'random-default' => false,
'width' => 0,
'height' => 0,
'flex-height' => false,
'flex-width' => false,
'default-text-color' => '',
'header-text' => true,
'uploads' => true,
'wp-head-callback' => '',
'admin-head-callback' => '',
'admin-preview-callback' => '',
);

A few important notes:

  • Flexible header support has to be built into each theme – it will not work automatically with your pre-existing themes.
  • This functionality requires WordPress 3.4, which is currently in beta. You can grab the latest here (.zip file). Please use it for testing and development, but don’t run it in production unless you know what you’re doing and have some risk tolerance.
  • Design-wise, flexible heights are relatively easy; flexible widths are much trickier to work into a layout while still looking good. Experiment!

Aside

As a quick followup to the previous licensing post, and in light of the current discussions on WordPress plugin licensing, I’ve decided to use MIT license for packaged code and Public Domain for code samples in posts from now on. None of this invalidates my previous argument, of course — pick a license, understand what it does, and unless you’re developing a whole new license for some excellent reason, don’t make up your own weird terms that downstream projects can’t easily work with.

Against DIY Licensing

Because my FOSS1 work is mostly WordPress these days, my baseline is the GPL. GPL is far from the only license out there, but — and this is the key point here — it’s widely used and (at least more or less) understood.

The GPL comes with a provision that derived works must also be GPL-licensed2, so I spend a certain amount of time hunting down whether some bit of code I want to use can legally be incorporated into such a project. And we do the same thing when reviewing themes: everything that goes in the WordPress.org repository has to be GPL-compatible, so all those nice textures and icons and webfonts that can really make a theme stand out have to be compatible as well.

Note: Compatible.

Not everything in the open-source universe has to be, or should be GPL. But everything that goes into a GPL project has to play well with the GPL.

There are wide swaths of the open-source world for which GPL is too restrictive, and people working in those areas tend to go for permissive licenses like BSD or MIT, or release their work into the public domain outright. And that’s awesome. For some kinds of projects, it’s way more appropriate than a restrictive license. If what you’re releasing is the code equivalent of infrastructure, it will not be useful, and will not spread, with a lot of restrictions on how it can be distributed. Permissive licenses are great for libraries, glue, shims, resets, and all that magic stuff.

Creative Commons – for content, not software – is absolutely one of the more brilliant ideas ever to come along. But remember, there are at least half a dozen such licenses, and they range from totally free, no rights reserved, no restrictions of any kind at all, all the way up to You Can’t Touch This3.  Occasionally people pop up in the theme review mailing list or IRC channel and ask “is a CC license okay”; much more often, people put things out there that just say “CC licensed”, which isn’t properly licensed at all. If anyone’s going to use the stuff, we need to know which rights you’re actually licensing.

Free-as-in-speech fonts finally seem to be standardizing more and more on the SIL Open Font License, no doubt thanks to the runaway success of Google Webfonts; the move to standardization makes things nice and easy. It’s also a nice license: quite permissive and GPL-compatible, and designed for the way fonts are actually built and used.

Notice that the above licenses are really far apart in what they allow, and (free software being chock full o’ free software people as it is) we occasionally have full-scale wars about which one is better. But also notice one similarity: they’re all well-known, widely used, documented. They’re suited to particular purposes: If you want your code used absolutely everywhere without any barriers, use a permissive license; if you want to spread the free software gospel, copyleft. The common licenses are standards, in a way. I know without having to put my project aside for a side trip to the local law library that I can incorporate MIT-licensed code in a GPL project, and also that I can’t do the same if I’m going the other direction. I know that I can package up a theme with a CC-0 photo, but not with one that’s CC-BY-NC-ND.

And ultimately, I don’t care all that much which one you choose — I’ll give you the benefit of the doubt and assume that you chose the path you did for reasons that you knew and fully understood at the time. I just want you to choose a path that allows me to understand how I can and can’t use this thing.

But instead, I keep seeing handmade and non-standard things like4 :

License:
- you can freely use it
- you can freely distribute sourcecode
- you can freely modify it as long as you leave my copyright/author info in source code
- if you developing closesource application, you should add my name at least to “about” page of your web application
- if you create an amazing modification, please contact me… I can publish link to your webpage if you’re interested…
- if you want to use my script in commercial application for earning money, you should make a donation to me first

Or5 this one:

- All themes are free to use as long as you leave the credits links unchanged in footer.
- You cannot claim our themes or modifications of these themes as yours.
- You cannot modify our themes and distribute them on your website.
- You cannot sell our themes for others.
- We does not allow you to use our themes for websites or individuals that participate in warez, hacking, cracking, malicious computer crime or fraud, or any other material or activity that is illegal.
- We does not allow you to use our themes for websites or individuals that participate in porn, gambling, poker, insurance, forex….

And here’s the thing. After seeing untold dozens of such licenses, I don’t even bother to study them and puzzle out if they’re maybe possibly compatible any more. If the developers actually wanted their stuff to be used, they would’ve made it so, and saved themselves a lot of time thinking about exactly which page a linkback needs to be on, or what list of industries they find too icky. Having actually read a bunch of these, they’re never okay to use in projects or put in the repository, and in the current climate, there is always another library or another template out there. Always.

(And on a personal note, for doG’s sake, please don’t call your homegrown terms a EULA. That does not impress or inspire. It just makes me think of 50-page-long click-through legalese from Sony or iTunes.)

  1. Fuck it. I’m saying “open source” from now on. Because it’s English words. Feel free to substitute your terminology of choice.
  2. Leaving aside all connotations of good and evil, this is exactly the replication mechanism of a virus, or more precisely a meme (using the original definition). Cool!
  3. AKA No-Derivatives.
  4. Hey, pay me and I might give you a linkback!
  5. Don’t use my stuff for pr0n!

Plugin: Blogify Posts Menu

I hate “Posts”. Oh, I don’t mean that I hate posts, and in fact I’m kind of in love with making more of them now that I’m finally getting back in the habit.

No, I mean I hate the thing in the WordPress menu that says “Posts”, because when I’m looking at the menu for what to click, I’m thinking, “I want the blog”. And because I’ve seen about a bajillion new users get really, painfully stuck on Posts and Pages and What’s the difference, and How do I know which one to use, and even after explaining, still just want to know, “but how do I post to my blog?”

When it happens that consistently, it isn’t a problem with the users. They’re simply telling us that we need a better label.

This plugin changes the label. No muss, no fuss, no configuration needed. Scratch your own itch, or add it to your standard bag of tricks when building sites for other people. Grab the plugin and more details at the WordPress repository or on the plugin page.