The CSS-Tricks License | CSS-Tricks

The CSS-Tricks License is one of the most delightful (and funny, and, yes, thoughtful) open licenses I’ve ever seen.

I don’t give two hoots what you do with any of the design or code you find here.

Actually, I do. I hope you take it and use it, uncredited, on a super commercial website and get wicked rich off it. I hope you use it at work and your boss is impressed and you get a big promotion. I hope it helps you design a website and that website impresses somebody you think is super hot and you get married and have smart, chill babies. I hope you use the code in a blog post you write elsewhere and that website gets way more popular and awesome than this one.

And it goes on from there. Every word is about the spirit of the thing, not just the fine print. Oh, yeah.

Why can’t there be about five of me today?

I would like to sit outside in the sun and noodle around with code & music. I would like to deep-dive into some project where I’ll get completely absorbed and lose all sense of time. I would like to dig in the garden and get a headstart on weekend plans. I would like to watch the ACC tournament. I would like to knock things off lists like a boss and make people happy.

All good spring days to have, but somehow I think making them all happen at once is sci-fi stuff.

Woody Guthrie on copyright

This song is Copyrighted in U.S., under Seal of Copyright # 154085, for a period of 28 years, and anybody caught singin it without our permission, will be mighty good friends of ourn, cause we don’t give a dern. Publish it. Write it. Sing it. Swing to it. Yodel it. We wrote it, that’s all we wanted to do.

Introducing sassy_s

I’ve been using Underscores (aka _s) for all my base theme needs since pretty much the day it came out. And I’ve been using Sass for more and more projects — so, inevitably, I started smooshing the two together.

Sass actually makes it really easy to do this, at least if you use the default .scss format. All valid css files are also scss files; you can just take your css file, change the file extension to .scss, and start throwing around variables and functions and all that Sassy stuff. But while it’s easy to get a project rolling that way, it leaves something to be desired organization-wise.

One of the very cool things about Sass is that it assumes that you’ll work with multiple files (partials, in Sass-speak) and compile them into one at the end; renaming the big stylesheet and working from there like I’d been doing still left me searching through a lot of lines of code to find what I needed. Ideally, I’d have a file for menu styles, a file for media styles, and so on. Even better, I’d be able to drop in a file of my own favorite mix-ins without recreating them for each project. I always set up my color schemes first thing, my base fonts and line heights, set up clearfixes and assistive text the way I want them, set up common styles for borders and boxes and the like; the values change, but what I’m styling has a lot of the same structure from project to project. (That one’s not included in the repo, but I’d love to hear about other people’s favorites.)

So to make more lazy level up my own practice, I finally took the time to make all this into a properly organized repo. Y’all can grab it here:

A couple of notes:

  • sassy_s is just a refactoring of the stylesheet — not a complete starter theme. It’s designed to work with a copy of _s, not replace it.
  • I’ve provided links to a couple of beginning Sass tutorials, and a couple of inline examples, but there are lots of great resources out there for installing and using Sass. If you have Sass questions, they’re the place to start.
  • The sass --watch command will overwrite your style.css with every change. Start with a fresh copy of Underscores and copy over your style.css header first. Don’t add this to a theme you’ve already made (unless you’ve got it under version control!)
  • If you’ve heard that you can’t use Sass if your end-users don’t run Ruby on their servers, fear not! In almost all cases, you should be running Ruby and Sass on your development machine, then exporting your Sass to a normal CSS file. It’ll run just as well as any other theme.

Diaries of a Core Maintainer #6: A tale of two developers |

Sloppy Sam is a hobbyist, who has been coding PHP off and on for a few months. One morning, she gets an idea for a new feature for Drupal core. She begins by searching the issue to see if something like it exists already and, finding it does not, posts a new issue with a general description of her idea. She then opens her IRC window and asks in #drupal, “Hey, folks! I had an idea for a new feature for core that [brief summary]. What do you think about this? [link]”

via Diaries of a Core Maintainer #6: A tale of two developers |

I have a feeling this is a post I’ll be coming back to often.

A very short photo essay


I’m not much for unboxing shots, but this the box the Raspberry Pi came in, next to a normal-sized laptop for scale.


The house has working doors for the HDMI and ethernet ports. This amuses me way more than it probably should.


Tiny computer installed in tiny ranch house. The doors are cute and all, but the hinged lid is actually the part I’m most proud of. Most of the Lego cases I looked at are either permanently bricked-in, or have a lid you have to pop off, which for me usually means rebuilding half the structure.



2012 Review, 2013 Look-ahead

At the beginning of 2012, I did a soft reboot of this blog with the intention of using as a log for a daily practice of contributing to WordPress, no matter how small the day’s contribution: it could be as small as helping a beginner user with an easy (for me) question, or as big as a patch on a new feature.

I didn’t do so hot with the daily logging part, but the rest turned out pretty well:

  • I contributed code to WordPress 3.4 and 3.5, and I’m busy thinking about what I can do for 3.6.
  • I was named a Recent Rockstar for the 3.4 release, and you know I saved screenshots of the credits screen.
  • I was invited to the first WordPress Community Summit, which was an incredible honor and a bit of a life-changer.
  • I gave my first conference talk at WordCamp Raleigh, about making the move from being a committed user or dev to being a community contributor — and including all kinds of roles in “contributor”.
  • Outside of WP-land, I was selected to attend the Ada Initiative’s AdaCamp DC conference. Between that and the Summit, I had two conferences this year that really expanded my views on what we do in open source and open culture, how our communities can make a foundation for that work, and my own place as a part of all that.

Looking ahead to 2013, I’m looking toward a mix of stepping up technical skills and turning everything I did last year into stuff that benefits people other than just me:

  • This is the year I really, seriously, learn JavaScript. Not just cute bits of DOM manipulation, but the stuff you build apps with. Turns out it’s a really cool language.
  • I want to speak more. I want to polish up the community stuff, and also add at least one technical subject to the list of subjects I can talk about.
  • Release more code in public. Whether it’s paid or free, the fact is that I do better work when it’s not just hidden away in the back end of a single site.
  • Find a team, part 1. I don’t yet know what form this will take: whether it means looking for a job or redirecting my freelance work toward bigger projects with distributed teams, but I do know that solo projects are limited projects compared to what I can do with good partners.
  • Find a team, part 2. As an outgrowth of the Community Summit, a new WordPress Community Outreach team was founded, and we’ll be starting up in the new year. Don’t worry — I’ll still be working on core code and reviews, but the Community team is an amazing mix of all the empowerment and outreach and learning ideas that drew me in to Open Source in the first place… of course I’m all over that!
  • Blog more. Duh. Maybe I’ll try logging some of my contributions.

A short rant for theme developers

If you’re making a design for someone other than yourself or your client, use fonts that work in languages other than English. If you’re making a theme for public distribution, pick something that at least includes extended Latin, and preferably has a few other alphabets as well.

Hell, if you’re making a design just for yourself, use fonts that work in languages other than English. You can be the most monolingual American on earth, and the minute you copy/paste something that’s a little more worldly, all those accented characters will fail over to your fallback font. It looks awful. It looks unprofessional. And it looks like you haven’t considered any audience that isn’t just like you.