Tag: design

I was lucky enough to corner Tracy Rotton at Contributor Day and bully her into a private “Sell me on Sass!” Class while we were both at WordCamp San Francisco. I’m a hard sell on something ‘new’ not because I hate change, but because I don’t see the point to learn something new in order to do something I’m already capable of doing. But that said, CSS and theme design aren’t my ‘thing.’ I can muddle through, but I don’t love them like I do writing.

In order of my WP skills it goes like this: writing, support, debugging, plugins, themes, databases. See how that goes? So I knew Tracy was big on this stuff, and I realized I had a perfect opportunity to get someone to explain, in a place where I could go “But why do I care?”

Why do you care?

Sass is an extension of CSS3, adding nested rules, variables, mixins, selector inheritance, and a ton of other stuff. For me, the nested rules earned an unimpressed face. Testing things in a ‘new’ way means I have to re-learn how to do things. And being able to define ‘font color black’ and use variables so I only have to change one thing is useless, as I’ve mastered grep and regex. Tracy laughed and then pointed out I could have Sass do the math for me.

Full stop.

If you’ve spent any time designing responsive themes (which most of us do) then you’ve probably run into the extended math part of CSS where you have to calculate font sizes, relative to each other, and then you have to sort out the percentages to make the width and height right and.. Well, I went and read Tracy’s post about saving time with sass later and felt way smarter for it.

But we’re still back to the fact that I don’t theme. It’s not me. So I had all this info and sat on it for a while. In fact, months. I started writing this post during WordCamp San Francisco. Next month is WordCamp Las Vegas. It’s pretty much been half a year.

What changed? MP6, or rather, the removal of MP6 and introduction of it as a core part of WordPress 3.8. Suddenly the plugin was useless. Less than useless, it broke display. So I looked at my options. I knew they were working on a plugin to bring the MP6 styles back, but right now they didn’t have my favorites and I really don’t like all black. I ripped open MP6, pulled out the color-schemes folder, stripped down the colors.php to just the part that added in more options, and thought I was done.

I was wrong. It looked ugly. It didn’t match, it was broken. And there was only one thing left I could do. It was time to get sassy!

What you nee to do this is a Sass ‘App’ – Now Coda 2 lets me edit Sass files directly, but not compile, so basically I have a nice highlighter. Booooring. There are plugins for this, and installing stand alone Sass compilers on my mac is as easy as $ sudo gem install sass which lets me then convert my file ala sass-convert style.css style.scss and now I have a sassy file! The other option, and this was where I ended up, is CodeKit.

Yes, I could use Grunt, Tracy, but I want to learn one things first, understand it, and move to the next. Grunt? Yes, I need to learn it. But right now, my need was to take five scss files and convert them into the right name css files.

What it looks like is plain weird. A scss file is weird. It’s this:

$base-color: #523f6d;
$icon-color: #ece6f6;
$highlight-color: #a3b745;
$notification-color: #d46f15;

$form-checked: $base-color;

@import "../_admin.scss";
@import "../_colors-fresh.css";

And then it looks like this:

@import 'variables';
@import 'mixins';

 {
	background: $body-background;
}


/* Links */

a {
	color: $link;

	&:hover,
	&:active,
	&:focus {
		color: $link-focus;
	}
}

....

Oh wait, it also has this! … No, wait, that won’t work. It kind of goes on like that for a while, like Russian Nesting Dolls, or a TARDIS. But in essence it let me make files where I could define what the CSS became. One file is my ‘define’ file, that was the first one I showed you. The next was my _admin.scss file, which had two more includes and a mess of what looks like CSS, if CSS had variables (which you know it doesn’t).

Look. I can’t, and won’t try to explain Sass. I’d do a crap job, worse than you think I’m gearing up for here. I’ve only been seriously playing with it for about three hours. But in those three hours I went from unimpressed (I’m a hard sell) to understanding. I was able to generate fancy CSS files without have to search/replace. All I did was make a new define file, tell it to output into a folder, and I had my Ectoplasm back.

Will I be using this a lot? Maybe. I can’t say I feel it revolutionizes theming for me, and it won’t for a lot of us. When don’t need to be able to spin up more CSS like this, CSS is something that generally remains static. It should, in my opinion. But the point would not be on the fly fix CSS, but to build out ‘themes’ of CSS. So perhaps for Brian Gardner it might change his world (hi, Brian).

You see, every Genesis Theme comes with color ‘choices.’ Usually these are green, blue, orange/red, and purple. Imagine being able to spin up your own by making one small file, generating the CSS from that, put it in a folder in your child theme, and you’re done. Heck, if someone wanted to get really sassy they could make a plugin that would pull in special Genesis files and folders from your wp-content, much like we have a languages folder today.

wp-content/genesis/themename1/color-style.css
wp-content/genesis/themename2/color-style1.css
wp-content/genesis/themename2/color-style2.css

And so on. That could dynamically be searched for by Genesis and add in more color themes as desired. This way, I can make new styles for my theme without needing a child theme at all, or another CSS editor plugin (which is what I use today – this site is customized by mostly CSS).

But. As Otto rightly points out, this over complicates things. Can’t I just search and replace blue for teal? Sure. But having the scss in the first place means I can look and see the four places I’d need to adjust colors to make it work. Or ten. So I can very quickly spin up a custom design, and I can tuck it away where my client won’t break it.

So no, while I like Sass, and I think it’s incredibly interesting, I’m not really sure that adding code to CSS and requiring compiling will be needed for everyone. Where it’s a major selling point for WordPress core is easy to find. It lets them easily break apart the massive admin CSS files into sections, edit one at a time, and then on ‘build’ pull them all into one file, so we don’t have messy @imports all over the place.

So it’s a good idea for me to learn Sass I suppose. And Grunt. Grunt is next.