Currently designing things at GitHub. Creator of Bootstrap. Previously at Twitter. Broheim.

Powered by Fusion

Dream on

This morning I was mentioned in a brief Twitter conversation, and because Jeffrey is the best, I feel obliged to reply.

I encourage you to read the mentioned post by Elliot Jay Stocks. In it Elliot asks the question, Why have today's designers stopped dreaming? Between the article and the tweets, there are two topics I'd like to comment on.


First, Brendan blames—among other unnamed things—frameworks. Consider my interest piqued.

While Elliot directs his post towards the craftsmen—those swinging the tools—Brendan throws the tools themselves under the bus. He's not alone in that line of thinking. Lots of folks hate on today's frameworks, design tools, and the like. Usually that dislike comes out of personal preference or limited experience. That doesn't invalidate anyone else's use of those tools though, and we'll all do well to remember that.

Let's consider another "framework" for a moment—iOS. Is the most important operating system of the last decade to blame for a stagnation in app design and creativity? Some might say so, but have you seen the amazing apps that are being built on iOS? They're fucking astounding!

Are frameworks the same as a mobile operating system? No, but they serve a familiar role—abstraction of common aesthetics, behaviors, and components with a focus on documentation. As absurd as it might sound, it's hard not to see at least some similarity between the two.

Are these frameworks and other tools impervious to criticism? Definitely not. (Have you seen the number of issues against Bootstrap? It's over 13,000!) However, it's important to acknowledge that amazing things can be done with just about any tool if you have the right mindset.

Bottom line, the tools aren't (completely) to blame.

Web workers

Second, from the article:

The web right now is a beautiful place. Web design has matured as an industry and the technology now enables us to create whatever we might dream of in HTML, CSS and JavaScript. But it's clear that laziness amongst designers has never been more rife.

Thousands and thousands of cookie-cutter sites litter the internet, each one drawing just a little too much influence from the last. The blame is not to be laid at the feet of sites that provide actual website templates, but at the feet of professional designers who are churning out 'bespoke' sites that might as well be templates.

I dare say what we're witnessing, and what Elliot and Brendan are referring to, is not laziness. The web design and development community is in a completely different place from when we got started.

We've been doing this stuff for 10, 15, or more years now. Those lazy designers you're seeing? They're lawyers, stay-at-home dads, bored teenagers, interior decorators, anthropology majors, teachers, and more. And they all just learned HTML and CSS last Tuesday afternoon while we were all eating our burritos and playing video games at work. (Hi, that's me in case you didn't realize.)

Today's web is filled with millions of people who don't make websites professionally. They make them simply because they want to and the tools are in place so that they can. That's fucking awesome!

This doesn't account for everyone though. Are some designers lazy? Yup, and at times I'm definitely one of them. The site Elliot described? It might as well be any number of the example templates that come with Bootstrap. And I'm perfectly okay with that.

Right or wrong

Elliot and Brendan aren't wrong. There are lazy designers and developers out there, and tools and trends can make it easier for folks to be lazy. At times, I'm one of those lazy designers. Does that make any of us right or wrong? I don't think so. Can all of us do better? Most assuredly.

Using design trends helps people. We find out what looks good doesn't always feel good. We find out that some tools don't always work for every job. We find out that performance and documentation are more important than your own visual preferences. Design trends, frameworks, and the like are, among other things, learning tools. Let's keep that in mind.

Sing with me

Everything I do in my work at GitHub and on Bootstrap is dedicated to folks who want to make awesome stuff on the Internet. My dream is to help awesome people do awesome shit. Nothing else gets me more stoked out of my mind than that. I get goosebumps thinking about how much the web has changed and how we can continue to shape it just by writing code and sharing our experiences.

Designers didn't stop dreaming. We just have millions of people dreaming dreams different than our own. Let's encourage and foster that by enabling these people, and ourselves, to do more—and to do better. And of course, to dream on.

Including CSS in Jekyll

Jekyll is a blog aware static-site generator. It's great for building simple pages like Code Guide or blogs like this one. Lately, I've been a big fan of Jekyll's include functionality.

Now, most folks use _includes for standard partials like a site's header or footer. Lately though, I've been using them to easily include CSS dependencies for fewer page requests.

Say you have three CSS files to include in your Jekyll project. Normally you'd do something like this:

<link rel="stylesheet" href="site.css">
<link rel="stylesheet" href="font-awesome.css">
<link rel="stylesheet" href="syntax.css">

With Jekyll, you can turn that into one file during site generation with includes and YAML front-matter. Here's an example Gist:

The front-matter tells Jekyll to treat this page as a buildable file rather than simply another asset to copy to the generated _site folder. With that in place, add any _includes you like, and run jekyll serve.


Introducing Poole

Poole is the Jekyll butler. It's a fully furnished Jekyll setup, designed to be a consistent and flexible starting point for Jekyll projects. It's available today, and I'm releasing two open source themes with it.

What's included

Out of the box, Poole is a Jekyll setup that focus on the content first and foremost.

It does so with a limited set of styles and a foundational feature set for any project:

  • Complete Jekyll setup included (layouts, config, 404, RSS feed, posts, and example page)
  • Mobile friendly design and development
  • Easily scalable text and component sizing with rem units in the CSS
  • Support for a wide gamut of HTML elements
  • Related posts (time-based, because Jekyll) below each post
  • Syntax highlighting, courtesy Pygments (the Python-based code snippet highlighter)


As part of the release of Poole, I've created two themes for folks. One, Hyde, has already been available for some time. The second, Lanyon, is brand new today. Each theme includes all the features of Poole, and then some.

Hyde 2

Hyde 1, my first open sourced Jekyll theme, was released in October. Along with the launch of Poole, I've redesigned and recoded much of it. Today's release represents Hyde 2.0. Overall it's still the same theme, but with many improvements under the hood.

Hyde 2

If you're wondering, Hyde 1.x is available on my GitHub account. However, it's no longer being actively maintained.


The second theme, Lanyon, is also being launched today.

Lanyon Lanyon open

Lanyon started off as a variation on Hyde to hide the sidebar. Rather than keep the two together, I figured a brand new theme was in order. Thus, Lanyon was born. The best part is the toggleable sidebar is handled all via CSS—no JavaScript is required.

Theme options

Lanyon in red

Hyde and Lanyon include auto-generated navigation lists with active link highlighting, eight optional color schemes (based on the colors of base16), and reverse layouts (sidebar on the right).


Docs for Poole, Hyde, and Lanyon are available in each project's readme.

The Poole docs include a basic walk-through for setting up Jekyll. Each theme's readme focuses on only theme-specific features and none of the Jekyll setup process.


If you're not familiar with it, The Strange Case of Dr. Jeykll and Mr. Hyde tells the story of a lawyer investigating the connection of two persons, Dr. Henry Jekyll and Mr. Edward Hyde. Chief among the novel's supporting cast is a man by the name of Mr. Poole, Dr. Jekyll's loyal butler.

It seemed fitting to name the project after such a man, given all he intends to do—for myself and the rest of you. Plus, it's a killer naming scheme.

GitHub org

To keep everything neatly organized, everything lives in a new GitHub organization, @poole. It includes Poole, the Poole homepage, and the two themes.

It behooves me to mention that if you have a bug or feature request in any of the Poole-provided files (configs, layouts, poole.css, etc), please open issues in @poole/poole. Anything directly related to the theme (like in hyde.css or lanyon.css), should be addressed in the respective theme's repository.


Snag Poole, Hyde, or Lanyon as you need from each project's GitHub releases page.

Watch the GitHub repositories to be notified of future downloads, or follow me on Twitter for updates when they become available.

What's next?

Probably some bug fixes and small feature requests, and soon maybe another simple theme. I plan on looking through my old blog designs for ideas on what to build next. If you have specific ideas, let me know on Twitter.


Introducing Hyde

Say hello to Hyde. Hyde is an elegant, open source, mobile first theme for Jekyll, the popular static site generator. It's super simple, inspired by Medium's structural design, and is a great starting point for just about any blog.

Hyde screenshot

Check it out on GitHub, or snag a download right away.

Have bugs or feature requests? Open an issue.


CSS and #noparents

#noparents is more than an emotionally charged hashtag to express your individuality and independence as an angsty teenager. Turns out it makes a lot of sense when writing CSS, too.

The fuck?

Consider the following snippets of HTML and CSS:

<div class="jumbotron">
  <h1 class="text-danger">Heading</h1>
.jumbotron h1 {
  color: #333;

.text-danger {
  color: #f00;

To summarize, we have a .jumbotron h1 that should have red text with the .text-danger utility class. The problem is, due to the specificity (a parent class preceding an open-ended tag) of the first rule, our utility class has no effect. The text will remain dark gray. Shit.

Classes to the rescue

If we modify our approach, we nullify the problem and walk away with some additional benefits.

<div class="jumbotron">
  <h1 class="jumbotron-heading text-danger">Heading</h1>
.jumbotron-heading {
  color: #333;

.text-danger {
  color: #f00;

Now, adding the .text-danger class will work as intended. It's worth noting two things here:

  • No matter what, this relies on CSS being in the proper order, but that's always true and out of our control.
  • Alternate solutions could include using !important or writing overrides to these kind of specific collisions. Both options suck.

Bottom line: removing the parent and using a single class as our selector is the best option, and it pays off.

Dem benefits

So, we wrote more HTML to avoid writing even more CSS. How's this a win and why does it matter?

  • To start, we've decreased the specificity of our selector. Now, any single class appearing later in our code can take over with ease, just as it does in our updated example. This is how CSS works, and keeping your code to that standard keeps your sanity.
  • In selectors, classes perform better than elements. Removing that h1 from our CSS rule for the heading helps the browser render the page faster. In many cases this isn't that helpful, but for larger project (like maybe a CSS framework or web app?) it can make a world of difference.
  • A series of classes for each component promotes more flexible and durable design systems. The use of .jumbotron and .jumbotron-heading logically groups code, more effectively scopes CSS, and promotes a consistent naming convention.

I'd say those are some solid wins, especially when applied across an entire project.

Applying it

I'll be the first to say Bootstrap doesn't do this enough, and it's to our detriment. Whenever we start work on v4, I'll be testing this approach. There will inevitably be situations where we need to keep the parents to prevent collisions out of our control (e.g., nav components and dropdowns), but I imagine we can still improve that. We'll get there in time as we continue to experiment.

Until then kids, remember this: when it comes to CSS specificity, it's #noparents.