Dabbling with pixel art for a game concept.

No problem. I quickly fixed it by pulling in the data using regular old Javascript instead and pushed it live so our autofill users could get on with their lives.

"snake_case".replace /((^|_)[a-z])/g, (match) -> match.toUpperCase().replace("_","") # output is SnakeCase

When we first introduced [Taurus](https://taurus.io) to [Hacker News](http://news.ycombinator.com), we were elated by the amount of attention and praise it received. Which is why we were surprised to see our first batch of about 100 beta users mostly flop out and do absolutely nothing. There aren't very many steps you have to take after creating an account on our site. In fact, we kept our dashboard lightweight on purpose. After logging in, the user was greeted with a barebones account-settings page where you could change your password or update billing information. And, of course, a link to the installation guide. But people were signing up, only to bounce immediately on our account-settings page. We didn't even see very many people click through to even try and figure out how to install the thing. After a couple emails asking how much it cost to get set up ($0, which was noted), and some time in my [mind palace](http://www.youtube.com/watch?v=yKFMV0S5L44#t=22), I realized we were seeing the effects of a paywall, but without actually having a paywall. In an effort to keep our account-settings page simple, we had been inadvertently telling our users, "thanks for signing up, now let's see some plastic." The mere presence of billing information was apparently enough to jump ship, regardless of captions and callouts indicating that payment wasn't necessary. To remedy this, the first thing we did was install a worthless dashboard (which still exists and is only slightly less worthless). It consists of a bar graph that measures how many tooltips have been created and a link to our installation guide. More importantly however, it's the first thing you see after creating an account. The account-settings page (thus billing information) was hidden away in another tab for until it was necessary. Later that week, we released another batch of invites and, like magic, watched usage rise.

I apologize for the title, but I really couldn't think of a better name for this post. I'm also making a fairly big gamble that I will never discover another CSS trick again worth writing about. Anyway, I just wanted to share a tag I just had the pleasure of meeting. But before I introduce you, please take note of the following examples.  # What's going on here? While example A is simply expected behavior, example B might throw some new designers for a loop. As we all eventually come to realize, an HTML element's width is exclusive of it's padding, border, and margin. By setting an element to 100% and a padding of 5px (example B), you actually set the element to take up 5 pixels + 100% + 5 pixels worth of space. **The goal here is to create a padded element that fits snugly into its parent** (example C). You *could* set the padding to use a small percentage and just appropriately deduct that from the width, but that lacks consistency at extreme resolutions and feels like "hacky" responsive design. # Okay, okay, so how do I do it? Set the element's [box-sizing](https://developer.mozilla.org/en-US/docs/CSS/box-sizing) to "border-box". This CSS tag forces the browser render the width inclusive of the padding *and* border. The final CSS for example C ends up being as follows: width: 100%; padding: 5px; box-sizing: border-box; -moz-box-sizing: border-box; -webkit-box-sizing: border-box; Neat. :)

We just launched customizable colors for [Taurus](https://taurus.io). Our users can now change the way their tooltips appear to their visitors. One of the challenges we faced in testing was having too many attributes to define. If you're going to have a customizable product, let your users go crazy, but for the love of God, let's keep the interface sane. We had assembled an uncomfortably long list of colors that *should be* customizable. Note that "should be" is not the same as "user wants," several of these options existed to avoid a situation where dark text might show up on a dark background. A button alone could potentially have the following attributes: * Background color * Text color * Hover background color * Hover text color Yucky. So while we wanted to allow the user to go all Burger King on the tooltips, we didn't want to discourage them with some monstrosity of a control panel. We needed to find a way to consolidate these options. We figured that several of these could be defined programmatically. For example, if a user defines a dark background for a button, the text color should not be dark. This was nothing a few if-statements couldn't solve, but how do we determine whether a color is light or dark? It turns out that simply averaging the color's RGB values isn't enough, in fact, there is a specific formula to determine a color's [luminance](http://en.wikipedia.org/wiki/Luminance_(relative)). Blues are actually perceived by humans to be darker than reds or greens. So if a color is heavy in blue, it actually ends up looking much darker. If a user defines a **dark red** for a **button** in Taurus, we now automatically define the following attributes using the luminance calculation: * Set the text and hover-state text to white. * If the **tooltip** background is dark, the **button**'s hover-state background will be pink, and vice versa. This drastically reduces the number of things a user has to think about, behaves as expected, and will appropriately go unnoticed for the most part (except for the few people who will have read this). [Check out the Taurus demo in action here.](https://taurus.io)

"It's great." -- completely worthless.