Tag Archives: CSS

Responsive Design

I’ve been playing around quite a bit with responsive web design the last few days as a result of a recent client requesting their new site be mobile-friendly. I’ve had to read up quite a bit on responsive design, but I’ve learned a lot both about what makes it a powerful tool to have and also about the various frustrations and pitfalls that come with designing a site that’s mobile-friendly. Not all themes make good candidates for responsive design, as I quickly discovered.

Responsive design is something I haven’t been altogether concerned about with my own sites since I was more or less content to default to the Jetpack mobile theme that comes bundled with that plugin. Building this design for my client, I realized how nice it would be if my own site was more mobile-friendly and customized to match my current style. So, yesterday, I rolled out version 2.1 of my theme.

responsive

If you’re viewing this on your mobile device, you should see a layout similar to the one above. This version of my site also got a couple of simple tweaks to its layout. I put a new social media bar at the top of the page for those links as well as for the search form, which frees up some real estate in my nav menu and sidebar. Everything else is built with relative dimensions, so the site should scale well on most mobile devices. The desktop and smartphone layouts work pretty seamlessly; some tablets may see a bit of jankiness. As it turns out, building a layout that accounts for every viewport size on every device is a large and daunting task. I’m not entirely convinced I’ve got everything in the middle quite right. If you see something odd on your device, I’d appreciate it if you could shoot me an email with a screenshot and the device you’re using so I can try to correct any issues.

That said, I’m chuffed about the updates to the mobile feature set of my site. Responsiveness is something I’ve had way in the back of my mind for a little while, but I honestly thought it was going to be more difficult to implement (i.e. building a whole separate theme; I didn’t even know media queries existed until this week) than it actually ended up being.

Next iteration of the site will be almost completely behind-the-scenes: shifting my stylesheet to SASS.

Designing with SASS

This past week, I ported the stylesheet for a web design project I’m currently working on from the traditional stylesheet to one formatted with SASS. And holy crap, y’all, how have I not started doing this sooner?

I’d heard about CSS preprocessors a little while back, and shortly after that WordPress added support for both SASS and LESS. Since I wasn’t working on any design projects at the time, I didn’t devote any attention to learning more about them. But I did read a couple of brief overviews, and a couple of items piqued my interest. The first was the ability to use variables to set a value once, use it multiple locations in your stylesheet, and then be able to change all the values at once simply by adjusting the value of the variable. This is a particularly handy tool with colors, since many elements in a site design use the same color values. Where before you might have:

.example {
     color: #ffffff;
     }

With SASS, you can create a variable called $font-color: #ffffff; and use it in place of your color value, thusly:

.example {
     color: $font-color;
     }

Now you can use the $font-color variable on any element that will use the same color in your design, and if you decide later that a different color will work better, just swap the value in the variable and the preprocessor will apply it to every element. Huge timesaver, that.

Another thing I appreciate about preprocessors is the ability to nest styles. Child elements in the nest automatically receive the parent classes, selectors, or identifiers in the rendered output. This eliminates the need to type those identifiers repeatedly the way you would in traditional CSS and makes your stylesheet easier to read. Instead of:

.main-navigation {
     margin-top: 5px;
     }

     .main-naviation ul.nav-menu, .main-navigation div.nav-menu > ul {
          border: 0;
          }
	
     .main-nvaigation li {
          font-size: 1.5rem;
          }

You can nest your elements like so:

.main-navigation {
     margin-top: 5px;
	
     ul.nav-menu, div.nav-menu > ul {
          border: 0;
          }
	
     li {
          font-size: 1.5rem;
          }
     }

The preprocessor then renders the output like this:

.main-navigation {
    margin-top: 5px; }
    .main-navigation ul.nav-menu, .main-navigation div.nav-menu > ul {
      border: 0; }
    .main-navigation li {
      font-size: 1.5rem; }	

Again a huge timesaver.

One of my other favorite features is the ability to split the stylesheet out into individual files, which the preprocessor then builds during processing. There’s still only the one HTTP request, and so any overhead normally incurred from the @import call is eliminated. For my project, I broke my stylesheet in six smaller files — one each for my variables, site body, header, content area, sidebar, and footer. Breaking my stylesheet down this way accomplished two things: 1) it made my stylesheet more manageable by reducing the amount of scrolling I needed to do, and 2) it made it easier to organize the elements for each individual section. At the final result, my based stylesheet ended up looking like this:

/*
 Theme Name: New theme
 Theme URI: newtheme
 Description: Twenty Twelve child theme
 Author: Jim Stitzel
 Author URI: http://jimstitzel.com
 Template: twentytwelve
 Version: 1.0
*/

@import url("../twentytwelve/style.css");

@import 'variables';

@mixin search-border-radius($radius) {
	-webkit-border-radius: $radius;
	   -moz-border-radius: $radius;
	    -ms-border-radius: $radius;
	        border-radius: $radius;
	}


@import 'body';
@import 'header';
@import 'content';
@import 'sidebar';
@import 'footer';

Technically, I could have split off the mixin into its own file, as well, but since there’s only the one, I opted to leave it where it was.

As I said above, WordPress now includes preprocessor support for both SASS and LESS inside its Jetpack plugin. You can also use a desktop preprocessor, like Koala, to do all the heavy lifting and then just upload the final stylesheet to your site.

I’m very pleased and happy with the result of my first experience with SASS. It has already saved me a lot of time and effort, and I plan to use it for every design I do in the future. If you want to read more about either SASS or LESS, I highly recommend you check out their respective sites. It’ll change the way you design.

Hiding Facebook’s App Ticker

Facebook has rolled yet another obnoxious feature with no user option to disable it — the App Ticker. Apparently, some folks have seen it for a week or so now, but it only just showed up on my profile today. I’ve been using the wonderful Facebook Fixer script for the Greasemonkey addon to tweak the way my Facebook looks, but they haven’t rolled out an update to deal with the App Ticker. Fortunately, Facebook Fixer has a custom CSS area, so I used Firebug to identify and remove the elements of the App Ticker and the white space behind it. For those who also use Facebook Fixer and want to plug in the custom CSS for themselves, I’ll save you some time and post the code I used.

.fixedAux { display: none; }

.ego_wide .hasRightCol #contentArea { width: 1005px; }

You’re welcome.

Code Geek

I am a WordPress god! Ok, not really, but I _am_ enjoying the fact that I can now manipulate a WP theme pretty easily. It’s true – the more you use CSS, the more you play around with web design, the better you get at it.

I host a number of different websites for myself and for friends on my shared account, and I’ve been helping a guy who maintains one of those sites tweak a WP theme to force it to behave. He’s done most of the actual template work, taking an existing one and hacking it pretty heavily to change it to a very different look and feel. I spent a couple of hours IMing with him last night adding additional tweaks to the theme – like adding a navbar at the top of the header, dropping the sidebar completely from the theme (since it’s going to be essentially a static CMS once everything’s in place), and changing a number of other small elements. It was fun to realize once all that was done that it was a lot easier now than it had been the first time I tried to change and manipulate a WP theme back a year or so ago. I’ve gotten a lot more comfortable both with how individual WordPress elements function as well as with CSS itself in being able to position and affect various things on the page.

From the first time I started teaching myself HMTL about 10 years ago until now, I’ve always enjoyed playing around with web page design. I’m pretty much self-taught, which is also why I don’t know nearly as much as I’d like to. I’m pretty well-versed in HTML and CSS now, and I know enough about PHP to be able to hack the code, though I don’t know enough PHP to write pages from scratch, much to my chagrin. But sometimes I don’t wonder if I shouldn’t go into the information technology business. I love playing with server-side utilities, I love hosting websites, and I love just building things out of code. It’s a hobby that I’m pretty passionate about. I’m just afraid that if I ever turned such into a business, I wouldn’t enjoy it as much.

I don’t know if I’ll ever actually step into the IT business – it would probably require me to find both the time and the money to pick up formal training to finish filling in the gaps of my coding knowledge, and that’s not something I’m sure I’ll ever be able to do. But the prospect of being able to go freelance sure is appealing to me. I’ve always wanted to be self-employed. There’s plenty of time, though, so it’s an option that I’ve not completely ruled out yet.

I’m starting to think, though, that it might be time for me to create another WordPress theme. Anyone have any suggestions for layout and features?