New Mm Theme: Trestle

[box type=”download”]


A handy boilerplate child theme for serious Genesis developers.

Trestle takes a lot of the grunt work out of building sites using the Genesis Framework, providing quick and easy-to-implement solutions to common problems and repetitive tasks. We’ve taken Genesis’ rock-solid foundation, integrated mobile-first CSS, responsive navigation, a full-featured settings panel, and much more. Download. Install. Enjoy.

View Demo » Download »[/box]


Trestle: A handy boilerplate theme for serious Genesis developersTrestle includes tons of helpful features such as:

  • Centralized control panel (Genesis → Theme Settings)
  • Responsive navigation menu
  • Mobile first CSS
  • Custom control over post info and meta
  • Multiple page layouts
  • Auto-generating primary navigation
  • Ability to auto-install your favorite plugins
  • Helpful theme jQuery
  • Compatibility with Genesis Extender plugin
  • Optional link icons
  • Built-in shortcodes (columns, buttons, Font Awesome, etc)
  • Front-end styles appear in editor as well
  • And more!

Still to come. . .

There are some features still on the horizon as well (feel free to add a pull request if you’re interested in contributing):

  • SASS support
  • Direct logo implementation (non-CSS)

What is Mobile First CSS and Why Does It Rock?

We throw around the phrase “mobile first” a lot here at MIGHTYminnow. It factors into many of our discussions and plays an important role in pretty much every site we build. We even created the Genesis Mobile First Child Theme, which is dedicated to making it as easy as possible to go mobile first when working with the fantastic Genesis Framework. Well if you’re wondering what “mobile first” means and why it rocks, keep reading.

What is Mobile First?

Lots of different people define mobile first in lots of different ways, but when we talk about building a mobile first website it basically boils down to two things:

  1. Philosophically: Optimizing the experience for mobile users as much as possible. In other words, putting the needs of mobile users first.
  2. Codily (we just made that up): Writing CSS in such a way that smaller (mobile) devices can access their styles without having to wade through styles written for desktop devices. In other words, writing the mobile styles first. (“First” means before the media queries that define the look of the site on larger displays – media queries are one of the hallmarks of “responsive design.”)

Now, there are tons of considerations that go into making this magic happen, and we’ll get to that in a minute. But first things first. . .

Why Go Mobile First?

There are a few key reasons why mobile first development is a good idea:

Mobile vs Desktop Usage Over Time

Mobile vs Desktop Usage Over Time

  1. Mobile traffic is growing. . . fast
    The number of website visits coming from mobile devices is ever-increasing, and is predicted to surpass desktop visits in 2014. Bottom line: mobile viewership is growing and so is the demand for mobile-friendly websites.
  2. Mobile experience ≠ desktop experience
    Phones and tablets are different from desktop machines in so many ways (screen real estate, processing power, connection speed, etc), and their different limitations and capabilities warrant different solutions. Bottom line: designing for ALL devices, and coding in the way that makes the most sense for each of them, is better than designing only for desktop devices.
  3. People will leave and never come back
    Tons of folks have written on the negative effects of poor site design/functionality, particularly in regards to site speed. Bottom line: if your site doesn’t work well on mobile, you’ll lose users.

How Do I Code Mobile First CSS?

There are tons of ways to optimize mobile users’ experience, and if you’d like to learn more about all of them you should definitely check out Luke Wroblewskis’ excellent book: Mobile First. In this post, however, we’re going to focus primarily on CSS – our bread and butter. With that in mind, here are some mobile first CSS best practices we use on a daily basis:

Min-Width Media Queries

This is probably the most common question we get when talking about mobile first: why does it matter whether I use min-width or max-width media queries?

min-width media queries in actionUsing min-width media queries at the end of your style sheet means writing all of the common (meaning used by all devices) CSS first. All of the rules that you want phones and tablets to see are front and center, with larger screen caveats in the media queries below, in order of increasing screen size. Writing the common-to-all styles first ensures that mobile styles get loaded without desktop styles mixed in – which can significantly improve the mobile experience.

Mobile first CSS is written like this:
Styles for mobile and styles that are common to all screen sizes
(no media query)
Media query with a smallish min-width breakpoint
e.g. @media (min-width: 400px)
Media query with a slightly larger min-width breakpoint
e.g. @media (min-width: 600px)
Media query with a larger still min-width breakpoint
e.g. @media (min-width: 960px)

One way to think of it is that you start with a mobile base and build up (or out, if you think in terms of widths).

It seems like, with the introduction of responsive design, that a lot of folks defaulted to building the desktop version of their site first, then proceeding with max-width media queries at the bottom of their CSS in order to “undo” these desktop styles for mobile devices. You’ll see this approach used in TONS of responsive WordPress themes. We think this is because we’ve gotten so used to visualizing design from a desktop-first standpoint. “I’ve got my big screen, and as I shrink it down to tablet and phone sizes I need to know the maximum width up to which I should apply my mobile styles.” That’s thinking desktop first – essentially catering to desktop machines and treating mobile devices as an afterthought.

Content is like water

Photo by Stéphanie Walter / CC BY

But here’s the catch. Let’s say our style sheet is massive (although in an ideal world we would minify and concatenate all our CSS), and our media queries are at the very bottom (which is good). Writing the desktop layout first – float this, position that – and then undoing that floating, positioning, etc in the media queries means that you are first building your desktop layout, and then deconstructing it for mobile. To do this, you are writing more code, and doing it in the order that makes the least sense to the devices that need the most help in terms of connection speed. And if you’re viewing the site on your phone, you’re going to be seeing the desktop version of the site until the CSS is almost entirely parsed. We’re not talking very long here, milliseconds at most, but we’ve seen plenty of sites on which this moment of incorrectly-styled content is visible – and distracting. You can read more about this eternal nemesis of developers the world around: FOUC.

Using min-width media queries allows you to build your design from mobile sizes on up, thus shifting the burden onto non-mobile machines. Now we’re catering to the limitations and capabilities of different devices (non-mobile devices typically load/render CSS faster than their mobile counterparts). Historically, the trend has been that mobile devices have less processing power than their non-mobile counterparts. While this gap is shrinking, why not make sure the less performant devices get their CSS faster?

The other reason to use min-width media queries is that it really helps us get in the mindset of. . .

Progressive Enhancement

Progressive enhancement essentially means adding more cool stuff (CSS & JavaScript, usually) as our device can handle it. It’s sort of the inverse to the concept of “graceful degradation,” which means that we start with all of our great functionality and design components, and remove them as needed for devices/browsers that can’t handle them. In terms of taking an approach to mobile first CSS, we can often achieve better performance on average by implementing a mobile first approach. Again, remember that we want to switch as much of the work as possible away from mobile devices and onto their (typically) more performant non-mobile counterparts.

So we start with the simplest core features, and we add more as the user’s device can handle it. This not only helps us follow our favorite KISS practices, it also results in better performance and user experience.

Content (Not Device Width) Determines Breakpoints

I can’t tell you how many sites we see with the following breakpoints: 320px, 480px, 768px, 1024px. As you may have noticed, these are the exact dimensions of the ever popular iPhone (pre 5) and iPad. The folks that wrote this CSS had one thing in mind: making sure their breakpoints aligned perfectly with specific devices. But what happens when a new device with new dimensions is released, the iPhone 5 for instance? Or a new Android tablet or the MS Surface? Suddenly our breakpoints don’t make as much sense and we’ve got to modify our CSS to accomodate these new dimensions. New device. New media query. New device, New media query. On and on, ad infinitum. You can see there is a fundamental problem with letting popular devices dictate breakpoints.

Instead, we prefer to base our breakpoints on the natural qualities of our content – essentially paying attention to when each element “wants” to be restyled. A great example of this is styling navigation menus.

On the MIGHTYminnow site, our navigation appears as a grid on mobile devices (try dragging your browser window to a smaller width to see). As the screen size increases, we simply pick a point at which the content itself would look better in a new formation, and that’s our breakpoint! We keep working our way up until we’ve reached desktop size, and that becomes our final min-width media query. It’s pretty simple, really, and we’ve created CSS that is future-proof, ready for any device size. Honestly, this organic approach flies in the face of a lot of the current grid-based frameworks and theories, but it is really the only thing that makes sense to us – plus it’s really not that hard to implement. If content is king, why not let your content define the point at which your layout changes?

Relative Units & Percentage Widths

Mobile first development, done well, is synonymous with flexibility. Using relative units (em or rem) and percentages (particularly percentage-based widths), allows you to create CSS styles that flow smoothly across devices and screen sizes. Almost more importantly, they make future changes that much easier. Imagine, for a moment, that you’ve hard-coded your content-area/sidebar widths and font-sizes with something like this:

Seems fine, right? But what if you suddenly realize your media query needs to trigger at 1060px, not 1000px? Now you’ve got to manually change the pixel widths of your content-area and sidebar. Or say you decide you need to bump up all font-sizes across the board. Here we’re just looking at two elements, but imagine the potential impacts on a site with hundreds, or even thousands, of CSS rules. That can get pretty daunting pretty fast. With relative units and percentage-based widths, however, far fewer modifications are needed. The proposed changes above are as simple as:

Notice that we’ve switch our widths to percentages, and the font-sizes to relative values. Now, you can see how our widths will work no matter where our breakpoint occurs, and our font-sizes can be changed across the board just by changing the <html> element’s font-size.

The Little Things

Mobile first CSS is often about improving the little things, which can make a big cumulative difference in the end. Here are some “little” best practices to keep in mind:

  • More Gradients & Font Icons, Fewer Images
    If you are looking for some new best friends in the web world, than might I recommend CSS3 gradients and font icons. These methods not only pack some serious design punch, they also help you minimize your HTTP requests and save on bandwidth – surefire ways to improve overall site speed and general user experience. Images, on the other hand, are a surefire way to increase load times and leave your users hanging, particularly on less performant mobile devices.
  • Smaller Images at Smaller Sizes
    Serving device-appropriate images is a great way to improve a site’s performance across all devices. With background images, this is a pretty straightforward task. As you move up through your CSS breakpoints, you can simply load larger versions of these images, changing your CSS styles accordingly. For inline images, this can get a bit trickier. The same concept applies (smaller images for smaller devices), but solutions typically require a JavaScript polyfill to dynamically replace/load images as needed. If you’re interested in this method, you might want to check out the following:

What’s The Catch?

Mobile first sounds pretty good, right? So why isn’t everyone using it?

Old Habits Die Hard

The good news is that mobile first’s main obstacle is simply that we’re not used to it. For a long time we’ve been designing websites for non-mobile devices simply because mobile devices never played a significant role in viewership. Consequently, we’ve picked up some deeply ingrained site-building habits, processes, and philosophies along the way. A mobile first approach requires us to flip some of these habits on their head (e.g. designing with a phone screen in mind and working up to desktop, instead of vice versa), and this can certainly lead to some growing pains. Worth it? Definitely. I mean, table based layouts weren’t easy to let go of, but we’re all glad we did.

Design problems

“The designer doesn’t understand mobile” or “there’s no budget for extra (mobile) comps”

One thing we’d like to stress is that mobile first coding doesn’t have to mean generating special mobile comps, although that sounds luxurious and lovely. Even if all you have is a desktop design, you can create a great, responsive website (have a look at our case study for Rocket Dog Rescue). We only ever have our designers generate desktop designs, and we use them to make responsive websites. All you need to do, in our opinion, is to be very conscientious when adding widths, floats and other column inducing code. As you are coding your “desktop” comp, isolate any column widths and layout stuff in media queries at the bottom of the page, as well as any outrageous heading font sizes that don’t look good when you drag your browser down to phone sizes. Do some browser dragging as you go, and pop over to or responsinator for validation. If you treat your comp as a guide, and keep on top of the way the site looks on mobile as you code, you can come away with a “pixel perfect” desktop display and appropriate mobile layouts without a ton of additional effort.

Side Note: Polyfill Needed

Alas, certain Browsers-That-Must-Not-Be-Named still don’t natively support CSS media queries, and will need an extra polyfill to accurately render your mobile first CSS. Good thing there are some great polyfills available:

In Conclusion

Mobile first. Learn it. Use it. Love it. Taking a mobile first approach is a great way to ensure that your site looks and performs optimally across the board.


Mobile First, by Luke Wroblewski

Creating a Mobile-First Responsive Web Design, by Brad Frost

Mobile First Design: Why It’s Great and Why It Sucks, by Joshua Johnson

Our New Mobile First Child Theme for Genesis 2.0+

[box type=”download”]

Mobile First Genesis 2.0 Child Theme

Download our new Mobile First Child Theme for Genesis 2.0. The theme looks and feels identical to the Genesis 2.0 Sample Theme, however it has been optimized with a “Mobile First” approach, meaning faster load times and an overall better experience for mobile users.

Download Now »
See Demo »[/box]


We’ve long been huge fans of the Genesis Framework – it integrates with tons of well-designed child themes, it offers lots of amazing functionality and plugins, and the StudioPress support team is consistently speedy and helpful. One thing we’ve always wanted, however, is a basic Genesis child theme that is “Mobile First.” So we decided to go ahead and make our own! We wanted to keep things as simple as possible, so we started with the Genesis 2.0 Sample Theme and went from there. Most of the work just involved rearranging CSS, however you may want to check out the full list of details below for more information.

Theme Details

    • Requires Genesis 2.0+.
    • All media queries have been switched from “max-width” to “min-width”.
    • Media queries have been rearranged to proceed from smallest to largest widths.
    • Only two changes were made to the original CSS to preserve styling after rearranging the media queries:
      • Line 700: .sidebar .enews-widget was changed to .sidebar .widget.enews-widget
      • Line 1366-67: the margin-top selector was changed to margin
    • This theme’s functions.php is identical to that in the Genesis 2.0 Sample Theme, only difference being the child theme name, url, and version definitions. It adds theme support for:
      • HTML5
      • Responsive viewport meta tag
      • Custom background
      • 3-column footer widgets

Important Note

Being as this theme utilizes mobile first media queries, you’ll need to utilize a polyfill if you want the theme to appear correctly in Internet Explorer 8 and below. Here are a few options:


  1. Install Genesis 2.0. If don’t already have Genesis, you might want to get it.
  2. Download the Mobile First Child Theme for Genesis 2.0.
  3. Install the the child theme, either manually or via WordPress’ theme installer.
  4. Activate the child theme.
  5. Feel free to modify the child theme’s CSS and PHP to create your own unique look and feel.
  6. All done!

Change Log

  • 1.4
    • Fixed nav extras CSS to better display search bar.
  • 1.3
    • Moved .first {} CSS rule into media queries where it belongs (thanks again @GaryJ)
  • 1.2
    • Added missing width: 100%; rule for full width content
    • Added missing float: right; rule for .content div
  • 1.1
    • Updated style.css table of contents to reflect new media queries (thanks @GaryJ)


We’d love to hear it. Please let us know if you have any comments or suggestions below. Thanks!

Add Expanding “Read More” Links to Your WordPress Blog

Here’s a handy jQuery/CSS snippet that adds special “read more” links to expand and hide your WordPress blog posts, accordion style. This is pretty useful if your blog page is spitting out a bunch of long posts, and you’d like to consolidate some space. The code is set to work with default WordPress classes and ID’s, however it can be easily modified to work on any HTML. Enjoy!

Check out this Pen!


Styling <select> Form Elements

A handy CSS/jQuery snippet to style <select> elements.

Check out this Pen!

:hover Effects for Mobile

We recently completed a project in which we needed to popup a tooltip-like box when hovering over an element. The :hover CSS pseudo-class works fine in desktop, but not so well on mobile. What ends up happening on mobile is that tapping the target element does indeed pop up the tooltip, but tapping elsewhere on the screen fails to close it. Clicking another link or hoverable element does the job, but we needed to emulate proper lightbox/tooltip behavior, in which clicking anywhere else will trigger it closing.

What we ended up with is the following jQuery/CSS combo that seems to do the trick nicely.

Check out this Pen!

Fake See-Through Backgrounds with CSS

Here’s a little bit of CSS to create a cool “see-through” effect, which is particularly fun when using fixed-position background images.

Try scrolling me!

Check out this Pen!


This method utilizes the :after pseudo-element, which doesn’t work so well on inputs, but if you want to apply the same effect to form elements you can just create a lighter/translucent version of the same background image and apply it to the <input>‘s. Anybody have a way to do this without creating a second image? We’d love to hear about it.

Styling TinyMCE content in WordPress

I, for one, was tired of my left aligned images creating a staircase in TinyMCE when my theme CSS is set for them to nicely clear. Here is what it looks like in WordPress TinyMCE:


When this is what it looks like on the page:


In TinyMCE it can often be challenging to tell what the true layout of the page will look like when your front-end CSS is applied, but it turns out that it’s easy to change the TinyMCE styles as well. All you need to do is drop this code into your theme’s functions.php:

And then create a corresponding CSS file called custom-editor-styles.css in your theme folder.

Write the CSS to clear your <h2>’s, make any other style changes you want to show up in TinyMCE, and voilà! You’ve got a page that makes visual sense.

Clearing Headings

There is a lot more you can do with this, like incorporating more of your actual theme CSS, but the main point is just to make your TinyMCE (back-end) and theme (front-end) CSS more consistent. We don’t need it to look exactly like the site, just enough to understand how the final page is going to lay out.

If you’d like to learn more, you can always check out the add_editor_style() post in the WordPress Codex.