About Mason Wendell

Mason Wendell podium

Mason Wendell is a Responsive Web Design, UX and Visual Design, Sass and CSS expert. He's passionate about getting to the core of what a client needs and turning that into the right design solution. He's a pioneer of the technique of using code to create designs directly in the browser. This gives him a unique perspective to find innovative ways to solve design challenges for his clients. 

He's a leader and innovator in using Sass to write styles. He created the popular Breakpoint tool for responsive web design. He's the co-creator of Sassy Modular Scale which helps to create beautiful typography.

He's an active public speaker, and speaks regularly at large and small events about web design, both from a creative and technical point of view.  


Fading in Sequentially

For a project I needed to call attention to an arbitrary number of “cards” while showing that each was an individual item. This led me to the idea that I could animate them in rapid sequence.

See the Pen Cards Fade in by Mason Wendell (@codingdesigner) on CodePen.



I’ve been speaking at meetups, bar camps, and regional and national conferences for the last six years.

I often speak about Designing in the Browser, Drupal, Sass and Compass, and Responsive Web Design. I produced a video podcast that teaches people about how they can use these tools and techniques creatively. I also blog at The Coding Designer and The Sass Way.

Videos on Vimeo


Thinking Inside The Box Inside The Box Inside The Box

  • Devsigner Con 2015 [KEYNOTE] - Portland, OR - (link)[http://www.devsignercon.com/conference/keynote]
  • Capital Camp
  • Design 4 Drupal
  • Sass Summit
  • SassConf 2014
  • DrupalCon 2014, Austin, TX
  • slides some reactions:
  • https://twitter.com/bkrall/status/474308270555791360
  • https://twitter.com/michaelgiaimo/status/474301519475388416
  • https://twitter.com/TXChetG/status/474298313739862016

Managing Responsive Web Design With Sass And Breakpoint

Designing with a Living Style Guide

Responsive Web Design

Mobile and Responsive Design with Sass

Intro to Sass

The Coding Designer’s Survival Kit (Sass)

Design in the Browser


Intro to Breakpoint


Balancing Ideal Sass and Ideal CSS

Sass makes CSS fun again, right? Well yeah, but that also makes it easy to forget that we’re still writing CSS. We can get caught up in all the new tools and tricks that Sass lets us do so easily that we lose sight of some CSS that might not be as awesome as we think it is. Last night at the Philadelphia Sass Meetup I set out to talk about the finer points of using mixins and extendable selectors, and ended up exploring how we can find the balance between a great Sass codebase and close-to-ideal compiled CSS.

Balancing Ideal Sass and Ideal CSS - Buttons

  1. Let’s just style a button. - Sassmeister Example
  2. Create a mixin. DRY Sass, but bloated CSS - Sassmeister Example
  3. Convert to an extended class. DRY Sass and small CSS - Sassmeister Example
  4. Convert that extended class to a silent extendable. Even better! - Sassmeister Example
  5. Maybe we need an alternate version of the button? Let’s try some manual overrides. Good CSS, but we could have DRYer Sass - Sassmeister Example
  6. We’ll try creating a new silent extendable that calls our mixin with a new argument. Better Sass but now our CSS is starting to bloat. - Sassmeister Example
  7. So now we’ll split our mixin into a ‘base’ mixin for the styles that are common to all buttons, and a ‘colors’ mixin to handle our alternate colors. We’ll create a %button extendable by calling both mixins, and a %button-cta extendable that extends %button and calls the button-colors mixin for its overrides. Clean Sass and clean CSS! Sassmeister Example
  8. What about RWD? Well it gets trickier. Extendables need to be scoped to their media query, so we need to redefine our extendables within a media query. The CSS is pretty clean but now the Sass is becoming a little hard to work with. - Sassmeister Example
  9. Instead of worrying about scoping those media queries we’ll call the mixins within the selector nest. This creates more css than we need, but the Sass is much easier to work with. - Sassmeister Example

Don’t extend native elements

  1. Extending a native element once seems ok. - Sassmeister Example
  2. But if we keep going we see a lot of (probably) unintended comma-separated selectors start to pile up. In a real project this gets pretty obsene. - Sassmeister Example
  3. So instead let’s define some silent extendables and then use them to define our native element styles as well as any extensions to them. Managable Sass and clean CSS! - Sassmeister Example
Posted on Thursday, August 1st, 2013

Post Breakpoint 1

Breakpoint 1.0

Breakpoint Title Card

Don’t feel like reading? Go get it now

About a month ago I was working on a responsive site, and trying to do it right. So instead of setting break points to match device dimensions (for phone, tablet, and desktop) I would set break points when my content and design needed them. Taking this kind of control over your responsive design means two things:

  1. You probably have a LOT more media queries
  2. And you lose track of why you used each one.

I needed a system to manage media queries.

As anyone who knows me knows, I’m a huge Sass nerd. Like, huge. So of course I was already trying to manage my breakpoints with my own system of variables and a super-cool mixin. Well that mixin was quickly growing unweildly, so I knew it was time to make something better.

I started with a few assumptions

  1. Most queries test the min-width feature.
  2. Variables are a good way to manage queries in a growing project.
  3. It’s nice to have a short easy syntax, that would still allow for complex queries when needed.

So I started with the syntax and worked it out from there. Since I wanted something simple I settled on using a mixin called “breakpoint”. That’s easy to remember. And since I’m making some assumptions on common use cases I decided to pass that mixin an argument that could contain just a simple numerical value. So, the simplest and most common use of breakpoint goes like this:

Simple use

$breakpoint-medium-width: 500px;
.foo {
  @include breakpoint($breakpoint-medium-width) {...}

Which compiles to:

@media (min-width: 500px) {.foo {...}}

min/max use

I expanded the syntax to accept numerical pairs, signifying a min/max relationship. The default feature is min/max-width.

$breakpoint-medium-not-wide: 500px 700px;
.baz {
  @include breakpoint($breakpoint-medium-not-wide) {...}

Which compiles to:

@media (min-width: 500px) and (max-width: 700px) {.baz {...}}

Feature / value pairs

I can’t limit this to just one kind of feature test, so if you pass in a feature name and a value it knows what to do.

$breakpoint-not-too-wide: max-width 700px;
.wtf {
  @include breakpoint($breakpoint-not-too-wide) {...}

Which compiles to:

@media (max-width: 700px) {.wtf {...}}

Stack ‘em up

Since I want to be able to create as complex a query as needed you can stack these up in a comma-separated list. You can even use one-sided tests like monochrome

$breakpoint-wide-portrait-mono: max-width 700px, orientation portrait, monochrome;
.zztop {
  @include breakpoint($breakpoint-wide-portrait-mono) {...}

Which compiles to:

@media (max-width: 700px) and (orientation: portrait) and (monochrome) {.zztop {...}}

I use this a lot. All over the place. Giving my breakpoint variable names that make sense keeps me organized, and the syntax makes me faster. Yay!

Collaborate, refine, add features

I told my friends about this, and one in particular practically pounced on it. My good buddy @snugug had been working on another solution to managing media queries and decided that Breakpoint would be a good engine for his syntax as well as the default one. And once he gets his claws in something he doesn’t let go. And that’s awesome, because now I can very happily say that Breakpoint is ready for prime time.

You want configuration options? You got ‘em.

You want to use ems instead of pixels? (You should.) Now Breakpoint can do the calculation for you.

You want to use device-pixel-ratio? (You shouldn’t.) Breakpoint will convert those to resolution for you.

Sam added these features as well as a ton of refinements to the code base. Everyone, thank Sam, OK? He’s pretty rad.

Add a break point at the point where it breaks.

Go get it now!

Posted on Wednesday, June 27th, 2012

Post Fixing H Fj

Fixing H&FJ Font Previews

HFJ Font Previews

I'm considering Hoefler & Frere-Jones webfonts for a new project. The service looks great but I haven't signed up yet. This may be different once I've paid for something, but for now their web preview kind of sucks. (sorry H&FJ) I want to test my own text before making such a big commitment but they only show their own promo text. To fix that I created a little bookmarklet that adds the 'contenteditable' attribute to all the preview spans. Now you can click any of those lines and type whatever you like. It's been helpful to me. Enjoy.

Drag this to your bookmarks: H&FJ Webfont Preview Use on pages like this: H&FJ Knockout


Posted on Wednesday, July 10th, 2013

Post Responsive Drupal

Responsive Web Design and Drupal

We love Responsive Web Design, and we love Drupal. But do they love each other? After working on a number of RWD and Drupal projects this year, I’m happy to report that they get along just fine. Though “Love” might be stretching it a bit.

Can Drupal and RWD be Pals?

Drupal is a great platform for managing content and for building everything from simple blogs to very complex applications. By connecting Drupal’s building blocks, you can build just about any functionality you need. That’s amazing, especially if you’ve ever struggled to build any aspect of that on your own. My Drupal a-ha moment came when I realized that I’d never need to write a user log-in on my own again. Smarter people than me were on the case.

But that speaks to two key aspects of Drupal that aren’t directly related to RWD. Drupal is primarily a back-end tool that excels when the building blocks are abstracted to be applicable to as many use cases as possible. Defining views and content types rightly doesn’t prescribe any layout or visual design, leaving those tasks to your creativity in the theming layer.

The best Drupal themes are also the ones that are the most general, allowing you to add all the custom details yourself. Good design is in the details, and the details are always custom. A good starter theme gives you the tools you need to have total control over those details and then gets out of your way. Themes that provide a full visual design must have their place, but I’ve never had a client that wanted to look like everyone else who installed the same theme. When a starter theme gets out of your way, you get something pretty fantastic: a back end system that provides the data and markup you need and a blank canvas where you can write whatever CSS and JavaScript you want to make something unique and delightful.

Responsive Web Design, just like any other flavor of design, is all about custom solutions. The difference is that we have the opportunity to change and refine the design around different browser characteristics, like the browser width. It’s natural that a designer would want a system to help with all this added complexity, but in most aspects, Drupal doesn’t provide such a system. But then again, it doesn’t provide a system for logo design either. It’s just not the right tool for that particular task.

Personally, I prefer Drupal as a blank canvas. With tools like Sass and the whole wide world of css techniques, I think we have some pretty great options already.

Posted on Tuesday, February 12th, 2013