Introducing, A New Responsive Website

A new keycoop.comI launched a new website this week, Go ahead and click on the link. Check it out. I’ll wait for you to come back. 🙂

Welcome back! This was a fun site to code. A few of the more interesting aspects include:

  • The main menu uses a 2D transform to give it a similar diagonal look to the logo.
  • If you’re in Chrome, you get to see a little eye candy as the hero image fades from 100% desaturation to 0%. I love CSS3 filters.
  • IE8 support is limited to functionality and a constrained single-column layout.

I was the front-end developer and UX manager on this project. That means I wrote 100% of the HTML, CSS, and JavaScript that wasn’t generated by our CMS.

As always, a shout out to the ever-impressive Emily Robinson for a beautiful design.

Love the site? Hate the site? Let me know what you think in the comments or on Twitter.

The Interactions Are What Matter

Alexis and her iPadThere’s something about the pulpit that the Internet gives us that makes us want to offer our opinions about everything. The latest source of drama is the release of iOS7, Apple’s extremely different-looking version of it’s popular mobile operating system. My Twitter feed is pretty evenly split, with (what I estimate is) about 60% of people disliking the change overall. I was unsure what I thought about it until this morning. Read More…

‘No, You Suck!’ and Other Poignant Progressive Enhancement Arguments

Responding to Rampant Progressive Enhancement Elitism

Update: Brad’s written a really good follow-up post, “On Progressive Enhancement,” where he basically clears up all my concerns and agrees with what I say below. Make sure you read it.

me, evidently

I tried really hard to stay out of this one. I really did. I’ve ranted too much about too many things lately and I was going to let this one go by with nary a whisper, but then I read this blog post by Brad Frost. In it, he claims that making decisions like “We don’t support [“Blackberries”, “IE6”, “Touch users”, <insert type of user here>],” is the same as looking that user subset in the eye and saying, “F*#& YOU!”

It’s incredibly elitist to say that every site and every web app we code has to support every subset of user on his predefined list of supportables. Read More…

Quick Fix: Sass Mixins for CSS Keyframe Animations

CSS Keyframe animations are awesome! I love the power and flexibility that using them gives me, especially when compared to the relatively simple nature of CSS transitions. With this power comes a problem. Even simple animations require a HUGE amount of CSS to make them cross-browser compatible. A simple move on the page requires this code:

.object-to-animate {
  -webkit-animation: move-the-object .5s 1;
  -moz-animation:    move-the-object .5s 1;
  -o-animation:      move-the-object .5s 1;
  animation:         move-the-object .5s 1;

@-webkit-keyframes move-the-object {
  0%   { left: 100px; }
  100% { left: 200px; }
@-moz-keyframes move-the-object {
  0%   { left: 100px; }
  100% { left: 200px; }
@-o-keyframes move-the-object {
  0%   { left: 100px; }
  100% { left: 200px; }
@keyframes move-the-object {
  0%   { left: 100px; }
  100% { left: 200px; }

Copying and pasting is overly difficult, but what happens if you now want to change the animation to end at left: 300px? And what if you have 30 animations? The complexity of your animation suite increases quickly, but there’s an easy solution to this problem.

Keyframe Animation Sass Mixins to the Rescue!

As with all things CSS, I’m convinced Sass makes generating keyframe animation code so much easier. Two simple mixins makes your life much easier, and your code much cleaner and more maintainable.

@mixin animation($animate...) {
    $max: length($animate);
    $animations: '';

    @for $i from 1 through $max {
        $animations: #{$animations + nth($animate, $i)};

        @if $i < $max {
            $animations: #{$animations + ", "};
    -webkit-animation: $animations;
    -moz-animation:    $animations;
    -o-animation:      $animations;
    animation:         $animations;

@mixin keyframes($animationName) {
    @-webkit-keyframes #{$animationName} {
    @-moz-keyframes #{$animationName} {
    @-o-keyframes #{$animationName} {
    @keyframes #{$animationName} {

Using the mixins looks like this:

@include keyframes(move-the-object) {
  0%   { left: 100px; }
  100% { left: 200px; }

.object-to-animate {
  @include animation('move-the-object .5s 1', 'move-the-object-again .5s 1 .5s');

The mixin allows for chaining of animations and as many keyframes as you'd care to use. It's a simple syntax that is very readable and maintainable for the long-term.

What other mixins are you using that make your life easier?

My Love/Hate Relationship With Twitter Bootstrap

Bootstrap Use or Abuse

It happens quite often. We take a framework, use the full, unminified version in a project we’re working on, then leave it. Bootstrap is just the latest addition to the stable of libraries we abuse. jQuery, Modernizr, D3. The amount of weight we add to websites we develop is quickly increasing. This chart from the HTTP Archive shows that the average page weight has gone up 24% in the last 12 months. The number of requests has also gone up dramatically.
Page weight increases

The newest version of Twitter Bootstrap (as of this post) is version 3. Even though it’s significantly lighter than previous versions (and mobile-first/responsive-ready by default!), it still weighs just under 100KB when minified. While that’s not totally deal-breaking, 100KB is 5x as much CSS as an average site should have, as well as 15%-20% of what all the assets on an average page should weigh. As you write more CSS to customize/override the Bootstrap defaults, it gets even heavier. Read More…

WordCamp: San Francisco Slides for Sticks, Spit, and Duct Tape

A doodle by the awesome @pixelista!

Thank you to everyone who came to my session today. It was a lot of fun to see everyone in the room and enjoying the session. Here are my slides for the presentation, Sticks, Spit, and Duct Tape: Advanced Responsive Web Development Techniques`. This should be everything you need to start experimenting with responsive web development, or to take what you’re doing to the next level.

The code from the live demo I coded during the presentation is ready to be downloaded. This is the exact file, unedited, ready for you to judge and steal from.

If you have any questions, or run into any issues, feel free to ask me on Twitter or in the comments.

Multiple Background Images Using Sass and Media Queries

Multiple background images

I am trying to create a quick way to theme’s class pages, and since the largest single asset of the whole page is the background image, I really wanted to use multiple background images to make sure that the closest possible image size is served to the user.

This most likely has zero use to you, but I thought it was a really interesting implementation of RESS multiple background images using media queries and Sass. I hope that if you need it, you use it; and if you don’t need it, maybe it will inspire you to employ some of Sass’s more advanced functionality. Read More…

Quick Fix: Sass Mixins for rem Values with px Fallback

Rems are awesome. They allow us to circumvent the complex cascading em mess that even great frond-end developers find ourselves in at times. The problem with them is figuring out the corresponding px value and remembering to put in the fallback. I’ve adapted a mixin by Karl Merkli to do just that. This beautiful little chunk of Sass will take rem value input in two different formats (with or without unit values) and output both the px and rem values you need. Read More…

My Sass and CSS Best Practices

Modularization, Nesting, Variables, Mixins, Specificity, Etc

In the week since I tweeted this, I’ve been asked about what I meant by it a half-dozen times. As with any dev tool, Sass’s power can be both a boost to productivity and a source of scorn because of misuse. I’ve even been told by a couple of people that they don’t allow their staff to use Sass/Less/CSS preprocessors because of the horrible unmaintainable CSS that it generates. Looking back at the Sass I wrote when I first started using it vs the Sass that I write now, I’m 100% certain that the problems these dev shops have lie 100% with the way the tools are being used, not the tools themselves.

Let’s take a look at some of the lessons I’ve learned and methods I use to write Sass that compiles to clean CSS.

  • Indentation vs. Nesting
  • Modularization
  • Variables
  • Mixins
  • Classes vs. IDs

Read More…