Optimizing Screenshots on macOS Mojave

Tuesday, April 16th 2019

Taking a screenshot in macOS has always been straightforward. Shift-Command (⌘) 5 will bring up Grab.app and let you crop the section of the screen you want to capture.

In macOS Mojave this tool was changed to mirror the way screenshots work on iOS. I like the change and found myself switching back to the system default after using tools like Napkin and Skitch for the better part of the last decade. The built-in system tool now lets me capture screen shots and make quick little markups just easily as those tools did and is a welcome addition to my workflow.

Frequently I find myself taking screenshots to include in emails to clients for short tutorials or to clarify requests before acting on them. The only problem with this new screen capture tool is that the default file format is PNG. If I was concerned with isolating specific windows on my desktop and capturing them in their entirety that would be great, but for my purposes it was always unnecessary. Typically I'd take the screenshot, make the the markups I need and them drop the image into a tool like Squoosh to optimize it further, and to avoid sending megabytes worth of attachments to my clients when a couple hundred kilobytes would do.

Changing the Default File Format

Although the new screen capture interface has a lot of options for how to capture your image, there is no GUI-visible option to change the default file format to a JPEG. It seems like a strange oversight to me. You can, however, change this setting on the command line:

defaults write com.apple.screencapture type JPG


Optimizing with Automator

The JPEG files that Mojave produces are still bloated. I don't need the highest quality 90% of the time when I'm embedding them in emails and blog posts. I can still drag the image to Squoosh or optimize the images on the command-line using a tool like ImageMagick but I decided to use Automator to make a folder action workflow instead. This way the JPEG images I create can be automatically optimized when I save them to a specific folder.

To do this I launched Automator, chose New from the File menu and created a new Folder Action. A folder action can be attached so a specific folder and will run whenever a new item is added to it.

From the library of options Automator provides I chose Run Shell Script and wrote a single line:

/usr/local/bin/mogrify -strip -quality 75 $1

You can consult the ImageMagick documentation to find a command that best suits your needs, but for my purposes stripping the meta tags and reducing the quality to 75% is a baseline "good enough" setting.

Attaching to a Folder

The last step is to attach this workflow to the folder. The easiest way to do that is to find the folder where you'll be saving your screenshots, right-click it and choose Services > Folder Actions Setup from the contextual menu:

It will ask you to grant permission for the folder actions service to run on this folder, but that should be the only time it asks you. After that you are done! If you've set this folder as the default location for saving screenshots then you should find them saved as optimized JPEGs going forward. Now I can omit the optimization steps in my workflow when sharing embedding screenshots in my emails.

For added flexibility you might consider leaving PNGs as the default file format for screen capture and changing the Automator script to convert PNGs to JPEGs when saved to that folder. To do that you'd want to change your script to something like this:

/usr/local/bin/convert -strip -quality 75 $1 $1.jpg

Getting Started with CSS Dark Mode is Easy

Thursday, April 11th 2019

"Dark Mode" has taken the modern OS UI by storm over the past few years. Many apps have made this an option, but now users can implement a system-wide setting. The preference gets communicated to the apps and they can react accordingly.

Soon you'll be able to detect this setting in your websites by using the prefers-color-scheme media query feature in your CSS. In fact, if you're using Safari 12+ on macOS you already can!

Unfortunately that's also the only place it's working, at the time of this writing, but that's probably likely to change over the course of 2019. Currently it's in-development for Chrome and Firefox. With Microsoft Edge switching to Chromium it seems likely to me we'll see it adopted there as well, sooner than later, though there's no telling for sure.

Using the new feature is very straightforward if you're used to using media queries.

Here's an example:

/* Show dark text on a white background */
body {

/* If the user has dark-mode enabled make
the text white and the background darker */
@media (prefers-color-scheme: dark) {
  body {

The documentation and examples at MDN illustrate this well and has an interactive examples as well. That's really it!

Conversely, setup a query to detect if the user has a preference set for light mode and respond accordingly:

/* Show white text on a dark background, as a default */
body {

/* If the user has light-mode enabled make
the text dark and the background white */
@media (prefers-color-scheme: light) {
  body {

That's really all there is to it!

This is one of the more interesting CSS spec items to come down the pipeline to me not so much for what it enables but because Apple pushed it out before all of the other players, but only desktop! I really can't remember the last time a feature arrived on Safari for macOS before literally everything else.

I feel like dark mode is a little gimmicky, but recognize it might genuinely help some people with eyestrain. Sometimes I can even talk myself into that when I stay up too late staring at my screen. Even so, I feel like this makes more sense as a system-wide operating system feature to enforce and not something the website should be handling.

Far less gimmicky to me is the prefers-reduced-motion CSS media feature. If your website employs a lot of animations and transitions you can check for this feature and tone things down. It's also much more widely supported.

Huff Post, Konami Code and Pet Photos Makes the News More Palatable

Wednesday, April 10th 2019

I've always kept tabs on my public profile out on the web. Sometimes it's surprising what you can find. You might have your own Google Scholar page because of a college paper you wrote when you were 18 or find out you were scheduled to speak at a conference in another country well before the organizers reached out to you.

Today I found out an old project of mine is being used on HuffPost—or should I say, FluffPost?


Go check it out! If you go to the HuffPost's homepage and enter the Konami Code all of the images turn into adorable photos of people's pets.

It has not been the best couple years for happy, uplifting news, but seeing some of these headlines accompanied by cute dogs and cats made it a lot more palatable. Cases in point:

Feisty Mnuchin

Mnuchin definitely looks feisty. And that team Barr is assembling looks like serious business. I'm sure they'll get to the bottom of things.

How did I find this?

I accidentally stumbled across this not via a Google search but by doing a search for my name on GitHub in other people's code repositories. This might seem a little odd, but if you've created or contributed to a lot of open-source projects it's an interesting view into how people might actually be using what you've made.

It's also a good way to see if a private repository you handed off to another development agency accidentally found it's way into the public... but that's a different story!

In looking for my name I came across references to a project of mine in what looked like code scraped from the homepage of Huff Post. The code contains comments with information about licensing, the version and a byline with my name, which is what helped me find this.

I decided to go the Huff Post and try the code out. When I entered the Konami Code and saw the pets I laughed, and when I went to view the source code for the page I was tickled to see my name and code sitting there.

About the project

Konami-JS is an open-source easter-egg project I made back in 2009. It lets you add an Easter Egg to any website when a visitor enters the Konami Code. The differentiator, at the time, was my project worked on mobile devices.

Most of what I find are people putting Konami Code easter eggs on their GitHub pages, blogs and other personal projects. Occasionally it pops up in bigger places like Marvel.com or Newsweek. I recently discovered it was even being used on Tesla's online design tool back in 2012—I found remnants of it on archive.org here. I guess now I can add Huff Post to that list!

By modern JavaScript standards the script is kind of archaic, but it lives in a sort of gray area where I'm not sure it stands to gain much by modernizing it. The code footprint is compact but but understandable and it's easy to plop into any existing project with a quick copy-and-paste. Beginners can and do use my code, all the time.

As the barrier to entry into web development seems to grow a little steeper each year, I'm happy to have contributed a project that's being used by novices and high-traffic websites alike. I'm also happy that it's a joyful, frivolous contribution that's been mostly used to make the web a fun and sillier place.

Watch me give a talk about my experience maintaining this "frivolous but popular" project at OdessaJS in 2017:

Lastly, I do have open issues and discussions on GitHub surrounding what Konami-JS 2.0 could/should look like, a decade later. Your contributions are welcome.