The one killer feature icon fonts have over svg
OR: why github icons look like shit now

The reason I write about this now is githubs icons started to look like shit on my screen/system since a week or so. I asked myself why and looked at the source to find out they switched from using an icon font to inline svgs. There is quite some controversy about whether to use an icon font or svgs for icons. Just google for it to find some articles about that topic.

What neither of those articles mentions is the one killer feature that icon fonts have over svg. Actually its two features, but they are a bit related. It is this: hinting and subpixel anti-aliasing.

In english, hinting means that the font rendering will snap straight lines to device pixels, to make sure that fonts always look crisp. And subpixel AA means that the font rendering can boost the horizontal resolution by 3 due to the fact how lcd hardware actually works.

Both of these features are unique to fonts, they do not apply to svg. Hinting can actually distort the proportions somewhat to make sure straight lines snap to pixels, you clearly do not want that for svg. And although subpixel AA may be possible for svg, I have never seen that been done so far.

There is quite some hoops you have to just through to make svg, and especially <canvas> look good and crisp. If you want a line that is 1px wide to look good, you have to place it at a 0.5px coordinate, so when you add the width, it ends up at [0, 1] and therefore looks crisp. You do not want to do that for a 2px line though, because you end up with [-0.5, 1.5] which looks like shit again. It’s hard. Believe me, I’ve been through that already.

The point im trying to make here though is that in order to make svgs look good, you actually have to give up on one key selling point of svgs: scalability! You have to author svgs, specifically for one size to make sure that lines snap to device pixels. Fonts will just do the work for you.


All that I have written about here applies to my personal system, which has a device pixel density of 1. For low dpi screens, hinting matters a lot. The problems I described here are much less of a problem on high resolution screens.

The second thing to note is that content authors do not control font rendering all the way. Sure, there are css properties like font-rendering and friends, but for example the hinting behavior can not be controlled by the author, but is a system wide setting. On my system, I have hinting turned up quite high because I prefer light crisp fonts rather than thick blurry ones. One of the hits you find on google for that topic mentions that icon fonts look blurry compared to svgs. They might, depending on your font rendering settings. On the other hand though, svgs look blurry if lines do not line up with physical pixels, pun intended.

Fact is that font rendering settings also very much depend on your personal taste. Some people for example have font smoothing / anti-aliasing disabled altogether, most likely because they don’t know such settings exist. If I have to use someone elses system, turning on font AA is the first thing I do, because it really hurts my eyes.

I have a also recently seen a developer post a screenshot without font AA that also hurt my eyes really bad. Come on, it’s 2016 for fucks sake! There is absolutely no reason to not activate this single most important feature of a modern desktop!

Doing the impossible:
Choosing a Material Design Framework

The story starts like this: I am about to start developing a native-looking mobile App. And I would like to use Material Design for it. Since its awesome and I want a native look and feel.

And just as a precursor: Similar to Paul Lewis, I am also known to hate everything that looks and smells like a framework. Even though Material Design is just about styling, most of the Material Design Frameworks do come with some baggage in the form of JS and Framework lock-in. I am also extremely opinionated when it comes to JS Frameworks and Conventions. I kind of feel like I am chasing for perfection instead of getting shit done. But well that’s just how I roll :-(

So I was mainly looking at Materialize and Material-UI and the paper elements of Polymer. And then just during my research google released Material Design Lite. I also looked at some other smaller contestants, but those four came out top.

Before I start dissecting the choices, lets just say that every one of those is missing some things that I kind of need. It is kind of disappointing really. So many contestants, but all are lacking in some ways. :-(

So lets start.


Seeing how materialize was a bunch of jquery plugins, I quickly removed it from the list of options. jQuery was nice ten years ago, but I think we can do without it by now.

I actually did try the other three, Material-UI, MDL and Polymer.


While I do like the concept and the composability of a react-like library, react itself is a bit too big for my taste. Putting material-ui into the mix, a simple page with just an AppBar comes to 1M of code. As opposed to all others, I actually talk unminified ungzipped code here. LOC would be a better measure but I don’t have exact numbers, except that it is HUGE.

It also has some kind of boilerplate:

import React from "react"
import injectTapEventPlugin from "react-tap-event-plugin"
import {Styles, AppBar, IconButton} from "material-ui"


const ThemeManager = new Styles.ThemeManager()

class App extends React.Component {
getChildContext() {
return {
muiTheme: ThemeManager.getCurrentTheme(),

render() {
return <AppBar
iconElementLeft={<IconButton iconClassName="material-icons">arrow_back</IconButton>}

App.childContextTypes = {
muiTheme: React.PropTypes.object,

React.render(<App />, document.body)

As far as I understand, this means that you can change the theme dynamically, which would be awesome. But the boilerplate is a bit annoying nonetheless.

On the plus side, Material-UI has some nice special elements like date and time pickers. It seems to be quite complete.

What I don’t like about React is that you can’t have arrays of elements, except for children. But you can only have one children array per element. So Material-UI passes some children as props, which just feels wrong to me. I know that a lot of React libraries use this pattern, but it still feels wrong to me.


I started out with the full polymer starter. Maybe that was a problem, since its also HUGE. It was downloading 300M of npm packages, plus a lot of things from bower. It just generated hundreds of files and I have no idea for what purpose. I simply couldn’t understand all that code. And that’s not even library code. It’s supposed to be your own app code.

Also, I’m not really a friend of html imports. I would rather have ES6 modules and wire up as much through JS as possible, maybe even CSS. But having everything as HTML modules with code inside script tags just feels kind of backwards to me. Maybe I should start with an empty project so I wont be overwhelmed from the start.

I am also kind of ambivalent when it comes to web components in general. Sure, it is supposed to be implemented natively in the Browser. But you still have to pay high costs for it. The browser will have to (recursively) resolve the imports and load the things. HTTP2 Push will help a lot, but still. Also there is a lot of JS involved at app start. While it does not matter for the project at hand, I think think web components, depending on the way you use them might not be that great for SEO, serving static html and load times. But I might be mistaken completely. For now the whole machinery with html imports and the tools that are used to vulcanize them seem to be a little overkill for me.

I actually haven’t looked into how big the resulting code is, but I would probably have to use it in conjunction with a React-like library anyway so that would grow the size considerably as well.

Material Design Lite

MDL was actually released right the moment when I was starting my research. Being mainly about CSS, with just little JS involved (sadly you can’t quite do without), and directly from google, it felt like it might be the best contestant. But it is also quite new and incomplete. It has no list components as of yet. And the Appbar kind of has a menu button hardcoded, I’m not sure how to replace that menu button by a back button.

Also something that really annoys me is that it is not yet easily embeddable in a typical app based on CJS or ES6 modules. The JS code relies on being globally imported, which I don’t particularly like. Hopefully this will be fixed, but until then its just annoying.

The JS Code comes to roughly 110K unminified and it is not too bad to read. The CSS also amounts to roughly the same size.

Again, I would use it in conjunction with a React-like library so that would add some weight. All in all, it feels to be the simplest base if I happen to do a lot of custom things. And since it has no lists yet, I would have to do at least those myself.


I am still not happy with the choices I have to be honest. And I still feel like I’m standing in my own way. Since I want to use something that I actually like to use, as in feeling like I’m doing the right thing as opposed to getting things done but feeling like its all a big hack.

So I’m basically standing still for now. Maybe I will give a clean Polymer project another chance, maybe I will go with MDL and just implement certain things myself. Most likely I would have to implement quite some things myself anyways.

New Blog

I have decided to start over. This time instead of rolling my own static site generator or blogging system, I decided to try hexo with a slight modification of its default theme.

And from now on I think I will blog more about technical things rather than personal or philosophical ones. And also to do so in english.

So enjoy!