Honestly, there are plenty of solutions to this. You could:
* Push more often;
* Backup your hard drive at least once every 12 nanoseconds;
* Put your laptop in a [hermetically sealed plastic bag][laptop ziploc].

While ~~all~~ most of those are valid solutions, I've got something slightly different. Instead of trying to protect your computer, why not stop relying on it all together? That's right, my digital nomads. This *one amazing trick* will allow you to eliminate your reliance on a single device, opening up the possibilities for you the next time your computer *literally catches on fire*.

:::figure
![My real computer catching on fire.][my computer on fire]
::figcaption[My very real computer catching on very real fire.]
:::

## Enter `code-server`
[`code-server`][code-server] is a magical piece of software from [Coder][Coder]. It allows us to run [VS Code][VS Code] on a cloud server, meaning that we no longer have to worry about maintaining our physical machine! Let's take a look at some of the massive benefits of using `code-server`.

### 1. It runs in the browser!
Because `code-server` runs in the browser, you can use it from *any device with a modern browser.*

**Chromebook?** No problem.

**iPad?** Doneskis.

**Raspberry Pi?** You know it.

**Palm Pilot?** Yea- uh, well… I did say *modern* browser. 😬

The added benefit here is that even if your device has limited resources — low RAM, tiny CPU, no *NIX environment — you'll still be able to work on your projects!

### 2. It has all of your favorite extensions!
Not only can you use VS Code in the browser, but you can also still use most of your favorite extensions! As a JavaScript developer, this is one of the most important parts for me.

NOTE: The `code-server` marketplace is more limited than the marketplace for VS Code because of Microsoft's Terms of Service, but if there's a missing extension, you can always request to have it added!

### 3. The built-in terminal works!
The `code-server` terminal works just like you'd expect! If you need to run your app, install new packages, or `cat` your SSH key, the built-in terminal has you covered. It works exactly like the terminal in a local installation of VS Code, and from it you can perform any task that your user is allowed to do!

## Conclusion
I've been using [`code-server`][code-server] for a little over a week now, and it's just a joy to use. My laptop finally has enough storage space to install that update I've been clicking away for months *and* my personal development pipeline is faster than ever! While those plastic laptop baggies might be a pretty solid back up plan, the best solution is to just get your code off of your laptop!





[my computer on fire]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2F92456147-f514-4ec3-8b63-6aec6ab7032b%2Fmy-computer-on-fire.gif?alt=media&token=69cc0d49-0c4c-4c10-870c-87ff9017b2ba "Enjoy this real clip of my real computer catching on real fire. 🔥"
[code-server]: https://github.com/cdr/code-server "code-server repository on Github"
[Coder]: https://coder.com "Coder website"
[laptop ziploc]:  https://www.ohgizmo.com/laptop-ziplocs-let-you-surf-the-web-in-the-shower/ "Laptop Ziplocs Let You Surf The Web In The Shower"
[VS Code]: https://code.visualstudio.com/ "VS Code website"

What would you do if your computer caught on fire?

I posted a gif of some new game dev work, and the amazing [@TimBeaudet][Tim Beaudet's Website] asked me a few questions about what I'm working on.

:::figure
![Screenshot of the MOAR game, specifically the quick stats UI which displays the character's name, current health and mana, and avatar.](https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2F15263bd8-049b-495f-bd2c-f182101f329b%2Fcharacter-preview.gif?alt=media&token=f5667cd4-9d2f-40b6-bd7c-8b637a6fd93d)
::figcaption[Screenshot of the MOAR game, specifically the quick stats UI which displays the character's name, current health and mana, and avatar.]
:::

## Is it a big idea?
Holy crap yes and simultaneously not even a little bit. 🤣

*The story goes something like this...* Early last year, I woke up from a weird dream at 4am and had the code in my head to build an inventory management system in JavaScript. I snuck down to the office and wrote it all out. I was pretty happy with my creation, so I figured... why not build the rest of a game? And so began my first *real* foray into game dev.

## What was learned from Attempt #1?
My first idea was to build a simple game, then expand from there. I was heavily inspired by CrossCode and Moonlighter, so I intended to dig in with a game that combined some elements of both of those. I reached out to an artist friend of mine to see if he was interested. We started working together on some worldbuilding, some art, and developing the main story arc of the game. The idea was to build this region that was cut off from the rest of its continent. If the game turned out well, we could build the rest of the world on top of the engine and the world (heh) would be our oyster.

There were two roadblocks that prevented me from moving forward on that attempt. The first was that I wanted to go in a pixel art direction, and my artist buddy wasn't into it. He produced a couple gorgeous pieces of concept art for me, but when he tried converting it to art we could use (I had decided I wasn't married to pixel art, he could kind of do whatever) he lost motivation.

The second roadblock was game physics. I had built my own game engine, and I ran into a thousand issues when I tried to reconcile the renderer with the physics engine. That killed my motivation and I shelved the project for a few months.

## What was learned from Attempt #2?
Several months later, I dug into my second attempt because I was itching to get back to doing some game dev. I had decided I wanted to fiddle with an MMO and net code (because why would I **decrease** the scope? I mean c'mon...). I grabbed some free art from OpenGameArt.org (artist CalciumTrice, who I absolutely adore) and threw stuff together. The net code was surprisingly easy. I knocked all of that out, but then I ran into new physics engine issues (HOW ON EARTH DOES A RIGID BOX SQUEEZE THROUGH AN IMPERCEPTIBLY SMALL HOLE‽). After smashing my head against that issue for a couple of months, rewriting both the renderer and the physics code multiple times, my motivation was shot.

## Attempt #3?
Alright, here’s the setup:

> You’re on a farm. Somebody has asked you to go collect some logs and bring them back to the farm. Go do that.

The story isn’t exactly robust, and that’s okay. The plan is to finally get a tiny functional prototype done and get the gameplay to just *feel good*. From there I can turn the game into whatever I want. I’d like to revisit the larger stories I wrote for the previous two attempts and merge them into something that can drive development for this latest attempt, but *everything* is up-in-the-air atm.

## Takeaways:
* Don't allow people to engage in things if they seem hesitant. They don't want to do it!
* Physics are hard.
* Scoping down is *holy bananacows important.* Large scopes make it really difficult to focus on the basics.





[Tim Beaudet's Website]: https://timbeaudet.com/

Making a Video Game in Zero Easy Steps!

[Ana Tudor][Ana Tudor Twitter] asked this morning about using the Chrome DevTools for testing CSS performance:

::tweet{id=1237009588664352771}

Chrome's performance tools have come a loooong way in terms of measuring performance on all sorts of scales, so I figured I'd take this opportunity to dig in and better educate myself on how to use them. What follows is the result of my endeavor to figure out what these graphs and charts mean. 😬

## TL;DR

Honestly, I'm not sure the Performance tab has that much to offer in terms of debugging CSS. It may be able to help define the *when*, but from my cursory dive I don't see it helping me identify the *why*. If others have more insight, I'd love to have somebody prove me wrong. 🥰

## Okay, what are we looking at?

This is a screenshot of the Chrome DevTools on the [about][about] page. This page has a decently meaty animation when it loads up, so I figured it'd be a good place to test this stuff out.

:::figure
![][devtools performance screenshot]
:::

## The Timeline
The first thing I did was try to understand what each section of the Performance tab is for. I started with the timeline at the top of the pane.

:::figure
![][devtools performance timeline screenshot]
:::

The timeline looks *super* interesting. At first glance, it seems like it's able to enlighten me with all sorts of valuable data. At second glance, I realize I find it *completely unintelligible. After clicking at random and hovering around a bit, I think I was able to glean some details on how to use it to track performance.

First off, you can grab the handles at either end of the timeline and drag them in to minimize the amount of data that's currently under analysis. This alters what you see in the rest of the tab, too.

Second, Chrome seems to have recorded what the site looks like as it renders. Hovering over any point on the timeline will show you a thumbnail of the site at that precise moment. This feature is what we in the industry often refer to as *hella cool*.

:::figure
![][devtools performance timeline gif]
:::

I've now minimized the data under analysis by using the thumbnails and pulling the handlebars to the beginning and end of the animation I'm wanting to analyze. 😎

### The... Other Timeline?

Okay, so below the complete timeline is another timeline with much more in-depth information. Again, this looks *super* useful, but I'm not entirely sure what to make of it. One thing I will say is *do not scroll while hovering this timeline*. It turns out that scrolling adjusts the selection in the full timeline up top. FML.

Okay, I'm going to try to reduce scope so I only have to understand a part of this, rather than the whole thing. First thing, I'm going to disregard the `Network`, `Timings`, `Chrome_ChildIOThread`, and `ThreadPoolForegroundWorker`. I'm sure they're all useful, but they don't seem immediately related to what I'm interested in.

Clicking the arrow to open the `Main` section is... holy cow it's noisy. When I hover over it I see a lot of things like `Schedule Style Recalculation` and `Recalculating Styles` (I really want it to say `Reticulating Splines` in here somewhere...), so I'm sure this something I'm going to dig into, but I'm going to put it off until last. The other pieces look *way* less noisy.

Opening the `Raster` section, I feel like I'm getting somewhere. I see two things underneath it — `Rasterizer Thread 1` and `Rasterizer Thread 2`. With all this talk of threads, I suspect this whole graph is about the browser's processor utilization. Most of these categories are probably related to the CPU, though there's a separate section specifically for the GPU that I'm excited to get to. Anywho, the `Raster` section. By definition, rasterization means:

> "to convert into pixels for screen output; convert into a raster image"
> *via [The Free Dictionary][rasterize definition]*

So this is very probably referring to the browser taking already generated images and preparing them, pixel-by-pixel, for rendering.

Next, I'm going to skip down to the `Compositor` section. There's only a single timeline underneath it. Compositing generally refers to taking two or more things and combining them to make a single thing. I'm guessing this is the browser taking the different pieces chunks of DOM, positioning them appropriately, then sending them as a single hunk to the `Rasterizer` to turn it into an image that can be rendered.

The `GPU` section is actually kind of disappointing. Similar to the `Compositor`, it's a bunch of blips on the timeline with no description. I was hoping it would give me some detail on what operations it was passing off the GPU, but nah. 😞

## The Overview
Finally, we have the donut chart at the bottom labeled "Summary".

:::figure
![][devtools performance summary screenshot]
:::

Looks like this is a breakdown of how long each of the performance heuristics that we're tracking took *in total*. Let's break down the legend here:

1. **Scripting** - It seems safe to assume that this is tracking the page's execution of JavaScript.
1. **Rendering** - I'm guessing this is a combination of both DOM rendering *and* CSS rendering.
1. **Painting** - I'd wager that this is related to CSS repaints, but honestly I'm not sure what the difference between rendering and painting is. We'll have to look this up next.
1. **System** - Probably OS-level things like garbage collection.
1. **Idle** - Time that the browser isn't doing anything or is waiting for something else to finish.

## Conclusion

So, I think all of the pieces of the timeline could be really valuable, but you still have to do a lot of work by hand. If you're working on some clunky CSS animations, the timelines could be super helpful to identify *when* your animation is getting wonky, though it doesn't seem to have any insight into *why* it would be happening. The overview seems really valuable for getting a quick look at the resources your app is using within a certain window, but I'm not sure that I'm going to be using it anytime soon.

One other resource that may be useful when you're digging into CS performance is the [CSS Triggers][csstriggers.com] website. It details which types of CSS rendering operations (`Layout`, `Paint`, `Composite`) will be triggered when changing each CSS property. You could use this — in conjunction with the `Performance` tab and looking at the styles on your elements — to try and narrow down what exactly is causing your animations to be clunky.





[about]: /about
[Ana Tudor Twitter]: https://twitter.com/anatudor "Ana Tudor on Twitter"
[csstriggers.com]: https://csstriggers.com/ "CSS Triggers"
[devtools performance screenshot]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2F6187f874-96cf-4d2f-b18f-f5525fc157b0%2Fcss-debugging-1.png?alt=media "Screenshot of the Chrome DevTools' Performance tab on https://trezy.com/about"
[devtools performance timeline screenshot]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2F6187f874-96cf-4d2f-b18f-f5525fc157b0%2Fcss-debugging-3.png?alt=media&token=3525e3ec-a631-4a0f-b263-69470a7d859f "Close up of the Chrome DevTools' Performance Timeline"
[devtools performance timeline gif]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2F6187f874-96cf-4d2f-b18f-f5525fc157b0%2Fcss-debugging-4.gif?alt=media
[devtools performance summary screenshot]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2F6187f874-96cf-4d2f-b18f-f5525fc157b0%2Fcss-debugging-2.png?alt=media "Close up of the Chrome DevTools' Performance Summary"
[rasterize definition]: https://www.thefreedictionary.com/rasterize "Rasterize definition in The Free Dictionary"

Performance Testing CSS with the Chrome DevTools

In this series, we're going to use [Firebase][firebase], [React][react], and [Next.js][nextjs] to build a photo-sharing web app. We'll start from nothing and build a complete user management system with logins, profiles, permissions, and file uploads!

When starting a new project, I don't always follow the same process, but I *always* start with [*Data Modeling*][data-modeling]. When building apps, all you're doing is creating new ways to display and manipulate your data. That means that no matter what, your data will always be the most crucial part of your app!

Let's dive in!

---

## What are we *really* building?

If our data is the most crucial part of our app, then *what is our data?* The first step of data modeling is to figure out what data needs to be modeled. To do that, let's think at a high level about what the app should be able to do.

* *Logging In* - Users need to be able to login to upload their photos
* *File Uploads* - It's not much of a photo-sharing app if nobody can upload photos to share
* *User Profiles* - I want to know more about the person that uploaded that cute cat picture
* *Moderation* - One of the dangers of a photo-sharing site is that people start uploading dangerous or illegal content, so I want to have a team of moderators that can manage that content

There are *plenty* of other features we could add to this site, but I want to start small, and this is a great start! Now that we know what we want to be possible, let's think about what we'll data we'll need to support those features.

* *Logins* - We'll use Firebase Auth to allow users to login
* *User Profiles* - We'll Firebase Firestore to store data about our users
* *Permissions & Roles* - We'll store roles in Firestore that a user can have, permitting them to do different things
* *File Uploads* - Firebase Storage is a great solution for file uploads, and keeping things in the Firebase family makes everything a lot simpler

## The shape of ~~water~~ data

Before we start writing any code or setting up the database, we need to know how we want our data to look. We have a high-level overview of what our data looks like, but now we need to get into details. We need to think about what bits of info are going to be relevant to our system and how we can represent them in the database. Since almost everything is going to based around the `User`, let's think about that first.

### The `User` model

Firebase Auth dramatically simplifies the process of building a login system. With Firebase Auth, you can allow users to log in with either their email and a password or with their social media accounts. However, we're *only* going to support social media login to reduce the scope of this project.

A `User` is going to comprise two chunks of data. First, there's the data that we get from Firebase Auth. When a user logs in via Firebase Auth, Firebase assigns them a unique user ID. There's some other useful data we can retrieve depending on what platform they sign in with, but for now, we'll just assume that the user has decided not to share any information with us from their social profile.

The second chunk of data we'll be retrieving is the user's `Profile`, which will be coming from Firestore. This will include some critical pieces of information, including:

- `username` - This will be what other users see when they look at the user's posts
- `email` - So we can stay in touch with the user
- `createdAt` - To keep track of when users were created
- `roleIDs` - An array of roles that the user has been granted so we can determine whether or not they have permission to perform specific actions

With all of this information, we can start modeling our data! Thus far, it looks something like this:
::::figure
:::ditaa
```
+-------------+    +-----------+
| {s}         |    | {s}       |
| Firebase    |    | Firebase  |
| Firestore   |    | Auth      |
+------+------+    +-----+-----+
       :                 :
       +                 |
       |                 |
       V                 V
+------+------+      +---+---+
| Profile     |      | User  |
+-------------+      +-------+
| id          |  /-->+ id    |
| username    |  |   +-------+
| email       |  |
| roleIDs     |  |
| userID      +--/
| createdAt   |
+-------------+
```
:::
::figcaption[A diagram of our data model with the `User` coming from Firebase Auth and the `Profile` coming from Firestore]
::::

#### A note on naming
Naming things is hard, and database field names are no exception. I try to follow the following rules when naming fields:

##### Boolean fields should start with `is`

A field to describe whether or not a user has been verified would be named `isVerified`. This is much more clear than a field named `verified`, which may be a `Boolean` field, or it may be a string that represents *how* the user was verified, like `by-email` or `by-street-address`.

##### Lists should be plural

A field with a list of sports a user is interested in should be named `sports` rather than `sport`.

##### Reference fields should end with `ID`

Reference fields (known as "foreign key" fields in SQL databases) always contain IDs that reference another item in the database. In our model about, our `Profile` has a `userID` field that will be populated by the `id` field of the `User` model. Naming the field `user` is confusing because it's not clear whether it will contain an ID or an object representing some other user data.

### The `Photo` model

Since we're talking about a photo-sharing site, our users should be able to upload some photos! Like `User`s, `Photo`s will also comprise two chunks of data. The first chunk will be from Firestore. This will be our record of all data about the `Photo`, including:

* `fileID` - When a file is uploaded, we'll generate an ID for it. We'll then use that ID as the filename for storing the file.
* `fileType` - `Photo`s have various file types — `gif`, `jpg`, `png`, etc. — and each of them can have slight variations on the way they're displayed or the way their metadata is stored. Storing that information will help us out later.
* `title` - When a user uploads a file, we'll allow them to add a title.
* `description` - When a user uploads a file, we'll let them add a description.
* `originalFilename` - To make `Photo`s easier for users to find, we'll store the filenames that they had when they were uploaded.
* `ownerID` - This will be the ID of the user that uploaded the file.

The next bit of information will come from Firebase Storage. This is where we'll store the actual file that the user has uploaded. With our new `Photo` data modeled out, our data model looks a bit more like this:

::::figure
:::ditaa
```
+------------+                          +-------------+    +-----------+
| {s}        |                          | {s}         |    | {s}       |
| Firebase   |                          | Firebase    |    | Firebase  |
| Storage    |                          | Firestore   |    | Auth      |
+----+-------+                          +------+------+    +-----+-----+
     :                                         :                 :
     |                      /------------------+                 |
     |                      |                  |                 |
     V                      V                  V                 V
+----+------+     +---------+---------+   +------+------+    +---+---+
| Photo     |     | Photo             |   | Profile     |    | User  |
+-----------+     +-------------------+   +-------------+    +-------+
| id    {d} |<--\ | id                |   | id          | /->+ id    |
| fileType  |<-\\-+ fileID            |   | username    | |  +-------+
+-----------+  \--+ fileType          |   | email       | |
                  | title             |   | roleIDs     | |
                  | description       |   | userID      +-+
                  | originalFilename  |   | createdAt   | |
                  | ownerID           +-\ +-------------+ |
                  +-------------------+ \-----------------/
```
:::
::figcaption[A diagram of our data model with the `User` coming from Firebase Auth, the `Profile` and `Photo` models coming from Firestore, and the `Photo` file coming from Firebase Storage]
::::

### The `Role` model

`Role`s are much simpler than most of our other models. There are only two pieces of information that a `Role` will care about:

* `title` - Each role should have a recognizable name, like `Administrator` or `Moderator`.
* `permissions` - These permissions will be fleshed out as we build our app, but each permission will be a string that represents some action. For example, `photo:delete` would indicate that any user with this role can delete a photo.

With `Role`s added, we've come to our final data model.

::::figure
:::ditaa
```
+------------+                            +-------------+                       +-----------+
| {s}        |                            | {s}         |                       | {s}       |
| Firebase   |                            | Firebase    |                       | Firebase  |
| Storage    |                            | Firestore   |                       | Auth      |
+----+-------+                            +------+------+                       +-----+-----+
     :                                           :                                    :
     |                      /--------------------+-------------------\                |
     |                      |                    |                   |                |
     V                      V                    V                   V                V
+----+------+     +---------+---------+   +------+------+    +-------+-------+    +---+---+
| Photo     |     | Photo             |   | Profile     |    | Role          |    | User  |
+-----------+     +-------------------+   +-------------+    +---------------+    +-------+
| id    {d} |<--\ | id                |   | id          | /->| id            | /->+ id    |
| fileType  |<-\\-+ fileID            |   | username    | |  | title         | |  +-------+
+-----------+  \--+ fileType          |   | email       | |  | permissions   | |
                  | title             |   | roleIDs     +-/  +---------------+ |
                  | description       |   | userID      +----------------------+
                  | originalFilename  |   | createdAt   |                      |
                  | ownerID           +-\ +-------------+                      |
                  +-------------------+ \--------------------------------------/
```
:::
::figcaption[A diagram of our data model with the `User` coming from Firebase Auth, the `Profile` and `Photo` models coming from Firestore, and the `Photo` file coming from Firebase Storage]
::::

## Data modeling

Modeling your data should be the first step in building any application. Knowing what data you need to collect, to display, and how it's all related can prevent you from having to make massive structural changes halfway through the development of your application.

In the next article, I'll walk through setting up the application with React and Next.js!





[data-modeling]: https://en.wikipedia.org/wiki/Data_modeling "Wikipedia: Data Modeling"
[firebase]: https://firebase.google.com/ "Firebase"
[nextjs]: https://nextjs.com/ "Next.js"
[react]: https://reactjs.org/ "React.js"

Part I: Data Modeling

Building Web Apps with Firebase

Web workers are magical. They allow for multi-threading in JavaScript, a language that has been single-threaded *since the beginning*. Their practical applications range from heavy number crunching to managing the retrieval and dissemination of asynchronous data, to loading images (as I'll discuss in this article).

I'm actually preparing for an upcoming talk about web workers, and according to a good friend of mine...

> Of course Trezy's talk is about web workers. If he wasn't already married to Meg, the man would marry a web worker.
> — @xlexious

I mean, I suppose I like them a bit. WHAT OF IT‽

## Why would we want to load images with web workers?

Moving image loading off of the UI thread and into a worker is a really great opportunity for image-heavy sites and one of my favorite web worker implementations. It prevents image downloads from blocking rendering and it can speed up your site significantly.

*Fun fact:* `<img>` tags actually block your application load. If you have 100 images on your page, the browser will download all 100 of them before it renders your page.

Let's talk a little bit about implementing web workers in a couple of different environments.

### The standard, vanilla implementation

To start a web worker in your average JavaScript app, you need to have it in its own file. Let's assume that we're working on my website, [https://trezy.com][trezy.com]. We'll name our worker file `image-loader.worker.js` and it'll be available at `https://trezy.com/workers/image-loader.worker.js`.

We'll start with a very simple web worker that will log out whatever data it receives:

```js
/*
 * image-loader.worker.js
 */

// The `message` event is fired in a web worker any time `worker.postMessage(<data>)` is called.
// `event.data` represents the data being passed into a worker via `worker.postMessage(<data>)`.
self.addEventListener('message', event => {
  console.log('Worker received:', event.data)
})
```

To start using it in our main JavaScript file, we'll do something like this:

```js
/*
 * main.js
 */

const ImageLoaderWorker = new Worker('/workers/image-loader.worker.js')

ImageLoaderWorker.postMessage('Hello world!')
```

If we load all of this up, we should see `Hello world!` in the console.
🎉 Woot! 🥳

## Let's Get Into It

### Step 1: Update your markup

With your worker implementation all figured out, we can now start implementing our image loader. I'll start with the HTML that we're going to plan on working from:

```html
<body>
  <img data-src="/images/image1.png">
  <img data-src="/images/image2.png">
  <img data-src="/images/image3.png">
  <img data-src="/images/image4.png">
  <img data-src="/images/image5.png">
</body>
```

> Uuuuuuuh, hang on. That's not what `<img>` tags look like!
> — You, just now.

Very astute observation, you! Normally you would use the `src` property of an `<img>` element to tell it where to download the image file from, but here we're using `data-src`. This is because when the browser encounters an `<img>` element with an `src` attribute, it will immediately start downloading the image. Since we want that job to be offloaded to our web worker, we're using `data-src` to prevent the browser from handling the download on the UI thread.

### Step 2: Pass the image URLs to our web worker

In our `main.js` file, we'll need to retrieve all of the relevant `<img>` elements so we can pass their URLs to our web worker:

```js
/*
 * main.js
 */

// Load up the web worker
const ImageLoaderWorker = new Worker('/workers/image-loader.worker.js')

// Get all of the `<img>` elements that have a `data-src` property
const imgElements = document.querySelectorAll('img[data-src]')

// Loop over the image elements and pass their URLs to the web worker
imgElements.forEach(imageElement => {
  const imageURL = imageElement.getAttribute('data-src')
  ImageLoaderWorker.postMessage(imageURL)
})
```

### Step 3: Download the images

Excellent! Now that our web worker has received a bunch of image URLs, let's figure out how to process them. This gets a bit complex in web workers for a couple of reasons:

1. **You don't have access to the DOM API.** A lot of non-web worker image downloader implementations create a new image element and set the `src` attribute on it, initiating the download, then replace the original `<img>` with the new one. This won't work for us because there's no way to create DOM elements inside of a web worker.

1. **Images don't have a native JavasScript format.** Images are made up of binary data, so we need to convert that data into something that we can use in JavaScript.

1. ~~**You can only communicate with the UI thread using strings.**~~ I've been corrected. This was the case in the days of yore, but no longer! 😁

So how can we get the image downloaded, converted from binary format to something JavaScript can use, and then passed back to the UI thread? This is where `fetch` and the `FileReader` API come in.

#### `fetch` is for more than just JSON

You're probably used to seeing `fetch` used to grab data from some API, then calling `response.json()` to get the JSON body of the response as an object. However, `.json()` isn't the only option here. There's also `.text()`, `.formData()`, `.arrayBuffer()`, and the one that matters to us for this exercise, `.blob()`.

A [`Blob`][blob] can be used to represent virtually anything, including data that doesn't have a native JavaScript format like images! They're perfect for what we're trying to do here. With that in mind, let's update our web worker to receive the image URLs and download them as `Blob`s:

```js
/*
 * image-loader.worker.js
 */

// I'm making the event handler `async` to make my life easier. If
// you're not compiling your code, you may want to use the Promise-based
// API of `fetch`
self.addEventListener('message', async event => {
  // Grab the imageURL from the event - we'll use this both to download
  // the image and to identify which image elements to update back in the
  // UI thread
  const imageURL = event.data

  // First, we'll fetch the image file
  const response = await fetch(imageURL)

  // Once the file has been fetched, we'll convert it to a `Blob`
  const fileBlob = await response.blob()
})
```

Alright, we're making progress! We've updated our images so they don't download automatically, we've grabbed their URLs and passed them to the worker, and we've downloaded the images to the browser!

### Step 4: Return the image data to the UI thread

Now that we've got the image as a blob, we need to send it back to the UI thread to be rendered. If we send the string back alone then the UI thread won't know where to render it. Instead, we'll send back an object that tells the UI thread what to render *and* where:

```js
/*
 * image-loader.worker.js
 */

self.addEventListener('message', async event => {
  const imageURL = event.data

  const response = await fetch(imageURL)
  const blob = await response.blob()

  // Send the image data to the UI thread!
  self.postMessage({
    imageURL: imageURL,
    blob: blob,
  })
})
```

Our worker file is done! The final step is to handle what we've received in the UI thread.

### Step 5: Render that image!

We're **so** close to being finished! The last thing we need to do is update our main.js file to receive and handle the image data that's returned from the web worker.

```js
/*
 * main.js
 */

const ImageLoaderWorker = new Worker('/workers/image-loader.worker.js')
const imgElements = document.querySelectorAll('img[data-src]')

// Once again, it's possible that messages could be returned before the
// listener is attached, so we need to attach the listener before we pass
// image URLs to the web worker
ImageLoaderWorker.addEventListener('message', event => {
  // Grab the message data from the event
  const imageData = event.data

  // Get the original element for this image
  const imageElement = document.querySelectorAll(`img[data-src='${imageData.imageURL}']`)

  // We can use the `Blob` as an image source! We just need to convert it
  // to an object URL first
  const objectURL = URL.createObjectURL(imageData.blob)
  imageElement.setAttribute('src', objectURL)

  // Let's remove the original `data-src` attribute to make sure we don't
  // accidentally pass this image to the worker again in the future
  imageElement.removeAttribute('data-src')
})

imgElements.forEach(imageElement => {
  const imageURL = imageElement.getAttribute('data-src')
  ImageLoaderWorker.postMessage(imageURL)
})
```

Check out the [Codepen demo][codepen-demo] with everything working together:

::codepen{id=ZNdbeQ height=500px}

## BONUS: Implementing web workers with Webpack

If you're using Webpack to compile all of your code, there's another nifty option to load up your web workers: [`worker-loader`][worker-loader]. This loader allows you to import your web worker into a file and initialize it as if it were a regular class.

I think it feels a little more natural this way, too. Without changing the content of `image-loader.worker.js`, this is what an implementation would look like if you have `worker-loader` set up in your Webpack config:

```js
/*
 * main.js
 */

import ImageLoaderWorker from './workers/image-loader.worker.js'

const imageLoader = new ImageLoaderWorker

imageLoader.postMessage('Hello world!')
```

Just as in our vanilla implementation, we should see `Hello world!` logged out in the console.


## Conclusion

And we're done! Offloading image downloading to web workers is a great exercise in using several different browser APIs, but more importantly, it's an awesome way to speed up your website rendering.

Make sure to drop off your questions and suggestions in the comments below. Tell me your favorite web worker uses, and most importantly, let me know if I missed something awesome in my examples.





[blob]: https://developer.mozilla.org/en-US/docs/Web/API/Blob
[codepen-demo]: https://s.trezy.sh/image-worker-main
[trezy.com]: https://trezy.com
[worker-loader]: https://github.com/webpack-contrib/worker-loader

Loading Images with Web Workers

Have you ever spent far too long writing a clever little script in the browser’s devtools to get some information from a page? Maybe you’re trying to generate a list of recurring characters from the Marvel Cinematic Universe (MCU) with their names and secret identities from a Wikipedia page...

![That wasn’t too bad...][clipboard-script-1]

Or maybe you’re trying to get a JSON representation of all of the MCU movies sorted by total profit...

![Okay, that one took a little longer...][clipboard-script-2]

Or maybe you’re a **true masochist**, and you want to extract the Game of Thrones (GoT) character and actor names from the body of the GoT wiki page.

![SERIOUSLY, WHY WOULDN’T YOU PUT THIS DATA IN A TABLE‽][clipboard-script-3]

---

## Anyway.

The norm here is to log the data into the console as JSON, then manually select all of the text with your cursor. Not only is this a nightmarish task with large datasets, it also has the potential to have incomplete data. Long strings (especially data URIs) get collapsed with an ellipse (...) by the dev tools. If you want to copy even small data URIs, this approach will leave you — and I’m putting this delicately — *completely boned.*

## Okay, how do we do it better?

With the `copy()` function! It just so happens the the devtools for Chrome, Firefox, and Safari (couldn’t test with Edge) all provide the `copy()` function for jamming anything you need into the clipboard!

✨🧙🏻‍♂️ IT’S MAGIC! 🧙🏻‍♂️✨

If you want to jam an object full of data into your clipboard, it’s as simple as stringifying the data and using `copy()`:

```js
const bigDataSet = [ ... ]
const bigDataSetAsJSON = JSON.stringify(bigDataSet)

copy(bigDataSet)
```

Now if you paste anywhere, you’ll find that your clipboard is chock full of JSON beautifulness.

*Protip:* If you want your data to be styled (with spaces, line breaks, etc) the `JSON.stringify()` method has you covered. For example, if you want the output to use 2 spaces as indentation:

```js
JSON.stringify(bigDataSet, null, 2)
```

For more information on what all you can pass into `JSON.stringify()`, check out the [docs on MDN][json-stringify-docs].

---

## Wow, Trezy! You sure are smart and amazing!

Oh, I know. I appreciate you saying as much, though. If you want to fiddle with any of the code in the examples at the beginning of the article, you can find them [here][pastebin-1], [here][pastebin-2], and [here][pastebin-3].





[clipboard-script-1]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2Fe79faa9c-70cf-43db-a8ac-b8b99ece10bc%2Fclipboardscript1.png?alt=media&token=217b874a-2c3e-4f82-b298-e623f90619c1
[clipboard-script-2]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2Fe79faa9c-70cf-43db-a8ac-b8b99ece10bc%2Fclipboardscript2.png?alt=media&token=ae5a40d0-15d9-4adf-9f66-d464b4b49aae
[clipboard-script-3]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2Fe79faa9c-70cf-43db-a8ac-b8b99ece10bc%2Fclipboardscript3.png?alt=media&token=59d05274-df14-44d8-812c-09efad707b19
[json-stringify-docs]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify "JSON.stringify() on MDN"
[pastebin-1]: https://hastebin.com/okihububep.js
[pastebin-2]: https://hastebin.com/eyuqosuwik.js
[pastebin-3]: https://hastebin.com/jarivurozu.js

From the Devtools to the Clipboard

`ngOptions` is awful. It’s hard write and even harder to decypher. If you’re looking at an `ngOptions` expression that *somebody else wrote?* God help you. Luckily, creating `select` elements in Angular can be so, so much easier. Try this out:

```js
var selectedState, availableStates;
 
selectedState = ‘’;
availableStates = [
  {
     name: ‘Alabama’,
     code: ‘AL’
  },

  // ...

  {
    name: ‘Wisconsin’,
    code: ‘WI’
  }
];
```

```html

<select ng-model=”selectedState”>
  
  <option value=””>Select a state</option>
 
  
  <option
    value=”{{ state.code }}”
    ng-selected=”state.code === selectedState”
    ng-repeat=”state in availableStates”>
    {{ state.name }}
  </option>
</select>
```

It makes sense — as far as Angular goes — right?

* `option\[value]` is what will be set in the model if the option is selected.
* `option\[ng-selected]` sets this option as selected if selectedState is set to a state code.
* `option\[ng-repeat]` loops through the states to create an option element for each one.

Now let’s look at ng-options:

```html
<select
  ng-model=”selectedState”
  ng-options=”state.name as state.code for state in availableStates”>
  
  <option value=””>Select a state</option>
</select>
```

(╯°□°)╯︵ ʎʇıןıqɐuıɐʇuıɐɯ

I’ll admit, it’s way shorter but even if I wrote them I can’t figure out what these things mean when I go back to look at them. Okay, let’s break it down anyway. For academic purposes, right?

* … as … basically says, “Use state.name as a facade for state.code.” That’s kinda cool, as it lets you use an object or an array or a goat or whatever the hell you want for the value and sets the facade as the displayed value. What’s not cool is that you’ll have to debug what the value actually is if things aren’t working the way you’d expect because the value in the markup will be nothing but a single digit. FUUUUUUUUUUUUUU
* … in … is your standard looping construct. It’s the same thing as ngRepeat.
* thing¹ for thing² may look familiar if you Coffeescript. Here it’s probably the most confusing part for me, though it’s not nearly as bad now that I’m breaking this down. It’s just saying do thing¹ for each thing².

I struggled for a long time trying to figure out how ngOptions worked. Then I struggled for a long time trying to figure out how to do it without ngOptions because it’s impossible to read. Do yourself a favor and follow Occam’s Razor.

## On Performance

A coworker pointed out that using ngOptions is superior to ngRepeat because of it’s performance benefits. ngOptions creates a single scope which encapsulates all of your options. ngRepeat creates a new scope for each option element. That’s true. Creating a new scope for each state — resulting in 50 new scopes — is definitely a performance hit. But if you’re using Angular, you obviously don’t care about performance anyway. So. There’s that.





[canonical]: https://codepen.io/trezy/post/stop-using-ngoptions

Stop Using ngOptions

## …or Why the Hamburger Icon is Awesome.

I've read plenty of anti-hamburger icon posts that came out after Mike Stern's rant at WWDC '14. The issue I take with those articles — and Mike's rant, for that matter — is that they aren't addressing the icon. They're addressing the menu.

## Hamburger Icon vs. Hamburger Menu

The hamburger icon - three vertically stacked horizontal bars - is most often the iconography selected for a button that opens an action menu. The terms used to refer to that menu are vast in number and so I'll not attempt to list them all but I can at least give you the most common: drawer, sidebar, or - least commonly - a hamburger menu. The hamburger icon typically does what you would expect based on it's design. The hamburger menu, however, can be virtually anything from a list of pages on a website to a multi-tiered tree of navigation allowing you to traverse your overly complicated email labeling system.

The issue is that the icon is the one that's getting a bad rep as if it did something wrong when that could be no further from the truth. The icon does exactly what you would expect it to - open a visual representation of itself. Typically, however, the menu is the one causing all the ruckus. WTF, mang?

W.
T.
**F.**

## Menu vs. Nav

To explain why the menu is causing so much fuss I feel like I need to clear up a terrible ambiguity.

### Menus

Menus are, in their most basic form, intended to facilitate action. When you right-click on a selection and you see `cut`, `copy`, and `paste`? That's a menu. `Save` and `delete` buttons? Those should be in a menu. HTML5 even added a `<menu>` tag with some super sweet features built into it. Check out this pen for an example of my typical usage of the element.

### Navs

Navs are (I would hope obviously) intended for navigation. If I click a button or link in a `<nav>` element then I should be taken to an entirely new page. It should be like a wondrous adventure to a new, far off land where unicorns roam free and everybody is eating s'mores and pooping rainbows. The most actionable thing you should do when I click on a link is prompt me about unsaved changes.

## Why Does Any Of This Matter?

The main argument that Mike and the rest of the anti-hamburger movement makes is that it's bad UX when the menu pops out and covers up the rest of your perfect, delicately designed interface. That's totally legit. If I have to cover up whatever I'm doing to cut the paragraph I just selected? You better believe I'm gonna find a better text editor.

However, if this is the navigation I'll be using to take myself to Magic Unicornland™ then I already have intentions of leaving the page. Eff that stupid interface of yours, I just want to get where I'm going.

## The Point

I've been hemming and hawing but for why? It's because the hamburger icon? That guy is my bro. I always turn to him when I don't have enough unicorns in my life. Menus? They're my bros, too, they just aren't used correctly as often as they should be.





[canonical]: https://codepen.io/trezy/post/menu-vs-nav-or-why-the-hamburger-icon-is-awesome

HTML Elements: Menu vs. Nav

## Browser caching is one of the best ways to take care of your users while also speeding up your website... so why is it so hard?

**This article was originally published on 19 October, 2014 at [Medium][canonical].**

Browser caching is a magical thing. Every time you visit a website, the files that make up that site are downloaded to your computer by your browser, which then uses those files to render it for you. This takes time and valuable bandwidth, especially on slower connections. The next time you visit that same site, however, the files needed to render it are already downloaded to your computer. Your browser will use the files it already has to render the site, preventing you from having to waste your bandwidth and wait for the files to download.

Now, this is what happens in a wonderful, magical fairy tale land where all web developers do the right thing and make sure the browser caching is set up on their site. Unfortunately, this is rarely the case. In the spirit of making up statistics, I estimate that somewhere between 30–90% of websites don’t just leverage browser caching, they’re actively working against it.
😞

See, there are a couple of ways to implement browser caching. You can use what’s called a `cache-control` header, which tells the browser how long it can hold on to the file. If you look at my own website, you can see that the Google Analytics script I’m downloading from Google has this header set.

![The cache-control header has a max-age of 7200 seconds, or 2 hours.](https://thepracticaldev.s3.amazonaws.com/i/2zx6rh0vi0aepov91lej.png)

Two hours isn’t bad. If I revisit my site sometime within the next two hours, my browser will still use the version of that file that I just downloaded. The cool part is that since it’s being served by Google instead of by my server, that file will be cached for every website that uses it, including mine!

However, if Google updates that file within the next 2 hours, I won’t get those changes.
😞😞

This is also a great example of where a lot of websites use a technique called **cache busting.** Cache busting is where you fool the browser into thinking something like this Google Analytics script is a different file than it previously downloaded, guaranteeing the user **always** gets the latest version of the file. Developers achieve this by adding something like `?timestamp=2017-10-19T13:04:29.423Z` to the end of the filename. It’s just a parameter that uses the current date and time, so the browser always thinks that this file is different and, thus, always downloads a new version. Now, every time I go to that site I’ll have to download a new copy of that file.
😞😞😞

## So... is there a better way?

Remember when I said there are a **couple** of ways to implement browser caching? Let’s talk about that second one, which is called ETags. ETags are something that the server generates and sends along when a browser tries to retrieve a file for the first time. Here’s an example of a fresh request for one of the files served from my website.

![Notice there is no expires header. The cache-control header has a max-age of 0, which somewhat unintuitively means feel free to keep this file forever.](https://thepracticaldev.s3.amazonaws.com/i/nxvcfv7pmijen7yx9mvw.png)

This is my logo, which has an `etag` header set. This header contains a calculated hash of the file that I’m downloading. The server created that hash for me and sent it up with the file. Now let’s take a look at the second time I request that file.

![The ETags match!](https://thepracticaldev.s3.amazonaws.com/i/g3xrc58yax7wnw7c6cs2.png)

Since the browser received an `etag` header when it first downloaded this file, it made sure to send that ETag back to the server in the `if-none-match` header. The server will compare that ETag against what it calculates for its version of the file. If they *don’t* match, the server will send a new copy of the file to the browser.

However, if they *do* match it won’t send back a file at all. Instead it will send back a `304 Not Modified` response, telling the browser nothing has changed. The Trezy.com server has just saved me time and bandwidth. Just how much has it actually saved me, though?

On a fresh visit to [Trezy.com][trezy.com], the website downloads *781KB of files* and takes around *1.34 seconds to finish*. That’s just for my very tiny website. For other websites that you visit regularly, you can imagine that those numbers will be much larger.

On a second, cache-friendly visit to my website, though, it only downloads *46.1KB of files* and takes *1.05 seconds to finish*. That’s a *94% savings* in bandwidth, and *22% savings* in response times. Again, this is just on my very, very tiny website. Imagine what those savings could look like on a larger website like Facebook or Twitter!
🤔

---

## Let’s take a look at some implementation

We’ll look at the very simple implementation of ETags I used for my website, which runs on a [Koa.js][koa] server. Below is the core of what `koa-etag` does. It takes care of making sure that your server’s response have ETags calculated and attached to the responses.

```js
function etag(options) {
  return function etag(ctx, next) {
    return next()
      // `getResponseEntity` checks to see if the response has a body, and
      // stringifies it depending on what kind of body it has (JSON, HTML, 
      // image, etc)
      .then(() => getResponseEntity(ctx))
    
      // `setEtag` calculates the ETag from the response body if it exists,
      // then sets that ETag as a header
      .then(entity => setEtag(ctx, entity, options));
  };
}
```

This isn’t all we need to do, though. The response from the server will still contain the contents of the rest and it will respond with a `200 OK`, telling the browser that it’s basically getting a new file. Here’s the missing piece of the puzzle.

```js
function conditional() {
  return function conditional(ctx, next) {
    return next().then(() => {
      if (ctx.fresh) {
        ctx.status = 304;
        ctx.body = null;
      }
    });
  }
}
```

Alright, what’s going on here? `ctx.fresh` is a Koa.js-specific property, but it’s basically checking if the old and new ETags match. This middleware, `koa-conditonal-get`, uses this property to determine how to proceed. If they do match, the information the browser has is `fresh` and we don’t need to send anything new along, so we’ll set the status to that nifty little `304 Not Modified` and delete the response body, eliminating the need to send who knows how much gobbledy-gook across the wire. If the ETags don’t meet up to Will Smith’s standards, we’ll need to send along the new content.

---

## Make it real!

If you work on one of the 30–90% of websites that don’t implement browser caching, there’s no better time than now to fix it! This is a stupid simple implementation of ETags that may not cut the mustard for a lot of systems, but it’s a great start. It’s not just for websites, either! APIs can leverage ETags to make developer’s lives easier, too. If you have arguments about scalability, I’ll just go ahead and point out to you, Mr. or Mrs. Smarty Pants, that Github implements ETags in their API, so there.
😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁





[canonical]: https://medium.com/trezy-com/why-is-browser-caching-so-hard-7bd711603c91
[koa]: https://koajs.com
[trezy.com]: https://trezy.com

Why Is Browser Caching So Hard?

[Handlebars][handlebars] is **awesome**. I can separate my template logic from my application logic? Yes, please. When I try to use Handlebars in my local editor, though, it vomits all over those ugly `<script>` tags. Fortunately there’s an awesome, future-friendly, spec-compliant solution — the `<template>` tag.

`<template>` tags are super cool in a lot of ways. From the [HTML5 Rocks article][article-html5-rocks-template], here are the pillars of `<template>` tags:

1. Its content is effectively inert until activated. Essentially, your markup is hidden DOM and does not render.
1. Any content within a template won’t have side effects. Script doesn’t run, images don’t load, audio doesn’t play… until the template is used.
1. Content is considered not to be in the document. Using `document.getElementById()` or `querySelector()` in the main page won’t return child nodes of a template.
1. Templates can be placed anywhere inside of `<head>`, `<body>`, or `<frameset>` and can contain any type of content which is allowed in those elements. Note that “anywhere” means that `<template>` can safely be used in places that the HTML parser disallows…all but content model children. It can also be placed as a child of `<table>` or `<select>`:

```html
<table>
  <tr>
    <template id=”cells-to-repeat”>
       <td></td>
    </template>
  </tr>
</table>
```

## Why isn’t this being used elsewhere?

That’s a great question. I can only speculate but I’d reckon it has something to do with the recency / lack of support. `<template>` is supported in most browsers, though [Can I Use][caniuse-template] tells us that we’re lacking support in Internet Explorer (big surprise), Safari 7, and Blackberry. Luckily, we can add [this shim][shim-template] if we need to make it work everywhere. You can read more about the `<template>` tag and how to use it in [this tutorial on HTML5 Rocks][article-html5-rocks-template].

Here’s the coolest thing, though — current Handlebars users will actually have to write **less** code. Check it:

```html

<script type=”text/x-handlebars-template” id=”article-template”>
  <article>
    <h1>{{title}}</h1>
    {{content}}
  </article>
</script>
```

…just swap the `<script>` tags for `<template>` tags:

```html

<template id=”articleTemplate”>
  <article>
    <h1>{{title}}</h1>
    {{content}}
  </article>
</template>
```

And blammo, you’re using awesome new HTML5 tech. Your editor and I will love you for it. 😉

## The catch

As [joao][profile-joao] points out in the [Codepen comments](https://codepen.io/trezy/post/on-handlebars-and-template-tags#post-comments), not everything is hunky dory. Take a look at this code:

```html
<template id=”tableTemplate”>
  <table>
    {{#each}}
      <tr>
        <td>{{content}}</td>
      </tr>
    {{/each}}
  </table>
</template>
```

Looks legit, right? Unfortunately it breaks in the browser. The parser still requires the code inside the `<template>` tag to be valid HTML which means you can’t have any content in a table unless it’s also inside a cell (`<td>`). You can, however, create your table cells / rows in a template tag and use them in a table:

```html
<table></table>

<template id=”tableTemplate”>
  {{#each}}
    <tr>
      <td>{{content}}</td>
    </tr>
  {{/each}}
</template>
```

It’s not ideal and I would definitely prefer a better DOM API for it. Still, this stuff is super cool and I’ll be using it all over the place. If you take advantage of it, let me know! I’ll leave you with my implementation of `<template>` tags and Handlebars:

::codepen{id=yxqCJ height=500}





[article-html5-rocks-template]: http://www.html5rocks.com/en/tutorials/webcomponents/template/
[caniuse-template]: http://caniuse.com/#search=template
[canonical]: https://codepen.io/trezy/post/on-handlebars-and-template-tags
[handlebars]: http://handlebarsjs.com/
[profile-joao]: http://codepen.io/joao/
[shim-template]: http://jsfiddle.net/brianblakely/h3EmY/

On Handlebars and Template Tags

This morning I read [7 Reasons Why You Will Never Do Anything Amazing With Your Life](https://medium.com/raymmars-reads/7-reasons-why-you-will-never-do-anything-amazing-with-your-life-2a1841f1335d) by Raymmar Tirado. It’s a painfully accurate article about the way that today’s youth consume the world through the lens of Buzzfeed and UpWorthy, usually driven by their friends comments of, *"OMG, SO true!"*

I love the article. I love its message. I love the way that Tirado summarizes the issues with the products of our education system and emphasizes the benefits of living the way that he and I do: consuming quality, thought-provoking, intellectual content; parsing news to get to the truth of a matter; defining your own measure of success; bettering yourself everyday by taking to heart the best advice you find; pushing yourself towards your personal renaissance. I *love* it.

## So what’s the issue?

The extremely adversarial tone of the article trivializes the existence of college students, likely turning the target audience away from the message. Tirado even acknowledges that fact in his anger:

> Because you are probably not reading this article even though you know you should.

Had I not the stubbornness of a man trying to move a hippopotamus with his bare hands I likely would have stopped reading when Tirado started calling me names and trivializing the past that isn’t even mine. I do, however, possess the aforementioned gall so I soldiered through. The article continues to berate those who aren’t making an effort to improve themselves everyday as well as those who spend any amount of time consuming mindless, pointless information.

Again, I love the article. I love that Tirado has justified my life choices. I love that his article basically says, *"Trezy, you’re doing it right."* However, this is the kind of masturbation that people are indulging in everytime they read, *"10 Things You Didn’t Know About Disney Movies."* They’re getting an opportunity to justify that they’re intelligent in some way by saying, *"I totally knew about all of those except for #9."* Indulging that justification for a different audience — in this case, self-made people like Tirado and myself — is no different than what the producers of trash content are doing. Tirado even admits that he’s doing this deliberately:

> Because the people that are reading this already know these things.

## Alright asshole, what’s your point?

I’m not trying to belittle Tirado’s article in any way. I’ll say it [at least] one more time — I *love* the article. It contains a message that I wish every college graduate would hear. I wish it was a freaking commencement speech.

In its current tone, however, it will never reach that audience. It will be read over and over and over by people like Tirado and myself and praised because, *"OMG, SO true!"* The audience that it needs to reach will rarely finish it and, if they do, they’re unlikely to affect themselves by it.

## Oh. Well… shit.

Yeah, I know. This isn’t something that can’t be dealt with, though. While reading the article I noticed it lacking any call to action. Nowhere was it written, *"This is a way to become better informed,"* nor was it entitled, *"7 Ways To Do Something Amazing With Your Life."* Without a path to enlightenment the people that would benefit from it are left with nothing more than a bad taste in their mouths. They’ll likely go off to play some Xbox while they *"think about it."*

Without a call to action, nobody will benefit from a piece as inspirational as Tirado’s. Those that already follow the path will take pleasure in their indulgence and those that don’t will be left wondering how they can be better.

## So what’s your call to action?

Write with a call to action in mind, duh. Well... I guess there’s more to it than that.

It needs to be apparent and focused. I’d be wrong to claim that Tirado’s article doesn’t have a call to action at all because it does and is easily summarized — be better. It’s not focused, however. An uninformed reader would likely take away from the article that Tirado is just an angry, crotchety old grinch that regularly yells at the youngsters to, *"GET OFF MY LAWN."*

## Disseminating the points

Breaking down Tirado’s paths to enlightenment isn’t too hard, though:

1. **Because You Have Not Failed Enough**
  Walk into a high school classroom or college lecture hall. Ask a simple question: *"How do you think our president is doing and why?"* You’ll likely see exactly nobody jump up to answer. We are so afraid of failure that we usually don’t even try. If you don’t try then you’ll never fail and you’ll *never* succeed. You’re likely to fail a lot and that’s not a bad thing. Learn from your failures and the failures of others and eventually success won’t be so far away.
2. **Because You Care What Others Think About You**
  I usually try to do the right thing regardless of what others think. If I didn’t, I’d never do anything at all. I hold a great many unpopular opinions and I have lost friends to them before but I will continue to hold them because I believe in them. Caring about what others think is putting yourself on the fast track to being useless to the world because without strong opinions, you will **never do anything amazing**. Never compromise the things you care about, *especially* for somebody else.
3. **Because You Think You Are Smarter Than You Are**
  Don’t expect that you know anything just because you have a degree. There are billions of people in the world. Most of them know more than you. Learn from them, then learn some more. When you think you’re done, keep learning.
4. **Because You Don’t Read**
  Good places to find quality content depend on what kind of content you’re looking for but no matter the topic, they do exist. King amongst the general reading is *Medium*. *Google News* is another great way to keep up with the world. Everybody should have information sources that they read regularly. If you never read then you’ll rarely learn.
5. **Because You Lack Curiosity**
  Devouring what you read and hear as fact will always leave you wanting. Until you know a truth for yourself, nothing should be considered true. Always dive deeper, get a second opinion, find another source, and get to the truth of it. Not everything has to have a conspiracy theory but then again… not all conspiracy theories are wrong. Curiosity may have killed the cat but it sure as hell hasn’t killed Edward Snowden yet.
6. **Because You Don’t Ask Enough Questions**
  Let’s go back to the high school classroom. When the professor offers to answer questions you’re likely to hear… silence. Our culture is still raising us to become a part of the industrial complex where you don’t stand up, you don’t ask questions, and you *always* do as you’re told. The world of today requires so much more than that. If you’re not asking questions and you’re always doing what you’re told then you remain just another cog in the machine. Unless you start to ask questions you’ll never find yourself coming closer to the truth.
7. **Because You Can’t Handle The Truth**
  Many people find comfort in hiding behind a wall of ignorance and I get that. Those people, though, are the ones contributing to every problem we face as a society: ignorance about science prevents scientific advancement; ignorance about technology prevents technological advancement; ignorance about the world prevents the elimination of racism and anti-global views. You don’t have to be an expert on any of these things and, in fact, shouldn’t claim to be. Keep an open mind. The world becomes so much more interesting when you do.

## Write for the right audience

I hope it’s clear by now that I *love* Tirado’s article. I just don’t love that he wrote it for me. If you’re not trying to make a difference in this world then you’re doing it wrong. *That’s the point.* The list I made isn’t as clear of a path as I’d like it to be… but I think it’s a good start.

How to do Amazing Things

The CSS transition property allows for a lot of really cool effects in your design, but it's caused me to bang my head against the desk more than a couple of times. 

*Disclaimer:* At the time of this writing transitions still require browser prefixes to work for Firefox (`-moz-`), Opera (`-o-`), and Webkit (`-webkit-`). I have omitted them from the code examples here for readability, but they will be required if you intend to use these techniques.

## The long and the short of it

The transition can be broken into several different properties or used in its shorthand form. You can even mix and match depending on what you prefer. The different transition properties that exist are:

* [`transition`](https://developer.mozilla.org/en-US/docs/CSS/transition)
* [`transition-property`](https://developer.mozilla.org/en-US/docs/CSS/transition-property)
* [`transition-duration`](https://developer.mozilla.org/en-US/docs/CSS/transition-duration)
* [`transition-timing-function`](https://developer.mozilla.org/en-US/docs/CSS/transition-timing-function)
* [`transition-delay`](https://developer.mozilla.org/en-US/docs/CSS/transition-delay)

Each of the longhand properties also have their own shorthand form:

```css
div {
 background-color: #2f2;
 color: #090;
 transition-property: background-color, color;
 transition-duration: 1s, .5s;
 transition-timing-function: ease, steps(4,start);
 transition-delay: 0s, .5s;
}

div:hover {
 background-color: #fff;
 color: #000;
}
```

Keep in mind that you don't have to have multiple values for each property. If we were to change `transition-duration: 1s, .5s;` to `transition-duration: 1s;` then both transitions would use the same duration value. Personally, I prefer the shorthand property because it looks cleaner and it takes less code:

```css
transition: 
  <transition-property>
  <transition-duration>
  <transition-timing-function>
  <transition-delay>;
```

The `timing-function` and `delay` are both optional in the shorthand version. Here's an example:

```css
div {
 background-color: #2f2;
 color: #090;
 transition-property:
   background-color 1s,
   color .5s;
}

div:hover {
 background-color: #fff;
 color: #000;
}
```

Both of these blocks of code will create the same functionality so it's entirely a matter of preference. A final thing of note for `transition-property` is that if you don't change anything between states other than the properties you want animated, you can use `all` in place of a list of properties.

## Transitions swing both ways

It wasn't until I read [this article](http://www.impressivewebs.com/mimic-onmouseout-css3-transitions/) from Louis Lazarus that I realized I could use different transitions for different states. If a transition is applied to just one state of an object like in the code examples above it will activate on `:hover` (or whatever state you choose) and reverse when the state changes back. However, if each state has a different transition property, it will be applied to the incoming transition. For example:

```css
div:not(.menu):before {
 background-color: #ddd;
 border-radius: 10px;
 color: #333;
 content: 'Hover me to see the menu';
 padding: 10px;
}

div .menu {
 background: #88b;
 max-height: 0;
 -webkit-transition:
   max-height .5s ease .5s,
   max-width .5s ease 0s;
 max-width: 10px;
 overflow: hidden;
}

div .menu a {
 color: #fff;
 text-decoration: none;
}

div:hover .menu {
 max-height: 999px;
 -webkit-transition:
   max-height .5s ease 0s,
   max-width .5s ease .5s;
 max-width: 999px;
}
```

::codepen{id=mvaLt height=500}

In this example when you mouse over the `.menu`'s parent div its first transition will come from the `div:hover .menu` rule. First, it will grow vertically, then it will grow horizontally. When you mouse off the parent div (or the menu) the `.menu` will take it's transition from the `div .menu` rule, first shrinking horizontally, then growing vertically. It's a little bit confusing but super cool!

## It's all in the timing

The `timing-function`s will be familiar to flash developers and video editors that customize the easing on their transitions, timing, and other effects, but they're likely a foreign concept to most web designers. These functions are already well-described on [MDN](https://developer.mozilla.org/en-US/docs/CSS/timing-function) and in the [W3C spec](http://dev.w3.org/csswg/css-transitions/#transition-timing-function) so I'll just give a brief description of each them here.

### `ease`

This is the default setting for `timing-function` so unless you're using the longhand `transition-timing-function` with multiple properties, declaring it is unnecessary. It will ease both the in and out points of the animation with a slightly sharper curve on the in than the out. Basically it's faster in the middle than at the beginning or the end, and the beginning accelerates a little faster than the end.

### `ease-in`

This is similar to `ease` but it has a longer in point curve (slower acceleration) and an abrupt stop.

### `ease-out`

The opposite of `ease-in`, this has a longer out point curve (slower… slowing?). Basically it starts abruptly and slows down as it gets closer to the end.

### `ease-in-out`

I thought the existence of this one was odd since we already have the basic `ease` function. However, there is a slight difference. `ease-in-out` actually has an equal in and out curve, whereas `ease` has a slightly sharper in curve. The actual animation will have an equally slow beginning and end.

### `linear`

This function has a straight line from beginning to end. This means it will have an unchanging speed with an abrupt start and stop.

### `step-start` / `step-end`

What the purpose of these two functions is, I have no idea. I am sure that they have their uses somewhere. With `step-start`, it will make the switch for the transition at the beginning of the duration, then does nothing until the end of the duration. The `step-end` function does the opposite, waiting for the end of the duration, then applying the changes suddenly. These are not smooth transitions at all but rather changes with delays built in.

### `steps(number_of_steps, direction)`

Much more useful than the previous step functions, `steps()` allows you to spread your animation across several abrupt changes for the duration of your transition. Here's an example:

```css
a {
 transition: steps(4, start) 1s;
 width: 100px;
}

a:hover {
 width: 200px;
}
```

When hovering over this link it would immediately grow incrementally from 100px to 200px instead of moving through a smooth transition. These are literally immediate transitions, similar to if there were no transition at all. The `direction` (in this case `start`) is the same as the suffixes for `step-start` and `step-end`, determining whether the changes begin at the beginning or end of each step. The default value for `direction` is `end` but the parameter is not optional so `steps(2)` will not work.

### `cubic-bezier(x1, y1, x2, y2)`

This is the mother of all `timing-function`s, giving you ultimate control over the timing of your transitions. All of the other functions except for `steps()` can be defined using `cubic-bezier()`. However, it can be extremely complicated, so I'll leave you to your own devices here. I highly recommend checking out the [MDN](https://developer.mozilla.org/en-US/docs/CSS/timing-function#The_cubic-bezier%28%29_class_of_timing-functions) article about it for a really brilliant explanation.

## Conclusion

Talk about dissemination of information, these dogs are cooked! And by dogs I mean fingers. Not that I have huge fingers or anything, just… are you calling me fat? Anywho, leave a comment if you have any questions or if you figure out some super awesome combination of transitions.

On Dropdown Menu Transitions

`box-shadow` is arguably one of the coolest things to come out of CSS3. However, I’ve been creating shadows in Adobe Fireworks and Photoshop for years, so I feel like CSS3’s `box-shadow` implementation is just too constrained. In an effort to expand my boxy horizons, I set out on a quest to create some cooler shadows.

*Disclaimer:* At the time of this writing filters and transforms still require browser prefixes to work, though filters will only work in Webkit browsers. I have omitted these prefixes from the code examples here for readability but they will be required if you intend to use these techniques.

## Rocking out with box-shadow

My first attempt at making my shadows more dynamic still uses `box-shadow` but it extends its use to create a new effect. My main goal was to avoid using any extra elements, so all we need is a div and we’ll leverage pseudo elements to do the rest of the work.

::codepen{id=Jrhpc}

What we’ve done is created two transparent pseudo elements behind our main element. These two pseudo elements then have `box-shadow` applied. This is done so that we can use 2D transforms to angle them, creating a 3D looking `box-shadow` for their parent element.

We also used the `top`, `bottom`, `left`, and `right` properties to keep the shadow from spilling out from the sides of the parent element.

## Box-shadow… without box-shadow?

I was pretty happy with the previous idea, but it didn’t look as awesome as I hoped. My next idea was to create the same effect using gradients.

::codepen{id=aybiL}

This time we’re still using our pseudo elements but instead of giving them `box-shadows`, we’ll give them gradients. We also used a new CSS3 property called `filter`. Make sure to check out all the nifty things it can do [here][demo-box-shadows]. We just use the blur to soften the edges and make it look more like a shadow.

## Oooooh… that’s way prettier.

While I was working on this project I ran across a site with an even cooler style of drop-shadow that pointed inward rather than outward:

[Karma][karma]

All I really had to do was flip my last idea and we were good to go!

::codepen{id=zEtgJ}

## Conclusion

If you use any of these drop shadows, post a link in the comments! Also, if you come up with any alternative ideas or issues that should be noted, let me know.





[canonical]: https://trezy.com
[demo-box-shadows]: https://html5-demos.appspot.com/static/css/filters/index.html
[karma]: http://demo.truethemes.net/Karma-Wordpress/

On Advanced Box Shadows

When I write my sans-serif font-family stack in my CSS file I normally use this:

```css
body {
 font-family: Ubuntu, Helvetica, Arial, sans-serif;
}
```

[Ubuntu][font-ubuntu] is one of my favorite fonts which I import from [Google Fonts][google-fonts] but you can replace it with whatever custom font you want. Since I prefer Helvetica over Arial, it's the next font on the list which I'm hoping they have preinstalled. If not the stack falls back to Arial, then the default `sans-serif` system font.

Now I've been writing my font stack this way for several years (sans the custom font) completely oblivious to the ridiculously obvious fact that half of the stack isn't necessary. The `sans-serif` piece of the stack asks for the system's preferred `sans-serif` font which, by default, is Arial on Windows and Helvetica on Mac. If I'm not concerned about the user having changed their default `sans-serif` font, I can cut 16 characters (not including spaces) out of my font stack:

```css
body {
 font-family: Ubuntu, sans-serif;
}
```

When I realized this a couple days ago, I subjected myself to an hour of staring at terrible websites as punishment for my ignorance. After recuperating from the debacle I decided to take a closer look at my new font stack. The only issue I have with it is that I don't trust my Windows users to not have changed their default system font to [Comic Sans][font-comic-sans] or [Papyrus][font-papyrus]. Fortunately, Windows will fallback to Arial if you declare Helvetica and it's not installed! When it's all said and done our font stack should like this:

```css
body {
 font-family: Ubuntu, Helvetica, sans-serif;
}
```

It's not a performance saver and it's not going to impress anybody - in fact you may look like an idiot if you admit to not having known this already - but it's a nice piece of info to have when writing your font stacks.





[canonical]: https://trezy.com
[google-fonts]: https://fonts.google.com
[font-comic-sans]: https://bancomicsans.com/main/
[font-papyrus]: https://trezy.com/blog/christmas-time-with-papyrus
[font-ubuntu]: https://fonts.google.com/specimen/Ubuntu

On Saving Characters

*Disclaimer:* Alright, don't get too excited. This stuff isn't backwards-compatible *at all*. However, there are fallback solutions and it's pretty darn cool that it's actually being spec'd.

Web designers were begging for variables and calculations in CSS well before LESS and Sass came along However, Sass and LESS output can sometimes bloat your CSS and, while it's pretty fun to play with, it's a pain to have to recompile your CSS after every change. Fortunately, the W3C has come in like the proverbial Mary Poppins and to give them a spit shine, making everything all fresh and new again.

## Variables

Mmmmmmmmm, variables. We've used them in almost every language but CSS… Until now. Admittedly, CSS variables are quite a long way off. They're still in a W3C Level 1 module so you won't be able to play with them for a while unless you want to get into the [Webkit nightly builds][webkit-nightly]. Still, it's fun to think about all of the amazing things we're going to be doing with them in a year…

Here's what variables might look like in CSS3. Keep in mind that since it's still Level 1, it's subject to change. To declare a variable, you'll create it inside an element. All of the examples are declaring them in the `:root{}` using the `var` prefix like this:

```css
:root {
 var-mainColor: #0c0;
}
```

You can then call the variables later on in the code by using the `var()` syntax:

```css
p {
 background-color: var(mainColor);
}
```

My main use for this in CSS has been dealing with branding colors. I can set all of the branding colors in the top of the stylesheet and use the variables throughout code, like this:

```css
:root {
 var-primaryColor: #0d56a6;
 var-secondaryColor: #4186d3;
 var-tertiaryColor: #689ad3;
}
header {
 background-color: var(primaryColor);
}
header > nav {
 background-color: var(secondaryColor);
}
article {
 background-color: var(tertiaryColor);
}
button {
 background-image:
   linear-gradient(
     bottom,
     var(primaryColor) 0,
     var(secondaryColor) 50%,
     var(tertiaryColor) 100%
   );
}
```

From this point on if I want to change the color scheme I can just change the colors in my `:root` element and they'll change across the entire website! I do hope, however, that before the spec is released we get the ability to create full property set variables that work like SASS mixins. The ability to do something like this would be stupendous:

```css
var gradient (color1, color2, color3) {
 background-image:
   linear-gradient(
     bottom,
     var(color1) 0,
     var(color2) 50%,
     var(color3) 100%
   );
}
article {
 gradient(#0d56a6, #4186d3, #689ad3);
 border: 1px solid #000;
}
```

[W3C Module][w3c-css-var]

## Calculations

Calculations are in a W3C Level 3 module, meaning they're pretty close to making it into the CSS3 full spec. If all goes well, we'll be able to consider them totally safe to use come next June. However, we can already play with them in the latest version of Chrome, Firefox, Opera, and Safari, as well as IE9/10.

So why are calculations so exciting? How about this horizontal centering:

```css
body {
 margin-left: calc(960px / -2);
 width: 960px;
}
```

[MDN Page][mdn-css-calc] | [W3C Module][mdn-css-calc]

## Units

There are some really snazzy new units coming with CSS3 but the ones I'm most excited about are `rem`, `vw`, `vh`, `vmin`, and `vmax`.

### rem

We're all aware of the `em` which we're encouraged to use for the sake of magnified page viewing. However, I've avoided them for quite sometime because they're a major pain in the ass to try to calculate. I don't like having to figure out what my em value is based on it's parent's calculated value which is based on it's parent's calculated value which is based on it's parent's calculated value which is… It just sucks. The `rem`, however, is here to save the day! The `rem` is similar to the `em` except that it's always relative to the `em` value of the root of the page. Take this code:

```css
:root {
 font-size: 20px;
}
.box1 {
 font-size: 2em;
}
.box1 > .box2 {
 font-size: 2em;
}
.box3 {
 font-size: 3rem;
}
.box3 > .box4 {
 font-size: 1rem;
}
```

In this case, `.box2` will have a font-size of 80px (2em of 20px = 40px, then 2em of 2em of 20px = 80px) but `.box4` will have a font-size of 20px (.box3 would be 3rem of 20px = 60px, `.box4` if 1rem of 20px = 20px). It's actually even more complicated than that, but this is the general way to figure everything up. `rem`s are much easier to use then `em`s, hands down.

### vw and vh

Even more awesome are the units that calculate based on the size of the viewport! `vw` and `vh` are percentages of the viewport width and height, respectively. Each `vw`/`vh` is 1% of the viewport size, so think about this:

```css
nav {
 width: 100vw;
}
nav a {
 min-width: 100px;
 width: 20vw;
}
```

With this you can create a navbar with 5 elements that is always the same size as the viewport! The `min-width` also makes sure that the links will never be too small so you can stack them or turn them into a vertical menu for super tiny screens.

### vmin and vmax

These guys are always relative to the larger or smaller size between the `vh` and `vw`. In other words, if the width of the viewport is smaller than the height (maybe its a smartphone in portrait mode) then the `vmin` will be relative to the width and the `vmax` will be relative to the height.

[W3C Module][w3c-css-vmin-vmax]





[less]: https://lesscss.org
[mdn-css-calc]: https://developer.mozilla.org/en-US/docs/CSS/calc
[sass]: https://sass-lang.org
[trezy.com]: https://trezy.com
[w3c-css-calc]: http://dev.w3.org/csswg/css3-values/#calc-notation
[w3c-css-var]: http://dev.w3.org/csswg/css-variables/
[w3c-css-vmin-vmax]: http://www.w3.org/TR/css3-values/
[webkit-nightly]: https://nightly.webkit.org

On Variables, Calculations, and New Units

Pure CSS tooltips have been a thing for a while now, but all of the solutions I've found have had severe limitations. After reading through Louis Lazaris's article — [Pure CSS Tool Tips Revisited][tooltips-article] over at [ImpressiveWebs][impressive-webs] — I decided to take a stab at making some powerful CSS tooltips of my own.

## The Problem

Louis's design broke some of the boundaries but still had some limitations. These were my goals:

### Multiline

Louis makes the argument that tooltips are only supposed to contain a small amount of information, eliminating the need for multiline tooltips. I agree with him to an extent, but I still think there are cases in which you would want a multiline tooltip. In my example, I am creating an error message rather than your average tooltip. I wanted my first line to be only the error type, then all of the following lines would contain the error message.

### IE8 Compatible

This was a big one since the company I'm doing this project for requires it. Fortunately we only have to support IE8, Firefox, and Webkit. Keep in mind, however, that this also means I don't know how this code will react in IE7 and below.

### No Extra HTML

Some other pure CSS tooltip solutions use extra elements, like placeholder spans or divs. I wanted to be able to pull in all of the information I needed without any extra elements. I bend the extra HTML rule a little bit since we do use an element's attributes to populate the tooltip but I think I can still live with myself.

## The Solution

If you check out the pen, you may notice the custom `data-` attributes on the link. The `data-tooltip` attribute is binary, meaning it's either set or it's not, just like `required`. I'll be using jQuery to create and populate the other two attributes in the final project but for now we'll just use some bunk data.

### Pseudo-classes and Uncommon Attributes

Most pseudo-classes describe some state of an element, i.e. `:hover` applies when the element is being hovered, `:focus` applies to form elements that are in focus, `:disabled` applies to elements that are disabled, etc. However, `:before` and `:after` are a little different. They are used to prepend and append, respectively, content to an element. For example you could use `.emailAddress:before` to append a label to the internal node of every element with a class of `emailAddress`.

You have probably seen most of this CSS before, though we're using a couple of pretty uncommon attributes. The `content` attribute only works with the `:before` and `:after` pseudo-classes. It determines what to prepend/append to the element. In this case we're using a pretty cool argument called `attr(x)`. It allows you to use the value from any attribute applied to the element as the content of the prepended/appended element. In our case we used the custom `data-` attributes we set earlier.

The `white-space` is another strange one. It's used to determine how white space (spaces and returns) should be handled inside of an element. We used `white-space:pre-wrap;` so that the spaces inside the `content` attribute would be preserved, specifically the `\A` which is a Unicode carriage return, pretty much the only way to ensure that the line breaks where we want.

### Positioning

This was the most important point to allowing multiline tooltips. Some previous solutions have used percentage positioning, some used pixel positioning, but they all used the `top` and `left` attributes. However these always break if you have more than one line so they are often used with `white-space:nowrap;`.

Instead of positioning negatively based on the top position of the element like Louis did, I set the top position of the tooltip to zero so it would line up with the top of the element, then gave the tooltip a `margin-top`. In my example, I'm placing the tooltip on a link so I set the bottom margin to 1em, ensuring the margin would always be the same height as my text. This may need to be adjusted depending on your line-height.

If you're not positioning the tooltip on a line of text then you can also set your margin to match the height of a static height element, or use some jQuery magic to adjust it.

::codepen{id=Khnzy}

## Wrapping It Up

The rest of this code is pretty standard stuff. One other peculiar thing we're doing here is using the `:before` to create the arrow on the bottom of the tooltip. [Louis's article][tooltips-article] explains that part a bit and there are plenty of other tutorials on creating shapes using divs and borders so I won't cover that.

I've tested this in all of the necessary browsers (IE8+, Firefox, and Google Chrome) and haven't seen any issues yet. If you run into an issue or have a recommendation for making it even better, let me know in the comments! I'll do another tutorial in the future about how to make this guy extensible using jQuery. 😉





[impressive-webs]: https://impressivewebs.com
[tooltips-article]: http://www.impressivewebs.com/pure-css-tool-tips/
[trezy.com]: https://trezy.com

On CSS Tooltips

After reading through A List Apart's article [What I Learned About the Web in 2011][ala-article] I decided I needed to make a second effort at getting into mobile web design. This article chronicles the epic struggle between myself and the perils of designing for a screen that fits in my hand.

Part 1 will discover the philosophy behind responsive design and how to apply these new bits of brain lightning to our current processes. My odyssey will continue in part 2 as I get into the technical side of using techniques like media queries to create a responsive design. Hit the jump to read on.

## What is Responsive Design?

Responsive design is the ideology of designing a single website for multiple screen sizes. Don't be scared traditionalists, it's not that hard. Actually according to most experts in the design field responsive design is making them more talented designers. The ideology is being necessitated by the increasing number of devices that are accessing our websites. It's no longer enough to design for desktops and laptops. We now have to take into consideration all of the tablet and mobile users and provide them with the same experience that we give to our desktop users.

## In the Beginning…

I decided to start my descent into the deep, dark depths of change by reading into the exploits of others that succeeded in defeating this great beast. From these musings I learned a few things that I'd like to share:

### The Mobile Minotaur Comes First

It was stated by every book, blog and video I ran across on the topic of responsive design: design for mobile first. It makes sense if you think about it. The issue with tackling a design for a mobile screen is size. By traditional design methods you have created some sort of grid format, 960px powerhouse but when it comes time to create the mobile version you are trying to squeeze all of that content into a teeny little box. If you design for mobile first you have the advantage of expanding your content rather than smashing it with the proverbial hammer.

### "The Fold" is an Ancient Beast, but a Worthy Foe

If you're unfamiliar with "The Fold," check out Paddy Donnelly's explanation of it [here][the-fold-article]. What makes "The Fold" insignificant in responsive design is that our first designs are going to be built for mobile users. Our content is going to expand well beyond the confines of their screens so we are going to have to become comfortable with the mobile version of the vertical tango.

### Truncating is for Elephants

Mobile users may be lacking in screen real estate but that doesn't mean they should have fewer options than they do from their home computers. If anything they should have access to more features from their mobile devices. They have the ability to get all touchy-feely with your website. They are more interactive than a desktop user because of that physical connection. We need to cater to these users by making them feel like their feeling the website.

Now I think I'll take a coffee break. Blogging is hard. Watch out for Part 2!

[ala-article]: https://medium.com/r/?url=http%3A%2F%2Fwww.alistapart.com%2Farticles%2Fwhat-i-learned-about-the-web-in-2011%2F
[the-fold-article]: https://medium.com/r/?url=http%3A%2F%2Fiampaddy.com%2Flifebelow600%2F
[trezy.com]: https://trezy.com