Archive for June, 2018

Page 1 of 1

Fluid Type for Better Responsive Text

I’ve been playing around with fluid type for a while and happened upon a pen by…I don’t remember who. I forked it a while ago, but in essence we’re simply attempting to scale type based on viewport size.

In the instance highlighted here, let’s say we want a bold header in a hero space to essentially always have that bold feel no matter what screen size we’re viewing items at:

See the Pen Scaling Text with Viewport Units by mikemattner (@mikemattner) on CodePen.

Not a bad solution, but if you’re not careful that can scale infinitely and in a way that is just a bit too in your face. My suggestion is to set–at the very least–an upper bound to that scaling. I’ve done something similar on this very site.

My minimum size is set at 14px, plus a half a percent of the viewport width with a line-height set based on 1.1em plus a half a percent of the viewport width. This will scale up infinitely, but I found that that maximum font-size I wanted was closer to 20px. Through a little viewport resizing and code inspection, I found the viewport width where this formula would generate a nominal 20px size and set that as my upper bound:

html {
  font-size: calc(14px + 0.5vw);
  line-height: calc(1.1em + 0.5vw);
  @media (min-width: 1200px) {
        font-size: 20px;

Not too bad of a result as far as I can tell. The rest of my typographic sizing builds on this initial sizing and seems to work out fairly well for my purposes.

Easy technique.

Adventures in Dotfiles

I accidentally ran into a bit of laziness during my development process that turned into a productivity boon, and should prove to be absolutely essential during the setup of any new Mac I might purchase in the future.

Let me preface this by saying I am not a native of the command line–by any stretch. I find it to be cumbersome and annoying to remember commands and all of the possible flags that might apply to them. Even something as simple as showing hidden files on the Mac can be obnoxious:

# Show hidden files
--- ~ » defaults write AppleShowAllFiles -bool true && killall Finder

# Hide hidden files
--- ~ » defaults write AppleShowAllFiles -bool false && killall Finder

What if I could just type show or hide and be done with it? This is where aliases come in. This was a concept I was keenly aware of already–seeing that most of the helper plugins I used in my ZSH installation provide plenty of helpful aliases–but I figured, why not create some that I could use for operations I performed frequently? Or to find a way to easily navigate to directories I regularly used?

At first I created a simple .aliases file and started to add what I needed:

# Show/hide hidden files in Finder
alias show="defaults write AppleShowAllFiles -bool true && killall Finder"
alias hide="defaults write AppleShowAllFiles -bool false && killall Finder"

# Hide/show all desktop icons (useful when presenting)
alias hidedesktop="defaults write CreateDesktop -bool false && killall Finder"
alias showdesktop="defaults write CreateDesktop -bool true && killall Finder"

# Disable Spotlight
alias spotoff="sudo mdutil -a -i off"
# Enable Spotlight
alias spoton="sudo mdutil -a -i on"

#Git commands
alias gnb="git checkout -b"
alias gmsg="git commit -m"

I sourced it in my .zshrc file and called it good.

But then I wondered what would happen if I lost everything on this system? I started doing a little research and discovered that there were plenty of people working on ways to bootstrap their development environments for situations like this.1

I found one particular repo by Mathias that I was able to gather some items from, as well as an installation process that could get me started with everything I used. Now all I need to do is navigate to my cloned repo and type:

--- ~ » source

I follow a few prompts and install what I need to get up and running. I can share my dev environment between machines fairly easily this way.

If you’re interested, feel free to browse my repo for reference, or fork it if you want to build on it. Keep in mind, there are more repos available with more sophisticated setups than my own if you’re looking for something more robust, but if you’re knew to this level of customization on this level, this is a good start.2

View Project on GitHub

  1. Getting Started with Dotfiles. Accessed May 23, 2018.
  2. GitHub does dotfiles. Accessed May 23, 2018.