• #os x
    • #macOS
    • #front end development

    Photoshop Favicon Creator Action for the Obsessive

    I created a photoshop action after annoyance over favicons. It's on GitHub for download. There's quite a bit to it but it creates 13 icons in total. The support list is loooong! I tried to cover everything and this includes (but not limited to): IE11, Edge, Chrome 4+, FireFox 2+, Opera 10.1+, Safari 3.1+, iOS Safari 6+, Google TV, Android Browser 2.1+, Chrome for Android, FireFox for Android, UC Browser for Android, Samsung Internet, QQ Browser, Chrome Store, Windows 8+ pinned sites.

    Size Name Purpose
    32x32 favicon-32.png Standard for most desktop browsers
    57x57 favicon-57.png Standard iOS home screen
    (iPod Touch, iPhone first generation to 3G)
    76x76 favicon-76.png iPad home screen icon
    96x96 favicon-96.png GoogleTV icon
    120x120 favicon-120.png iPhone retina touch icon
    (Change for iOS 7: up from 114x114)
    128x128 favicon-128.png Chrome Web Store icon
    128x128 smalltile.png Small Windows 8 Star Screen Icon
    144x144 favicon-144.png IE10 Metro tile for pinned site
    152x152 favicon-152.png iPad touch icon
    (Change for iOS 7: up from 144x144)
    167x167 favicon-167.png iPad Retina touch icon
    (change for iOS 10: up from 152x152,
    not in action. iOS 10 will use 152x152)
    180x180 favicon-180.png iPhone 6 plus
    195x195 favicon-195.png Opera Speed Dial icon
    (Not working in Opera 15 and later)
    196x196 favicon-196.png Chrome for Android home screen icon
    228x228 favicon-228.png Opera Coast icon
    270x270 mediumtile.png Medium Windows 8 Start Screen Icon
    (not in action)
    558x270 widetile.png Wide Windows 8 Start Screen Icon
    (not in action)
    558x558 largetile.png Large Windows 8 Start Screen Icon
    (not in action)


    1. Download the Photoshop Action and double click to decompress
    2. In Photoshop in the actions menu, click the hamburger menu and select load actions
    3. Locate the Favicon Creator

    Using the action

    The default image must be square and above 228 x 228 pixels (I recommend personally recommend using higher than this). Click play and the action will create 13 icon sizes in PNG.


    Unoptimized PNGs from Photoshop tend to be quite large. I highly recommend for macOS users the free application ImageOptim for lossless PNG compression. It's brainlessly easy. Drag and drop all the newly created PNGs to shave off valuable KBs off images without any quality hit.

    For the more obsessive, macOS users, ImageAlpha (works in tandem with ImageOptim) allows users to use indexed color profiles to even further reduce file sizes. PNGquant works natively from Photoshop and TinyPNG provides free service usable from your web browser. See favicon cheat sheet for CLI utilities.

    Favicons and you

    As mentioned above this suite of Favicons includes support for (but not limited to): IE11, Edge, Chrome 4+, FireFox 2+, Opera 10.1+, Safari 3.1+, iOS Safari 6+, Google TV, Android Browser 2.1+, Chrome for Android, FireFox for Android, UC Browser for Android, Samsung Internet, QQ Browser, Chrome Store, Windows 8+ pinned sites.

    So what does that leave off? IE8-IE10 and Windows Start Screen Icons. IE8-10 require .ico formats. Notably if you opt to include a favicon.ico, Safari will use the Favicon.ico (macOS/OSX) over the PNG version. This means you will need to create a retina caliber icon. See DaringFireball's guide.

    Due to the unusual formats of the Windows 8-10 tiles, I'd recommend creating these separately.

    HTML (place in your head)

        <!-- generics -->
    <link rel="icon" href="/path/to/favicon-32.png" sizes="32x32">
    <link rel="icon" href="/path/to/favicon-57.png" sizes="57x57">
    <link rel="icon" href="/path/to/favicon-76.png" sizes="76x76">
    <link rel="icon" href="/path/to/favicon-96.png" sizes="96x96">
    <link rel="icon" href="/path/to/favicon-128.png" sizes="128x128">
    <link rel="icon" href="/path/to/favicon-228.png" sizes="228x228">
    <!-- Android -->
    <link rel="shortcut icon" sizes="196x196" href="/path/to/favicon-196.png">
    <!-- iOS -->
    <link rel="apple-touch-icon" href="/path/to/favicon-120.png" sizes="120x120">
    <link rel="apple-touch-icon" href="path/to/favicon-152.png" sizes="152x152">
    <link rel="apple-touch-icon" href="path/to/favicon-180.png" sizes="180x180">
    <!-- windows -->
    <meta name="msapplication-TileColor" content="#FFFFFF">
    <meta name="msapplication-TileImage" content="/path/to/favicon-144.png">

    Is all of this really necessary/is there any penalty to including all these images?

    How often do you really bookmark websites? It's an honest question. Favicons are most useful for desktop browsing as they give a nice indicator. The 32x32 is the only Favicon that truly matters, the rest are Favicons for bookmarking sites. If you only created a single 32x32 favicon, you'd support roughly 95% of users. The biggest losers are mobile Safari, Chrome for iOS, Opera Mini, Blackberry browser being the odd men out either requiring their own formats or not supporting the 32x32 at all. iOS Safari/Chrome only use use the favicon touch icon sizes for bookmarks within the dock. Chances are your users would never see the icon.

    Today, Web browsers are very smart. The only requests made are for the favicon that matches your browser's parameters. Since it takes almost no effort with this action, you may as well include all the favicons for the edge case users.

    Twitter Cards and FaceBook OpenGraph is the new Favicon

    Users now expect Favicons and now expect social media shares to be equally as compelling. Both OpenGraph and Twitter Cards take a little more effort to support: you need to fill out additional meta data but the image sizes can be found here, and either set can be used with regular meta data to make other services (Slack or iOS's Messages in iOS 10/macOS's Messsages) share with beautiful site previews.

    FaceBook Best Practices for Images practices

    Twitter Summary Card with Large Image

    Google MetaData Console

    Future Plans

    Next up is creating an OS X automator version of this, so you won't need Photoshop at all :D

    • #os x
    • #macOS

    Requiem for Final Cut Pro

    I finally took time to fire up Final Cut Pro X. The experience was surreal, it's eerily a foreshadowing of the Apple to come: a paternalistic and patronizing tone to its professional users that seems to shout "We know best" rather than "You know best and we want to provide you with the best". It's the Apple that removes headphone jacks and dreams TouchBars are a feature for professions. The writing was on the wall: The Xserve. The Mac Pro. Final Cut Pro. Soldered on RAM in the MacBook Retina, all in the span of a year. It it be known, 2012 was the last year Apple cared about creative professionals.

    2016 didn't kill the Apple that we once loved, it happened 5 years ago when Final Cut Pro 7 was replaced by Final Cut Pro X. If it weren't for OS X, I don't think any of us will still be buying Macs.

    • #os x
    • #macOS

    2016 was the year of anxiety over the future of the Mac

    "Speaking of the Mac Pro, I was reminded today about a time when Apple was proud of the professional Macs they shipped. Until the middle of last year, they had a dedicated page for professional users and case studies." - Nick Heer, PIXELENVY

    ". In the Mac line, at least, 2017 Apple seems a lot like 1994 Apple: misguided products, propped up by gouging the loyalists. The difference is that today’s Apple isn’t dependent on computers, and indeed barely cares about them thanks to the timespace-warping enormity of the iPhone. It’s like being in an alternate timeline where the Newton was a smash success, so the Sculley/Spindler era went on indefinitely."

    "I’m honestly not sure Apple is even a consumer electronics company anymore. I’m starting to think they’re more a fashion and luxury goods company instead. When they make the devices thinner just for aesthetics, at a genuine cost to their performance or utility, the old “form over function” slam rings a little more true than it used to. As does the idea of charging high prices because they can" - Chris Adamson. Time Code

    "But here’s the problem: in retrospect, what they built was a device based around their own ego needs of proving their critics wrong, not a device that served the purposes of their power users. It’s not configurable, it’s not upgradeable, it’s not expandable: It’s pretty, and full of (for 2013) innovative hardware design, but is that really what Apple’s power users needed?

    I don’t believe so. I think they were much better served by the “cheese grater” Macs of the previous generation, and I think Apple needs to rethink this, and for the high end, go back to more of a developer machine which gives users flexibility to expand it and customize it to their needs. Just like the old Mac IIci, one of the best computers Apple ever built. I propose just this in a piece I wrote about this.

    The Mac Pro, and its possible successor are serving niches within the niche that is the Mac market overall, but it’s an important niche: it’s the power users, the influencers and the developers who build all of the Mac and IOS apps we all depend on. These are important people that support and evangelize the Mac AND IOS platforms and ecosystems, and Apple has done a poor job of supporting their needs for a good three years now." - Chuq Von Rospach, chuqui.com

    "I use a Mac as my daily driver, and have rarely made a tech-related purchase I regretted. And I've never returned a Mac, until today.

    The 2016 MacBook Pro is a mixed bag. Many features (most shared between the two models) are huge improvements in the Pro lineup—like the SSD speed, size and weight, keyboard feel, and Thunderbolt 3/USB-C. Other features (like the Touch Bar) are worse than useless—they make the user experience worse.

    I hope Apple realizes the blunder with the Touch Bar (and with the confusing lineup of laptops they currently sell) and either fix it or remove it entirely. I'd be happy if Apple only preserved the Touch ID/power key combo." - Jeff Geerling, jeffgeerling.com

    While Brooks and others are arguing that iPad will eventually replace the Mac, Gruber is arguing there will always be a need for macOS—specifically a desktop operating system. Despite what my aforementioned dalliance with iPad might suggest, I’m firmly in Gruber’s camp. - , Delusions of Grandeur

    I find a bit of solidarity that other Mac faithful seem to be echoing my my initial reaction to the Mac Pro. As much as I like the iPhone, there's a viable alternative to it. As a web developer and creative professional, OS X is the beginning and end of why I use Apple products. There's no real competitor that's even on the same field mixing a clean UI, and the power of *nix Apple's "courage" is taking its toll. Computer updates do not need fancy press releases but rather a steady component refresh of the latest and greatest, and ability to accommodate the power users rather than Jonathan Ivy's whims. As someone who codes, blogs, designs, creates music, and does visual effects compositing (all of these at some level of professional) OS X is vastly superior. iOS always feels like an apology when I try to do real work. It's great for some people but for those who value raw power and/or raw efficiency, it's OS X or die.

    I doubt I'm the first to notice this, but when will Apple learn that a tiny high end/professional, virtually unupgradable desktop is the computer no-one wants? The 20th Anniversary Mac, G4 Cube, and the Mac Pro 2013 all have been flops.

    • #off topic

    Announcing Bandon Rain Cidery

    bandon rain logo

    So my family started a cidery, Bandon Rain and I've been slowly building up its web presence. The web site, while far from done, is finally ready to be viewed by the public. There's a lot more to be done (lazy loading, better high density screen handling, more info, better design, press kit and inevitably a back end for others to manage the copy) but it's finally taken the mighty first step. They'll be at First Taste Oregon and I'll probably be there as well.

    • #off topic

    Running up MAME Arcade emulation MAME/MESS (Intel 64-bit Builds) on macOS (OS X)

    The last OS X native GUI is forever locked in 2013 at version .149.1 but fear not, you can run the current version of MAME ( version .180 as of writing this). However there is a current MAME port for Intel OS X by @sdlmame_osx.

    Download and install SLD

    Go to libsld.org download and down the DMG. Then install the SDL2.framework into (in your root) Library/Frameworks. This is a library for cross-platform development designed to provide low level access to hardware such as I/O and graphics cards (many Steam games are based on this library for OS X).

    Download MAME/MESS for Mac OS X - 64-bit Intel

    Go to sdlmame.lngn.net and download MAME and decompress it into a folder of your choosing

    Create Roms folder

    Create a roms folder and place your roms within the newly created.

    create a roms folder

    For easier launch, download the m64 launcher from github.com/bamf2048/bamf2048.github.io (Direct link) to zip and place it in the directory. This will launch the app without the terminal and default to the installed games.

    It isn't pretty but it'll get you the latest MAME compatibility. Notably sites like emuparadise have the rom sets. You may want to consider setting up OpenEmu with Mame if you want native GUI. Enjoy!

    • #off topic

    Setting up MAME Arcade emulation & NeoGeo via OpenEmu on macOS (OS X)

    I've written in the past about emulation and OpenEmu, a multi-console emulator front end that uses multiple emulation cores to provide a unified experience to macOS (OS X) emulation.

    OpenEmu also sports MAME Arcade emulation support but its a bit tucked away.

    Step 1: Download OpenEmu Experimental

    Go to openemu.org and click the swatch and download OpenEmu Experimental, and install it.

    website of OpenEmu

    Step 2: Install the MAME core

    Once installed launch OpenEmu, open preferences and select cores. Click the install button next to MAME

    OpenEmu cores preferences

    Step 3: Install games

    Games can be nabbed from the usual suspects like emuparadise. . OpenEmu only supports zipped roms so if the rom comes in a .gz or .rar, be sure to decompress its contents and rezip it. Name it the exact name as before (but with the new extension of zip). OpenEmu's mame core is version 0.149.1 so its significantly behind the windows version (from 2013 to be exact). Some sites will list the earliest known support needed for the rom in question.

    OpenEmu with NBA Hangtime (arcade)

    Notably you'll want access to the dipswitches, hitting F2 repeatedly while the game is launching will take you to most ROM bios screens that enable modes like free play. Note, I had issues resuming games and had to force quit MAME resuming so you may want to hold off resuming games.

    OpenEmu with NBA Hangtime (arcade) dipswitches

    Optional: NeoGeo Emulation

    Emulating NeoGeo games requires one extra step, you'll need to get the NeoGeo rom, the one I used is from emuparadise (just go there and search for Neo Geo Bios) or try a popular search engine. Drag the Neo Geo zip into OpenEmu. You'll see the NeoGeo rom in your game list but ignore it and double click the games as you normally would.

    Good luck with OpenEmu

    • #front end development

    9 Weeks with CodeKit 3 - A Review

    codekit 3 icon


    Back in January of 2015, I posted the longest continuous blob of text I had written since college, a review titled 9 months with Codekit 2: A review, which was a meditation on task management in the world of front end development. The review was popular enough to be ripped off by a few hack writers on other blogs like yourwebsitefirst.com which managed to use a verbatim copy of my review's final points. As the saying goes: Imitation is the highest form of flattery. It seems fitting that this now is officially the longest single article I've written. I'd like this review to be as accessible to novice coders and beginners as possible but it will inevitably be more technical as the differences between CodeKit 2 and 3 requires such vernacular, vocabulary, terminology, and industry acronyms. Readers may want to revisit my previous review for context as I spend more time explaining the usefulness of a task manager and Sass.

    Front End Development is wildly a caustic field to learn as every week we're talking about some hot new JS framework. It's also a wild mix of several professions including but not limited to: app developers, animators, data visualization architects, content/information architects, CMS (content management system) templaters, UX/UI designers, all residing under a very wide umbrella called front end development. The great unifier between these professions is the core technologies: we all live and die (primarily) in the browser. The main focus is on HTML, CSS and Javascript, even if we abstract ourselves from it with technologies like JSX, Sass and TypeScript. I imagine in less than a decade we may see a fragmentation of front end development into perhaps two or more divisions, starting with javascript app developers. I also worry until the fissures start forming, front end web development is a hostile environment for junior developers, due to the dearth of knowledge required to be independently successful. Postulation aside, If I can bring the tiniest bit of sanity or elucidation to this review, then I'll consider this a success.

    Also, this review may sound like I'm focusing on the negative (isn't that the way of 2016?), this is because CodeKit 3 is a very mature, very stable product and you probably should buy it if you like CodeKit 2 or fancy a GUI for task managing. (How's that for a review? You can essentially skip the rest of this review if you want.)

    As with my previous review, I'm starting with a mini-glossary of terms and how they relate to the review below.

    Mini Glossary of Terms

    Command Line Interface(CLI) - A GUIless (graphical user interface) way to interact with a computer. Commands are entered and run via the terminal on a computer, for most users this is done via a BASH terminal on a Linux/Unix variant like macOS (Formerly OS X) or Ubuntu (Linux). For web development, many utilities/libraries (like Node.js) require some basic terminal knowledge to use.

    Compiler - A utility that transforms source code into another type of data that an operating system or program or web browser can understand.  Some languages must be compiled before they can be run and some programming languages use Just-In-Time compilers (compiling on the fly) which are languages that are not compiled until the code is executed. In regards to web development, a web browser compiles Javascript in real time via its own customized javascript compilers. There are many types of compilers and interpreters that differ wildly depending what platform and programming language is used. When I am discussing compiling for the sake of this article, I am strictly talking about compiling code with a preprocessor in order to spit out code in common web languages that are read by a web browser.

    Preprocessor - a utility that processes and converts one type of data into another type of data that another program can use. Preprocessors are not compilers, but for the sanity of this article, I will refer to the action of "compiling". This is often used as a blanket term for programming languages that require a preprocessor to interpret the code into a browser readable language. Sass and Less are often referred to as preprocessor languages.

    Syntactic sugar - Syntax in a programming language that is designed to make things easier to read and understand. However, the end results of syntactic sugar does not affect the core ability of the language. Example: Sass, LESS, JADE and TypeScript's most primary function is to provide syntactic sugar to CSS (Sass/LESS), HTML (JADE), and TypeScript(Javascript), however there is some argument to referring to them as purely syntactic sugar. While jQuery is a powerful library, it's a large part of the value it adds is still syntactic sugar by reducing the amount of lines of  javascript code to more human readable.

    Task Manager / Task Runner - a program that once configured can automatically performs common tasks. Task managers can “listen” for events and automatically run a series of instructions based on event parameters. For web development, this usually means when a file is saved or project structure is altered or a specific command is entered into the CLI, it can trigger a preprocessor to compile code, followed by  reloading a page and chained together with other common tasks. Popular task managers include:

    • CodeKit - A Mac only utility with a graphical user interface
    • Prepros - A cross platform utility with a graphical user interface
    • Gulp.js - a command line utility built on Node.JS + Node Package Manager (NPM) built on Node Streams (asynchronous data flows) via 'pipelines'
    • Grunt.js - A command line utility built on node.js + Node Package Manager (NPM). Predates Gulp.

    Gulp and Grunt are open source command line utilities that allow you to execute custom code or functions in other utilities to compile / minify / uglify / concatenate, pre-compiler languages such as Sass and TypeScript automatically each time you hit save. This is hardly all they can do. Both can be configured to use popular plugins like BrowserSync, a server wrapper that acts as a middleman to live-inject CSS changes and reload when various files are changed like HTML/PHP/Python/JS/JSON files and synch mouse clicks/scrolls across multiple browsers. They can be configured to do auto vendor prefixing for CSS, remove unused CSS, optimize CSS to shorthand, image optimization, image resizing, svg minification, svg merging, create custom builds of libraries like Modernizr, Linting, use Unit Test libs, create basic style guides, generate CSS icons, move files/folders, rename files and folders, zip files/folders, search and replace strings, and even integrate with PageSpeed analytics, create screenshots and monitor file sizes. These events can be chained together.

    That's quite a list of things that can be automated and sadly both Gulp and Grunt aren't the most forgiving utilities for those new to web development and even can be cumbersome or annoying to set up for developers who are in a turn-and-burn environment where project timelines do not account much time for setup. Most seasoned devs using Gulp/Grunt (self included) have a template that they use to easily configure with several favorite tasks, and call it a day.

    DOM  (Document Object Model) - This is your life. Think of it as the rendered version of your HTML/CSS/JS.  A good cliff notes introduction to the DOM is the CSStricks article, "What is the DOM?". Web browsers have the ability to expose the DOM structure via developer tools such as "Inspect Element".

    Package Manager - a package manager automates the process of installing, upgrading, configuring, and removing software, and the respective dependencies. This term often refers to package managers used by operating systems but for the sake of this review, I will be only using this term for web centric package managers.   Node Package Manager and Bower are the most popular package managers for front end developers. When a project requires installing libraries in order to run, these are often referred to as "dependencies". However, Bower and Node are not dependency managers. node.js is more than a package manager.

    Watch - Task Managers have the ability to "watch" files. When files are watched, this means when a file is changed in the watch list, it can trigger an event such as compile sass, compile javascript, copy files, run image processing and so forth. This is probably the most common task for task managers.

    Minification - Every keystroke takes up minuscule amounts of data, measured in bytes. Minification takes out unnecessary keystrokes from HTML/CSS/JS and creates a “minified” version of your code. With Javascript, even variable names are replaced with short names to save data known as uglification. Since HTML/CSS/JS are the core instructions that your browser needs to render the page, this will help aid page load speeds considerably.

    Concatenation - (concat for short ) when programming means combining to two variables’ stored values. When applied to file management, concatting means combining multiple files into one file. This allows for example, many javascript files to be combined into one JS file for distribution. This reduces the amount of requests a web browser must make, and thus (usually) speeds up the data transaction from the web server and reduces the load on the webserver.

    This has to be one of the biggest sanity checks for front end developers in the past 5 to 6 years.

    Auto-prefixing - Browsers often add features before they're an official CSS spec. The supported-but-not-official specification features would require a vendor prefix like -webkit-font-smoothing or for Firefox, -moz-osx-font-smoothing. Keeping track of these is a pain. Depending on your support configuration, writing a simple gradient such as:  background: linear-gradient(to bottom, rgba(30,87,153,1) 0%,rgba(125,185,232,1) 100%) 

    Will also generate all the browser prefixed code such as:

    background: -moz-linear-gradient(top, rgba(30,87,153,1) 0%, rgba(125,185,232,1) 100%); 

    background: -webkit-linear-gradient(top, rgba(30,87,153,1) 0%,rgba(125,185,232,1) 100%);

    background: linear-gradient(to bottom, rgba(30,87,153,1) 0%,rgba(125,185,232,1) 100%);

    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#1e5799', endColorstr='#7db9e8',GradientType=0 )

    This will ensure your code will work on older browsers that require prefixes and prepare for the day when prefixes aren't needed. This has to be one of the biggest sanity checks for front end developers in the past 5 to 6 years. Also, prefixing may become a thing of the past one day, as webkit announced that it was doing away with prefixes.

    SVG - Scalable Vector Graphics Format (based on XML) is the preferred vector format of the web. While I expect anyone reading this to be familiar it's important to understand the flexibility of SVGs. They can be written directly in HTML, in CSS using data URI, or within an image file making them unusually flexible. SVGs also have the ability to contain CSS and CSS media queries and in some scenario, even Javascript. SVGs attributes like fill colors or stroke widths also can be be manipulated via CSS or Javascript. A good way to think of SVG is a visual language describing shapes with XML and math to browsers. Vector images are wonderful in the age of ultra-high density displays as they will always render to the ideal resolution. For those unfamiliar with the differences between vector and raster, I recommend taking a second to read an article such as designshake.net's Raster vs Vector: What do I use?

    Sass - Syntactically Awesome Style Sheets. If you are still writing vanilla CSS you really should stop and start using Sass. It's more or less assumed today that developers are using Sass (or at least LESS).

    This has to be one of the biggest sanity checks for front end developers in the past 5 to 6 years. If you'd like a quick explanation of why you should be using Sass, please visit my original CodeKit 2 review or visit an article such as Scotch.io - Getting started with Sass..

    Source map - If you inspect element and use minified CSS file, it can be a pain to track down what line of code that the original CSS originates from as everyone is on one line without spaces. Source Maps are ancillary files generated to map where the original contents of a file reside for web browsers for CSS and javascript. Once a browser is configured to use source maps, JS console errors will display the line of the code based on the non-minified / uglified files and CSS references will display where the original CSS originates, down to the line on the appropriate .scss file.

    This has to be one of the biggest sanity checks for front end developers in the past 5 to 6 years.

    Bless - A lesser-known bug in Internet Explorer which causes CSS to be completely ignored after the limit of selectors allowed in a single CSS file is reached. Bless provides a simple solution: parse the CSS file into multiple segments.See blesscss.com for more details.

    BrowserSync - an open source application that allows for synchronized browser testing, and the ability to manipulate the page in realtime via code injection. The most common use is pairing with Gulp or Grunt and used to trigger browser reloads on code changes or live CSS code injections after a task manager detects the CSS file has been altered. This allows the browser to seamlessly change the layouts in near realtime or trigger page refreshes on HTML/PHP/Python/JS/etc changes when properly configured. It even allows the user to pair page interactions to multiple devices. If a user clicks on a menu in one browser, the same menu will be opened in all other browsers that are using the BrowserSync web server. It's pretty magical to click a link on an iPhone and see both the desktop browsers and the iPhone load the requested page. If that weren't enough, BrowserSync also features remote device inspect element by using the JS library Wienre. Wienre gets several mentions on this page because it can be a massive time saver for extreme edge case browsers that do not have the ability to inspect element. For more info, visit browsersync.io. There are few utilities that make my life easier on a daily basis than BrowserSync + Sass.

    This has to be one of the biggest sanity checks for front end developers in the past 5 to 6 years.... (you get the idea)

    About My Workflow

    It's always interesting to consider how my workflow has evolved since my last review as a lot can change in 2 years. When I wrote my CodeKit 2 review, I was still using Sublime Text, and my day-to-day task manager of choice was Grunt on a RAM/Storage starved MacBook Pro Retina 2013 (8GB of RAM/256GB SSD). Most of the projects were CMS sites that were coming through the door. Today, I'm using Grunt and Gulp, Atom, working on CMS sites and Cordova (phonegap) apps. OS X is still my platform of choice and my company bought me a shiny MacBook Pro Retina 2015 (16 GB of RAM/Dedicated GPU/512 GB SSD). The suite of my other tools hasn't changed much: iOS Simulator and GenyMotion are my go-tos for simulators. I still use Parallels and sometimes VMWare for IE. Sketch is my world, so is Photoshop and I'm starting to play with Principle for interaction design. Tower is my Git Client of choice and Kaleidoscope is my show-diff/merge tool, and Grunt/Gulp are my task managers of choice. A few other utilities I lean on are ColorSnapper, ImageAlpha, ImageOptim, Xscope. I do JS but I'm still bolstering up on major frameworks. I remember life before CSS, the transition with absurd workarounds and even have toyed with postCSS. Also my job has evolved as I'm more client facing than ever. I mention all of this as not some sort of a humblebrag but because every front end developer's job currently encapsulates many practices: Interaction Design, Graphic Design, Web Accessibility, Javascript application development, User Testing, Data Visualization and so on. What my daily work flow looks like could be wildly different than someone else who wears the same job title as me. I have yet to write unit tests but someone reading this review might spend a bulk of her day testing code. My job inevitably will be not an accurate representation of front end development as a whole, just a segment. Use this information to compare and contrast as my needs will be inevitably different than yours.

    What is CodeKit?

    By now hopefully you understand that CodeKit is a task manager with a GUI, designed primarily to compile various preprocessor languages. These languages include: Sass, Less, Stylus, JavaScript, CoffeeScript, TypeScript, Pug (Jade), Haml, Slim, Kit, Markdown and JSON. It also comes pre-baked with support for the following frameworks / libraries: Bourbon, Bourbon Neat, Bitters, Zurb Foundation, Google Web Starter Kit, Susy, Nib, Jeet and Compass. This isn't to say that these are all that CodeKit is compatible with, but rather simple ones that can be quickly installed via CodeKit. Codekit can even support more languages using its hooks system to initiate CLI processes to keep all your tasks primarily within the GUI.

    Simply put: Everything that CodeKit does, can be performed by Grunt or Gulp. What you're paying for is a refined GUI for extremely quick and nimble setup and a much lower learning curve. Even as a seasoned dev, I'll admit that I can get rolling with CodeKit with in less time than with my grunt or gulp starter templates. CodeKit's primary value is that it lowers the barrier to coding, and cuts out some of the set up. Drag and drop your project in, then create a few paths for where compiled files go and which get concatenated and you're back to your IDE. CodeKit isn't aiming to replace all complex tasks for edge cases that Gulp and Grunt can do but rather all the common ones. It's designed to be the daily warrior, akin to my favored task setup in my grunt and gulp template files.

    For less seasoned devs, CodeKit is indispensable. While I'd argue eventually it's a good idea to familiarize yourself with a CLI task manager, the front end developer pool is a deep one to jump into head first. There's decades of tacit skills, like IE or Safari hacks (browser testing / device compatibility), learning how to vertically align things with CSS (this is still a problem even though CSS's W3C Recommendation dates back to December 1996), how to leverage ES6, learning the ins-and-outs of a syntactic sugar preprocessor, what new hot JS framework is bringing all the devs to HackerNews, and so on. The state of front end development is a precarious one so anything that frees mental space for concentrating on core tasks is welcomed. This is where CodeKit truly shines.

    What's New

    First and foremost, CodeKit got a facelift... if you can call it that. It's gone hyper minimalist to the point of abstraction or undesign. I actually found Codekit 2's "look" pleasing even if the interface was occasionally bumpy. I can't say I'm a fan of the new GUI. I also was not a fan of Yosemite's design or iOS 7's design. Both took several iterations to strike a balance between minimalism and design and I'm hoping perhaps CodeKit 3 will follow this trend of slash and burn and then replanting. Almost all text has been removed such as "Server", "Preview", "Assets". Even worse, a mouse hover doesn't bring up any tooltip explanation. Instead you're left with "Click and hope for the best". When I first was writing this review, I initially missed CodeKit 3's package manager leading me to believe it had been removed. It took accidentally clicking on it to realize it was still there. It's not a great start for a utility that's value is explicitly that it's easier to use than a CLI. The redesign is not a total loss: there's a nice project overview that also includes a build project button so builds can be triggered manually.

    codekit's main window

    That said, any caveats with CodeKit 3 are minor seeing as the primary function of a task manager is to operate silently in the background until something triggers it to take action (usually hitting save on a file). The real changes are under-the-hood.  The full list is on CodeKit's website, but I'll highlight what I think are the most important new features. Don't worry if you you're unsure what the differences are as as I'll break it down later in the review.

    • Build System: Trigger builds from UI. Project migration
    • Image Optimization: SVG optimization, gif optimization. Better optimization engine for PNG/JPG.
    • Javascript: Babel transpiling and babelrc support, React compiling , ESLint and eslintrc support, 
    • Server: Simple SSL Support
    • Hooks: Matching support with RegEx, per file triggering, hook error logging
    • Custom Language Support: Add Your own languages and combine with hooks
    • Bower: Creates/updates bower.json, version support for components, rename/relocate bower folders
    • CSS: Bless, autoprefixing, Minification, Source mapping (for shits and giggles I suppose) for regular CSS files
    • Other: Bitters framework support, Pug: Jade's successor with backwards compatibility for Jade

    My Wishlist from late 2014

    For fun, let's compare CodeKit 3 to my late 2013 wishlist of features found in my CodeKit 2 review.

    • Optional Remote Inspect Element (FireBug’s JS beta or otherwise would do nicely).
    • Remote server tuning (I get JS errors in IE10 and IE11)
    • SVG minification
    • Ability read Grunt or Gulp tasks and pair them to CodeKit’s functionality (A man can dream…)
    • Ability read Bower configurations and automatically install missing libraries

    So of all the features other than my pie-in-sky dream of Grunt/Gulp pairing, all but one of my requests were addressed.  Did Bryan Jones read them? Probably not, these were pretty reasonable and probably obvious feature requests. The best it can affirm is that I am a front end developer who has enough technical prowess to know there are reasonable features that would make my life easier. I stress reasonable because I could wish for a "make website better button" but its insanely non-specific. 

    Overall I'm pretty happy that all but one target was hit. I'm still surprised that CodeKit doesn't have a remote element inspection mostly because it doesn't seem to use browsersync. BrowserSync has the ability to use Weinre, and track user interactions to pair across multiple browsers. As near as I can tell is its a custom WebSockets configged server. Perhaps one day, CodeKit 3 may switch to BrowserSync.

    Code Compiling

    CodeKit's primary function is compiling code. If you've used CodeKit 2, then configuring CodeKit 3 is pretty much the same process. CodeKit will read imports in JS/SCSS/LESS etc but the initial pathing is set up via the UI. CodeKit 2 never was perfect about making sense of project pathing and CodeKit 3 makes no more attempts to improve it. It'd be helpful to see an overview of sorts to know what files are outputting to where at a glance. That said, its no less esoteric than reading JSON config files. All linked files can be viewed from a master file but without any pathing info nor can listed files be right clicked to "show in finder" or "open in editor".

    CodeKit's file pathing window

    All the front end coding greatest hits are here: concatenation, minification, source map, auto-prefixing and blessing.. 

    Compiling is as fast as Gulp or Grunt, as the compilers in CodeKit are built around the same open source software. Without a technical way to benchmark, the best I can say is it feels as zippy as I'm accustomed to with Gulp. Compiling Sass can differ widely based on any number of factors like the obvious complexity of a project, how bogged down your computer is, and so on. What I can say with certainty is CodeKit idles well. Grunt taxes the CPU even when just watching files. Gulp seems to be much better at this and (to me personally) marks the largest difference between gulp vs grunt (despite all the hype around Gulp's asynchronous abilities). CodeKit seems right in line with Gulp.

    Builds are triggered by hitting save on a watched file or via hooks, and hooks can be set to trigger other actions. If you're adventurous, you could configure  CodeKit on a save to copy files to an FTP.

    CodeKit also comes preconfigured to refresh the page on HTML/PHP/Python/JS/Pug etc saves and to inject CSS without page reloads. If you're still in the old world of manually page refreshing, you'll wonder how you lived before code injection and auto-page refreshes.

    CodeKit can also sort JSON content to be organized, and this can be triggered on file changes so you can always have alphabetized JSON files.

    Lastly, like any good code compiler, the error log is the main event. More than likely, almost all your time in CodeKit will be spent in the error log. Its presented in a single pane, cleanly formatted. Successful builds are marked in green dots and bad in red. It's simple and effective, and now has the ability to consolidate external compilers to the error log, which was to some ire of me before.

    codekit 3's error log

    Internal Server

    If you've used CodeKit 2's server, it now has SSL provisioning and event syncing. I never knew or noticed the SSL issue since all my development is done locally but I imagine for some this is a crucial fix. Calling CodeKit's internal server, a "server" may be misleading. Akin to BrowserSync, it's a simple wrapper that can be mapped to any domain or directory, and injects the necessary JS to trigger page refreshes and CSS injection.

    codekit 3's Server Pref

    CodeKit now features event syncing for any page clicks, forms and scrolls. This is incredibly useful for testing multiple browesrs and devices simultaneously. This is a big addition.

    As mentioned previously, Wienre allows for remote inspect element. This may not seem like a killer feature as Android and iOS offer remote device inspect element via using a desktop browser to run inspect element on physical device connected via USB or simulators. Occasionally as a Front End Developer, you may be asked to test on an esoteric browser like Amazon's Kindle's Silk which doesn't have Chrome or Safari device inspection. Wienre is the answer.

    CodeKit's Servers works well for a wide variety of projects and even integrates with MAMP.

    Image Optimization

    Saving an image from most image programs is not the most data efficient use of a file format. Often they bundle in meta data, and do not use obsession-tuning that makes the most use of compression, optimization techniques. For JPEGs and PNGs, there's a set of algorithms that optimize images and can shave significant amounts of data off them without affecting the image quality. Since these require zero input from the user other than what files to target, its a painless way to shave significant amounts of data off file sizes.

    CodeKit's image optimization got a much needed revamp. Prior, image optimization worked but had some serious caveats. ImageOptim did a much better job for generic PNGs and JPEGs, (often able to cut another 15% off the image size without any quality loss) and CodeKit had no support for SVGs. CodeKit 3 offers a massive upgrade. It's not at the same level as tuning PNGs with ImageAlpha (a manual process), it's every bit as good as ImageOptim. In my tests of a 4.1 MB PNG, both ImageOptim and CodeKit 3 produced a 2.6 MB PNG file. CodeKit 2 produced a 3.1 MB image. Results will vary wildly based on the individual image. After running several tests against ImageOptim, CodeKit 3 is pretty much indistinguishable from ImageOptim. Also, Codekit 3 can be tuned to also watch files to recompress on a file change unlike CodeKit 2.

    See the Pen CodeKit SVG Optimization by Greg Gant (@fuzzywalrus) on CodePen.

    SVGs as described in my glossary are essentially XML files. This means a set of tricks like minification and uglification can be used to reduce file sizes. Sketch and Illustrator created SVGs that contain a lot of extra data and are not minified by default. The process of SVG optimization is much more akin to Javascript optimization than PNG/JPEG optimization. Clicking on an SVG gives a host of options, all from the SVGgo library, a set of SVG specific optimizations. SVGs can be set to copy to other locations leaving the originals unaltered.

    I'm quite fond of this and CodeKit provides the best quick UI for SVG optimization I know of. This is a huge win for CodeKit.

    codekit 3's svg options

    About the only thing CodeKit doesn't do is export inline SVGs or crunch all SVGs into a single SVG file, which are edge case optimizations. I'm guessing for the truly ambitious this is obtainable but this is pure speculation as I haven't had time to mess with hooks.

    In future releases I'd like to see CodeKit go beyond simple optimization, specifically creating sets of resized images based on rules for responsive images. The would take some careful consideration to deliver a simple solution but I'd love to easily create image sets from an original source image. Perhaps that's a sister utility waiting to happen for CodeKit? I'm not sure...

    Package Management

    codekit 3's package manager

    Codekit 2 made an admirable attempt to bring package management to CodeKit although I always found it a little confusing. CodeKit 3 is still no different and the interface isn't entirely great. Its hyper minimal and allows for a set of favorite components, and the ability to search for new ones. Unfortunately, the search bar is hidden and takes poking around to find.

    CodeKit offers easy installs for a few well used add-ons (Bourbon, Bourbon Neat, Bitters, Compass, Zurb Foundation, Susy, Nib, and Web Starter Kit) via the project preferences pane. CodeKit also offers Bower support and can read bower.json files to install dependencies. I'm unsure if CodeKit can use .bowerrc configs and I plan to test this when I have time.

    CodeKit also offers the ability to create your own framework of commonly used files as before. I can't say I personally like CodeKit's package manager as I found it easier to simply search and find the frameworks or plugins I was looking for via google and installing them (via bower or node or manually) than the guess and check method of CodeKit . I do like the Bower config file support as even junior devs can understand the bower.json after a little bit of reading.

    CodeKit doesn't offer package.json support for NPM (node package manager). Deal breaker? Not at all, but it is a nice-to-have feature to make CodeKit all encompassing.


    codekit 3's hooks menu

    This section is TBA.

    In the interest of time, I may revisit this as it is important but also could double the amount of time it'd take for me to write this review. I updated my CodeKit 2 review over 7 times over the course of 2 years and plan to do the same with this review. CodeKit 3 hooks look MUCH improved to the point of being much more useful.

    The CLI task managers vs CodeKit 3

    terminal window displaying Gulp on macOS

    Gulp as exciting as it gets

    Both Grunt and Gulp are immensely powerful. As I was working on transitioning a Cordova project to Gulp after using CodeKit 3, I was debating if I wanted to try out a plugin to auto generate a style guide and to delete unused CSS. The last project, I created a customized Modernizr build based on scanning my CSS file for modernizr classes using a grunt task. Grunt and Gulp have amazing support and it shows but the setup is intensely unfriendly. It'd be easy for me to go "greybeard" and detest kids and their GUIs but they have their place.

    How much is a clean and easy to use GUI worth? This is the most prescient existential question to CodeKit. It'd be easy to say not much, or launch into a tirade about the superiority of Gulp but this for years was at the very crux of Apple's OS X as it was Unix but dressed up and cleaned for day-to-day use. This isn't the best analogy and we have better analogues to CodeKit 3.

    CodeKit does for task management as what Tower does for Git; provide a GUI to CLI utilities. Even as a world weary web developer, I still live by Tower. Tower can't do all things that Git does but it does enough and makes it digestible enough where I rarely use Git via the command line. The only time I can really recall CLI Git in the past year was for git resets and nuking a branch. CodeKit can do the same albeit with a few more limitations. (Tower recreates the functionality Git whereas CodeKit recreates plethora of utilities)

    CodeKit does something that I find valuable: it gets me to writing code more quickly. My personal portfolio always has been managed by CodeKit, and even when I start projects and need to rapidly code something up, I tend to lean on CodeKit. It reminds me of my early days as a digital musician. I learned to use Reason 1.0 in the year 2000. Reason was novel since it was immensely easy to spin up and start making music with minimal delay. Around 2004, I outgrew it and switched to Cubase and but I still pine for the simplicity of Reason in which project setup was a lot faster and took a lot less overhead. It wasn't as powerful but it got my idea out much more quickly. It's also why I still use Apple Motion despite Adobe After Effects being superior. That's the niché of CodeKit to me today.

    More importantly, CodeKit allows junior developers to focus on learning Javascript, CSS, HTML and/or any other preprocessor language without struggling through esoteric configuration. If you're already using Gulp and/or Grunt, CodeKit might be a tougher sale. For those looking to jump into front end development, CodeKit lowers the hurdle of learning modern development where automation of tasks has become integral.

    Depending on your job needs or workflow, CodeKit may be all you ever need, or you may quickly outgrow it (and anything in between). This is a question I cannot answer for you but I can say that CodeKit can be useful even to am accomplished developer.

    CodeKit 3 vs Prepros 6

    Prepros (to my knowledge) is still the only competitor to CodeKit. Prepros offers a very similar feature set.

    prepros 6 iconPrepros

    codekit 3 iconCodeKit 3


    • Sass
    • Less
    • Pug/Jade
    • CSS
    • Stylus
    • Markdown
    • Haml
    • Slim
    • CoffeeScript
    • LiveScript
    • Typescript
    • Babel
    • CSSnext
    • Sass
    • Less
    • Pug/Jade
    • CSS
    • Stylus
    • Markdown
    • Haml
    • Slim
    • CoffeeScript
    • LiveScript
    • Typescript
    • Babel
    • Kit
    • JSON


    • Live Reload
    • Minification, Uglification, Concatenation
    • Browser Sync (Scroll / click / form sync)
    • Image Optimization for PNG / JPEG
    • FTP
    • Remote inspect element
    • CSS Injection & Live Reload
    • Minification, Uglification, Concatenation, Bless
    • Browser Sync (Scroll / click / form sync)
    • Image Optimization for PNG / JPEG / GIF / SVG + Keep original files
    • Hooks to add support for other languages and execute terminal commands
    • Package Manager via Bower & GUI
    • Linting for JS/SCSS/Stylus/CoffeeScript
    • Enforce Coding Styles
    • Quick installs of popular frameworks

    Absolutely the biggest difference between Prepros and CodeKit is, CodeKit is macOS / OS X only. Prepros also offers Wienre support which is nice, and a built in FTP. For most people in production environments the later isn't really useful, as you should be using staging servers managed by a utility like Jenkins but that's another story.

    I wrote a review on Prepros 5 that's still pretty relevant to Prepros 6 that's worth reading as I break down the superiority of CodeKit in detail. If you're a Windows user, you can effectively stop reading this review as CodeKit is OS X only or consider getting a Mac to run CodeKit. This isn't a slight against Windows as Microsoft has made some serious sweeping changes to allow Bash in Windows, which means no longer the dissonance of trying to use frameworks like node.js on Windows which required a special Node CLI. You'll be hard pressed to find Windows front end developers but I assure you, they're out there and perhaps reading this review.

    OS X users (excuse me, macOS) users have the agency of choice between Prepros vs CodeKit but Codekit is the clear winner. Codekit's ability to use external compilers saved the day on a few projects in the past for me. When I was working on a project that required a newer version of LibSass than CodeKit offered, I simply changed the engine to use the latest compiler instead of waiting for an update. Prepros does not have this ability. Also, Prepros doesn't have the nice framework library bundling, nor SVG optimization, ability to create hooks, create custom frameworks, and is a little more CPU heavy.

    CodeKit still leads the race, although Prepros has gotten a little better with javascript. I also mildly prefer Prepros's UI after Codekit's redesign. CodeKit 3 allows you to grow more than Prepros and that's exceptionally important as you'll always be in a grind to automate your workflow as a developer. Prepros isn't bad, its just not as good as CodeKit.

    Looking forward: Where do we go from here?

    I made some pretty bold feature requests back in 2014 and to my surprise, most were answered. So what would I like CodeKit to do in the future? This is tricky as some useful features like SVG-to-WebFonts have a limited shelf life, as webfonts are bad for accessibility.

    Are these the best features? Perhaps, perhaps not. I'm not as confident with my asks as I was in late 2014. This may be a case of the Aristotlian principle: "The more you know, the more you know you don't know" but I think the easy-fixes are mostly done. Perhaps I'll have some better insight later in 2017. We're starting to get to more avant-garde features as Front End Development itself becomes more avant-garde. I'll probably have some more insight as I start my venture into the world of React in 2017.

    Final Thoughts:


    • CodeKit 3 is a logical step forward and almost all the things I wanted from CodeKit 2 are in 3.
    • Backwards compatible
    • Improved server now offers event syncing
    • More languages and more JS centric features
    • Much improved image optimization
    • External processors and hooks
    • More build configuration
    • Less resource intensive than Grunt when idling
    • Seems a bit faster
    • CodeKit 2 users get CodeKit 3 (sans new features) for free


    • New GUI obfuscates features in nebulous icons and suffers for it
    • If you're on a CLI task manager, not a huge compelling reason to use CodeKit
    • Must make current project active (Only watches one project at time)
    • Even after weeks of use, still not a fan of the UI update

    CodeKit is the beginning and end as far as GUI task managers go. It's quick. It's powerful. It lowers the learning curve for preprocessor languages like sass, typescript and even babel (a little). It's $35 for a first time buyer and offers upgrade pricing. CodeKit 2 users can continue using CodeKit 3 but only with the CodeKit 2 feature set. It's a nice gesture for long term support and users can upgrade at any time. Currently the paid upgrade pattern for CodeKit is once every two years,so you can expect around 2 years of support for $35 and then upgrade pricing. CodeKit 2 had a lot of bug fixes and mild improvements over time. At launch CodeKit 2 didn't have Bless or autoprefixing, that came in version 2.1.9 for compass projects or sourcemaps for stylus until 2.1.4. There's probably more features that are bound to hit CodeKit 3 that aren't on this list.

    If you outgrow CodeKit, chances are you'll still consider it money well spent.

    Versions Review

    3.0.1 to 3.0.4

    Price:  $35 first time purchase.


    Fun fact: After writing 11,000 words in three reviews between CodeKit 2, Prepros 5 and Codekit 4, I've written 42 pages single spaced or 84 pages now on GUI task managers for Front end development. This review isn't finalized but I wanted to get this up ASAP, spelling errors, bad grammar and all.

    12/21/16 update: Minor editing / grammar fixing, a lot more reference links, trimmed down intro.

    12/23/16 update: Minor editing still, (a little list rambling, a little more content), better Prepros vs Codekit breakdown, error correction about event syncing

    • #front end development

    The Mac Pro that wasn't

    We hit a milestone. The Mac Pro 2013 was released December 19, 2013, marking 3 years without a single update.

    The Mac Pro 2013 probably marks the most misguided product they've released. Even 4 years later, I can name several TV shows and even movies where editors re-use or rent 2012 Mac Pros in LA.

    A successful Mac Pro would a simple rehash of the 2012 with an update:

    • Bring back the old chassis or similar
    • Modern CPU/Bus/GPU/RAM configurations
    • User upgradable RAM
    • 4 PCIe Slots
    • USB 3 + 3.1c Ports
    • ThunderBolt 3
    • (at least) 2 legacy SATA drive bays internally

    Pro users aren't looking for unique or avant-garde, but rather boring boxes that let you configure your desire with just boring yearly hardware refreshes with boring updates that the average consumer doesn't care about. Apple can phone it in and the creative market wouldn't leave. However if they ignore it they will. There's sect of video editors/illustrators/video compositors/3D animators/audio professionals/scientific modelers/developers/power users that just want an upgradable box that runs OS X. These users do not need press events or big marketing campaigns, just an order page where they can throw their money.

    • #front end development
    • #politics

    In 2016, Browser plugins tap into journalism

    Plugins that do mildly comical things have been around for awhile but 2016 is the rise of the political browser plugins. While it didn't start with John Oliver, one of the first high profile plugins was Drumpfinator. While a fan of John Oliver, it was a one note gag, and to me personally, wasn't that funny but I appreciated commitment. There were a few others such as a browser plugin that replaces pictures of Trump with kittens, a plugin that attempts filter Trump mentions from any page but that seemed to be the extent of it.

    However, the rise of fake news spawned something far more interesting: injecting in-page fact checking content. Slate created its This is Fake chrome extension that labels Fake news as such. Even more interesting and more resource intensive is Washington Post's RealDonaldContext which provides Washington Post's analysis on a per-tweet basis of Donald Trump tweet claims. This is something entirely new as far as I can think of as its an on-the-fly pro-active level of journalism that's responding to your interactions without having to even go to the parent website. I have a feeling it may be scratching the surface of what's possible. This strikes me as something new and unrecognized as such. Both Slate and Washington Post are avant-garde, stretching way we consume news with contextually aware experiences.

    • #front end development

    Front end horror story - sIFR and random SWFs (and fix!)

    Front end development is always an adventure. Today I found something I forgot even was a thing: Using Flash to render non-web safe fonts. Back in the day when @font-face support was limited, the only real way to ensure custom fonts for (virtually) all users was using image files or using a flash file. The later lead to an inventive solution, Scalable Inman Flash Replacement (sIFR), which allows a javascript/flash driven approach. JS was used to target page elements, read the text contained on the page, and overlay an SWF containing the same content with the customized font over the top and feed the SWF the text. This was used in 2005, and actually was pretty genius as:

    • Any desired font could be embedded into the flash file
    • No images were required
    • The same flash file would be used through the site, thus cachable and more efficient than images for bandwidth
    • Any copy updates to the HTML were reflected immediately as the JS simply fed the text into the SWF
    • Most people had flash, and if they didn't, the text in question would still be rendered as plain ol' text, just not with a custom font
    • Predates jQuery

    For the truly curious, you can find the sifr generator here.

    Sure you took a major performance ding in 2005 for polluting your site with random SWFs but ended up with a site with custom fonts. It was an elegant application to a stupid solution.

    Fast forward to 2016: Flash is dead and websites now ask for permission to run flash. This is an unforeseen problem as it doesn't fail gracefully in modern browsers and in the case of FireFox leaves black squares on the web site, waiting for the user to allow flash to run.

    unrendered block of text flash has failed firefox

    How to fix

    Fortunately the quick fix is easy, remove the sIFR.js. Look for sIFR.replace in your JS to see all the targeted text that's being replaced with an SWF, to write out new CSS rules to format. Hunting down the fonts can be a bit of a chore but hopefully the swfs are named after the font. If you can't find webfont versions, just hit the usual grounds of Google Fonts or Font squirrel to find "like" font replacements. In 2016, its unlikely many sites are still up using sIFR.js. Good luck out there!

    Example of sIFR

    var euro = {
      src: '/swf/clarendonCondensed.swf',
        wmode: 'transparent'
    sIFR.replace(euro, {
      selector: '#col1 h2',
        css: [
        '.sIFR-root { color: #589f28; font-size: 36px; text-align:left; cursor:pointer; }'
    • #politics

    Presidential Rule by 140 characters

    As technology, social media, and politics meld ever deeper, we're seeing what a presidential rule by tweets may look like: political enforcement by twitter. The Washington Post asks, "Did Donald Trump tank Boeing’s stock because he was mad about a news article?" Regardless of motivation, the executive branch seems to have new power, and one that has no precedent for regulation.

    • #ios
    • #android

    Emerge launches WCAG Checklist

    The company I work for, Emerge Interactive launched its free A11y WCAG Accessibility Checklist, a simple checklist based off of Luke McGrath's and W3C's recommendations. It can now be found on Apple's App Store and Google Play. This was an internal project spearheared by former coworker Joe Watkins but included most of our team. I lent my hand, especially in the development of the microsite.

    Accessibility is important when only 5% of a survey of 215,942 people were deemed fully computer literate and 1/3 is can completely medium level tasks. What we design has to be digestible by all.

    • #politics

    What post truth looks like

    In something that reads like a scrapped episode for "Black Mirror", Trump's security advisor, Michael Flynn tweeted a link to a wantonly fake story about a bizarre conspiracy involving the Clintons, sex-trafficking, and a DC Pizzeria. End result? A man "investigating" (by way of a rifle) barged into the restaurant and discharged his weapon. Conspiracy theorists exercising unfathomably bad judgement and scary behavior isn't new, the mainstreaming by elected officials and social media is. (Look no further than the comments found on the official reply from the targeted Pizzeria). In year filled with a lot of massive stories, the rise of fake news may be in hindsight the biggest story of 2016.

    • #offtopic

    Amazon's "You Will"

    Amazon announced Go, a fully automated check out brings us one step closer to the AT&T's strangely accurate "You Will" future. In a twist of irony, AT&T has had almost nothing to do with any of the innovations proposed. For the Amazon addition, see this advertisement. The only technology proposed in all of the 6 adverts truly out of reach is "Have you ever renewed your driver's license from a cash machine?"

    The real question is if this tech becomes licensed, who'd be silly enough take up Amazon on it? It's every bit as nihilistic as Uber's "Drive with us while you still can while we work on automating your job".

    • #offtopic

    Hulu's rise

    Recently upped my subscription to Hulu from paid to ad-free and haven't regretted it. The real shocker is the slow uptick in quality programming, Causal was good, 11.22.63 was great and Handmaiden's Tale's timing is phenomenal. I'm finding myself looking at Hulu more than Netflix for the #2 spot behind HBOGO.

    Also, I recently finally for the first time used Prime to watch TV for Man in the High Castle and Grand Tour after having Prime since its inception. They were surprisingly good.
    • #politics

    Trevor Noah is finding his voice

    I sat down today and listened to Trevor Noah's interview with TheBlaze pundit Tomi Lahren and held off reading reactions until tonight, The Atlanic.com almost verbatim matched my reaction on Facebook. "He's finding his voice". Trevor doesn't score any KOs but does try to pin down Tomi to explain what sort of protesting she'd find acceptable to only have her evade, and evade more, and manages to get in a few humorous jabs. There's the same visible tension that's reminiscent of Bill O' Reilly and John Stewart whenever they shared a screen.

    One of Trevor's quirks, his inability to get worked up or as emotionally invested as John Stewart suddenly becomes part of his appeal. If Stewart's cross to be bear was the from frustration from the stupidity of the Bush Jr era, Noah's looks to be the exasperation from the intolerance of the Trump era.

    As a long time Daily Show fan, I've found myself rather taken with Samantha Bee's aggressive punk-rock zero-tolerance for ignorance which has Stewart-like quality. That said, I'm rooting for Trevor as he has the biggest shoes in entertainment to follow. I look forward to see where Noah goes from here.

    • #charity

    Never Let Your Guard Down On Social Media - Standing Rock Edition

    I usually keep my professional blog free politics that do not concern web development/digital privacy/security but under the current climate I have a feeling that line will be blurred a bit.

    I was on FaceBook and a friend of mine shared a t-shirt with Dwayne "The Rock" Johnson wearing a shirt that took a pro-Standing Rock protest standpoint. Instinctively, I clicked the Like button and decided to check out the shirt more, as I've been one to buy such things to support causes, including a shirt by a local Portland Company where proceeds went to Planned Parenthood.

    FaceBook Post of faux shirt

    That's when things got fishy, the page redirected to another website, standwiththestandingrock.com/support redirected to teezily.com, a site that had zero information other than general sizing and color options for the t-shirt. I poked around and didn't see any notes about profits or sales. Next I went to standwiththestandingrock.com, which again redirected to another site. Clicking back, I noticed the original photo of The Rock looked mighty fishy so I did a quick reverse image search.

    Original image

    I re-read the copy, no where did it say proceeds went to Standing Rock protesters or any native tribes, simply just show "support" in very engrish like writing. Clever. A WhoIS search returned no information on standwiththestandingrock.com other than it was registered on November 7th.

    While there wasn't any real "scam" in the traditional sense (I'm sure I'd of received a shirt), it was specifically tailored to make me fill in the gaps if I weren't paying attention.

    • #front end development

    Using Modernizr to detect IE versions

    Recently I've been using grunt-modernizr, which is pretty fantastic as it can be set to build a modernizr js file based on the classses that appear in your CSS or JS, as I've been trying to move away from HeadJS. While this post might be a bit antithetical to the point of Modernizr, there are plenty of reasons why to detect IE versions

    IE version Test Class
    IE8 and below csstransforms3d .no-csstransforms3d
    IE9 and below subpixelfont .subpixelfont
    IE9 only csstransforms3d subpixelfont .no-csstransforms3d .subpixelfont
    IE10 and below borderimage .no-borderimage
    IE10 only flexbox .flexboxtweener
    IE11 only borderimage .borderimage

    Note: borderimage, csstransforms3d are a core detect. Please note these detects are not IE exclusive.

    • #front end development

    I hate nouns instead of version numbers for OSes

    The conversation goes something like this: "Can you check out the rendering issue on Android?"

    Usually it's followed up with, "What version of Android is this happening in?"

    "Franken Berry"

    Then its off to google...

    It's telling that Apple never applied its naming scheme to iOS yet Google felt it necessary to do as such on Android. Inevitably every time I complain that about this, someone feels compelled to point out "But Greg, it's in alphabetical order!", but Google had to go on and fuck up a potentially good idea. There's no sense of versioning. A ≠ v1.0 or v0.1 and N certainly does not equal v14 or v1.4 So much for cleverness. Apple with OS X named only its yearly releases, any point releases of that OS didn't get its own namesake like "Tiger Cub" or "Lion Pride". Android, any candy snack could be massive upgrade or a minor point release. As a decidedly non-Android user, I'm not about to commit 14 sugary snacks to memory, and I question what happens after 12 more releases of Android?

    It's a small burden but I can't help but be annoyed.

    • #windows

    Installing Magic Pad on Windows 10 for a non-Mac

    The Apple Magic Pad doesn't work out of the box on Windows. It takes a few steps and some features simply aren't available to windows, even in with a Mac running Windows natively such as three+ finger swipes. You'll need a Windows PC with Bluetooh 4.x. I'm going to skip how to connect bluetooh devices to Windows 10 as Microsoft provides basic instructions and there's multiple ways to connect to bluetooth from a Windows PC, including the Control Panels.

    Step 1: Download Apple's bootcamp drivers

    Unfortunately, you'll have to download ALL of bootcamp's drivers, for a 800+ MB payload. The latest version that can be downloaded from Apple's website are Boot Camp Support Software 5.1.5621

    Step 2: Unzip but Do run run the main installer

    Screen shot of Window 10 displaying the Apple Executables

    Do not run the main boot camp installer. Within the Bootcamp Folder, locate the drivers folder and open the drivers folder. Install the AppleWirelessMouse64.exe and AppleWirelessTrackpad64.exe and AppleMultitouchTrackpad64.exe.

    Step 3: Better support (optional)

    At this point the Magic Pad is usuable-ish, although I did find that tracpadmagic.com's drivers help considerably.

    Screen shot of Trackpad magic's drivers in Windows

    TrackPad Magic's drivers may cost $9.40 but are well worth it to give trackpad users basic control.

subscribe via RSS