DEV Community: Trezy

Melody: A New Way to RegEx

Trezy — Wed, 06 Apr 2022 00:15:36 +0000

Today, yoav-lavi announced Melody, a language that compiles down to ECMAScript RegEx. Now, I write a lot of RegEx, so this project immediately piqued my interest.

Since the project was only released a couple days ago, it's lacking several important features. For example, you can't...

set flags (i for case insensitivity, u for unicode support, g for global search, etc)
negate ranges (e.g. /[^A]/)
create arbitrary multi-ranges (e.g. /[a-c1-3]/)
pass in variables (JavaScript, not RegEx)

All that said, the syntax is pretty slick. Here's a simple example from the docs for finding a hashtag in a string:

"#";
some of <word>;

Here's the RegEx that's output:

/#(?:\w)+/

The syntax is interesting, but I'd argue that if you didn't know RegEx then you'd find the Melody version to be infinitely more readable.

Interesting Syntax

Let's talk about some of the ways Melody makes RegEx more human readable and less like using blood to draw runes into the dirt for the purposes of enacting an arcane incantation.

Symbols

Symbols are Melody's way of simplifying a lot of common RegEx tasks. For example, if you want to capture any normal Latin character in any case, you might write [a-zA-Z]. With Melody, though, you can use the <alphabetic> symbol! There are ~16 symbols as of this writing, but here are some of my favorites so far:

<char> An alternative to the wildcard (.) character, which matches anything. <char> takes all the guess work out of figuring out if \\\. is a wildcard or a literal period character. 🙃
<word> RegEx escape codes are extremely useful, but it's not always clear what they're doing. The <word> symbol matches any word character. This is the same as the \w escape code in RegEx.
<alphanumeric> Matches any Latin character (A-Z) in any case (a-z), as well as numbers (0-9). This is the same as using [a-zA-Z0-9] in RegEx.

Special Symbols

As of this writing, there are two special symbols: <start> and <end>. These symbols correlate to the ^ and $ characters, respectively. They're used to indicate that the search must start at the beginning or the end of the string, or if the search should be all-inclusive (when using both symbols).

Quantifiers

Quantifiers allow us to, uh... well, they allow us to quantify our expressions. For example, you might use something like this to check for a UUID with RegEx:

/^\w{8}-\w{4}-\w{4}-\w{4}-\w{12}$/

Here, {8}, {4}, and {12} are all quantifiers. They indicate that you want exactly 8, 4, and 12 respectively of the preceding search. With Melody, this would be handled with the ... of ... quantifier:

<start>;
8 of <word>;
"-";
4 of <word>;
"-";
4 of <word>;
"-";
4 of <word>;
"-";
12 of <word>;
<end>;

If you need a number of characters within a certain range, you can use {min,max}. For example, \d{1,2} would indicate that you want between 1 and 2 digits. Melody provides the ... to ... of ... quantifier:

1 to 2 of <digit>;

Melody also provides alternatives for the * (zero or more), + (one or more), and ? (zero or one) quantifiers:

// \d*
any of <digit>;

// \d+
some of <digit>;

// \d?
option of <digit>;

Character Ranges

When searching for something within a known character set you need to use a character range (hexadecimal, for example, would be [0-9a-f]). Declaring ranges is handled by the ... to ... expression.

// [a-f]
a to f;

// [1-5]
1 to 5;

Groups

One of the most vital features of RegEx is groups! Capturing and non-capturing groups make it possible to create extremely complex searches. Melody enables these capture, match, and either groups.

To capture the major, minor, and patch versions of a semver string:

capture major {
  some of <digit>;
}

".";

capture minor {
  some of <digit>;
}

".";

capture patch {
  some of <digit>;
}

If you need to match a search without capturing it, you can use match. If you need to join multiple match statements together, you can use either. Here we'll use both to handle the lack of multi-ranges to match a 2-digit hexadecimal value:

2 of match {
  either {
    0 to 9;
    a to f;
  }
}

So Much More!

Melody supports lots of other features, so make sure to check out the docs!

Putting Melody Thru Its Paces

The basic examples are cool and all, but I wanted to convert some of my real world RegExes to Melody to see if the readability argument still holds up.

A Simple Test

While working on my game (debug) recently I wrote a RegEx to grab the name, vendor ID, and product ID from a gamepad. Here's what the original version I wrote looked like:

/^(.*?) \((?:standard gamepad )?vendor: (\w+) product: (\w+)\)$/ui

The only issue I have with converting this to Melody is that Melody doesn't support flags, so my u (unicode) and i (case insensitivity) flags won't translate. For now I can handle that on the string before passing it to Melody's RegEx, but it's deffo a sizable shortfall to keep in mind.

Without further ado, here is my original RegEx converted to Melody syntax:

<start>;

capture {
  lazy any of <char>;
}

<space>;
"(";

option of match {
  "standard gamepad ";
}

"vendor: ";

capture {
  some of <word>;
}

<space>;
"product: ";

capture {
  some of <word>;
}

")";

<end>;

It's a lot more verbose than the original RegEx, but that's what we want! The resulting Melody version is definitely more human readable than the original RegEx, though if you already know how to read RegEx then it's debatable whether or not the Melody version is more readable.

For good measure, though, let's do a side-by-side of the original RegEx alongside the output from Melody:

// Original
/^(.*?) \((?:standard gamepad )?vendor: (\w+) product: (\w+)\)$/ui

// Melody
/^(.*?) \((?:standard gamepad )?vendor: ((?:\w)+)product: ((?:\w)+)\)$/

The weirdest thing I've noticed is that Melody tends to add more non-capturing groups than necessary. For example, the only difference between the original and the Melody output is that the \w escape codes are being wrapped in an extra non-capturing group. That's totally unnecessary and I've made an issue on the repo for it.

Let's Get More Complex

Last year I ran across an absurd Password Validation challenge. You can see my solution in action on RegExr.com, but here's the actual RegEx I came up with:

/(?:.*(?:(?:[A-Z].*(?:[0-9].*[a-z]|[a-z].*[0-9]))|(?:[a-z].*(?:[A-Z].*[0-9]|[0-9].*[A-Z]))|(?:[0-9].*(?:[A-Z].*[a-z]|[a-z].*[A-Z]))).*)/

Every time I go back and try to read it... 🤢

The fact that this RegEx is so impossible to read is exactly why I thought it would be a great test of readability for Melody. Let's take a look at what the Melody version looks like:

match {
  any of <char>;

  either {
    match {
      A to Z;
      any of <char>;

      either {
        match {
          0 to 9;
          any of <char>;
          a to z;
        }

        match {
          a to z;
          any of <char>;
          0 to 9;
        }
      }
    }

    match {
      a to z;
      any of <char>;

      either {
        match {
          A to Z;
          any of <char>;
          0 to 9;
        }

        match {
          0 to 9;
          any of <char>;
          A to Z;
        }
      }
    }

    match {
      0 to 9;
      any of <char>;

      either {
        match {
          A to Z;
          any of <char>;
          a to z;
        }

        match {
          a to z;
          any of <char>;
          A to Z;
        }
      }
    }
  }

  any of <char>;
}

That's... a lot to chew on. However, it is undeniably easier to read than the original RegEx! The one caveat about the output is that it still suffers from the issue I mentioned in the last example with the unnecessary non-capturing groups. Otherwise, the output is perfect! ❤️

Final Thoughts

Melody seems like it'll be an excellent addition to the JavaScript ecosystem! It's got a ways to go, but I'm personally excited to watch how it matures.

In case Yoav is reading this, lemme tell you what I'd looove to see: I can write my RegEx by creating a .melody file, then I can import myRegex from './my-regex.melody' and use myRegex directly in place of a regular RegEx! There's a Babel plugin that allows writing Melody within template strings, but it'd be amazing to be able to write it in completely separate files and have it imported via a custom Webpack loader or Rollup plugin. HMU if you wanna pair on that project. 🥳

Loading Images with Web Workers

Trezy — Mon, 10 Jun 2019 20:32:49 +0000

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. 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:

/*
 * 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:

/*
 * 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:

<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 a 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:

/*
 * 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:

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.
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.
~~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 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 Blobs:

/*
 * 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:

/*
 * 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 6: 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.

/*
 * 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)

  // Once the image is loaded, we'll want to do some extra cleanup
  imageElement.onload = () => {
    // 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’)

    // We'll also revoke the object URL now that it's been used to prevent the
    // browser from maintaining unnecessary references
    URL.revokeObjectURL(objectURL)
  }

  imageElement.setAttribute('src', objectURL)
})

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

Check out the Codepen demo with everything working together:

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. 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:

/*
 * 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.

Updates

13 November, 2019

Added the URL.revokeObjectURL(objectURL) call based on @monochromer's comment.
Fixed several typos.

From the Devtools to the Clipboard

Trezy — Tue, 04 Jun 2019 03:29:55 +0000

You CAN jam stuff into your clipboard from the devtools!

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…

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

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.

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():

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:

JSON.stringify(bigDataSet, null, 2)

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

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, here, and here.

Why Is Browser Caching So Hard?

Trezy — Tue, 04 Jun 2019 03:29:05 +0000

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 Trezy.com.

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.

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.

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.

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, 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 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.

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.

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.
😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁

Stop Using ngOptions

Trezy — Tue, 04 Jun 2019 03:28:22 +0000

This article was originally published on 02 September, 2015 at Codepen.io.

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

var selectedState, availableStates;

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

  // ...

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

<!-- `ng-model` represents the home for our selected value. -->
<select ng-model=”selectedState”>
  <!-- This is the default option -->
  <option value=””>Select a state</option>

  <!-- The list of states. -->
  <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:

ng-model=”selectedState”
ng-options=”state.name as state.code for state in availableStates”>

Select a state

(╯°□°)╯︵ ʎʇıןı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.

:trollface:

On Handlebars and Template Tags

Trezy — Tue, 04 Jun 2019 03:26:57 +0000

This article was originally published on 17 June, 2014 at Codepen.io.

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, here are the pillars of <template> tags:

Its content is effectively inert until activated. Essentially, your markup is hidden DOM and does not render.
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.
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.
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>:

<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 tells us that we’re lacking support in Internet Explorer (big surprise), Safari 7, and Blackberry. Luckily, we can add this shim 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.

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

<!-- Handlebars recommended template block syntax -->
<script type=”text/x-handlebars-template” id=”article-template”>
  <article>
    <h1>{{title}}</h1>
    {{content}}
  </article>
</script>

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

<!-- The exact same thing using template tags -->
<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 points out in the Codepen comments, not everything is hunky dory. Take a look at this code:

<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:

<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:

On Dropdown Menu Transitions

Trezy — Tue, 04 Jun 2019 03:26:20 +0000

This article was originally published on 01 March, 2014 at Trezy.com.

The CSS transition property allows for a lot of really cool effects in your design but it has definitely caused me to bang my head against the desk a few times. Here are some details about the transition property that aren’t very well documented.

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:

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

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:

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:

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 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:

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;
}

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-functions 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 and in the W3C spec 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:

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-functions, 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 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 Advanced Box Shadows

Trezy — Tue, 04 Jun 2019 03:25:31 +0000

This article was originally published on 03 December, 2013 at Trezy.com.

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 I’m too constrained by CSS3’s box-shadow implementation. 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.

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.

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. 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

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

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.

On Saving Characters

Trezy — Tue, 04 Jun 2019 03:24:26 +0000

Recently I discovered something mind-blowing that I feel like I should have known for years.

This article was originally published on 06 May, 2013 at Trezy.com.

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

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

Ubuntu is one of my favorite fonts which I import from 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:

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 or 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:

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.

On Variables, Calculations, and New Units

Trezy — Tue, 04 Jun 2019 03:21:41 +0000

This article was originally published on 15 December, 2012 at Trezy.com.

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 CSS to add variables and calculations for years before LESS and SASS came along, giving us the ability to use these shiny new toys to our heart's content. However, SASS and LESS output can sometimes bloat your CSS sheets 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 nanny and started giving them a spit shine to make them 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. 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:

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

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

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:

: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:

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

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:

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

MDN Page | W3C Module

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:

: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. rems are much easier to use then ems, 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:

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

HTML Elements: Menu vs. Nav

Trezy — Tue, 04 Jun 2019 03:20:50 +0000

…or Why the Hamburger Icon is Awesome.

This article was originally published on 16 April, 2015 at Codepen.io.

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.

On CSS Tooltips

Trezy — Mon, 03 Jun 2019 20:52:06 +0000

This article was originally published on 05 October, 2012 at Trezy.com.

Pure CSS tooltips have been a thing for a while now but all of the solutions I've found have had limitations. After reading through Louis Lazaris's article Pure CSS Tool Tips Revisited over at ImpressiveWebs, I decided to make a few modifications of my own to his design.

Check Out the Demo

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.

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 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. 😉

DEV Community: Trezy

Melody: A New Way to RegEx

Interesting Syntax

Symbols

Special Symbols

Quantifiers

Character Ranges

Groups

So Much More!

Putting Melody Thru Its Paces

A Simple Test

Let's Get More Complex

Final Thoughts

Loading Images with Web Workers

Why would we want to load images with web workers?

The standard, vanilla implementation

Let's Get Into It

Step 1: Update your markup

Step 2: Pass the image URLs to our web worker

Step 3: Download the images

fetch is for more than just JSON

Step 4: Return the image data to the UI thread

Step 6: Render that image!

BONUS: Implementing web workers with Webpack

Conclusion

Updates

From the Devtools to the Clipboard

You CAN jam stuff into your clipboard from the devtools!

Anyway.

Okay, how do we do it better?

Wow, Trezy! You sure are smart and amazing!

Why Is Browser Caching So Hard?

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?

So… is there a better way?

Let’s take a look at some implementation

Make it real!

Stop Using ngOptions

On Handlebars and Template Tags

Why isn’t this being used elsewhere?

The catch

On Dropdown Menu Transitions

The long and the short of it

Transitions swing both ways

It’s all in the timing

ease

ease-in

ease-out

ease-in-out

linear

step-start / step-end

steps(number_of_steps, direction)

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

Conclusion

On Advanced Box Shadows

Rocking out with box-shadow

Box-shadow… without box-shadow?

Oooooh… that’s way prettier.

Conclusion

On Saving Characters

Recently I discovered something mind-blowing that I feel like I should have known for years.

On Variables, Calculations, and New Units

Variables

Calculations

Units

rem

vw and vh

vmin and vmax

HTML Elements: Menu vs. Nav

…or Why the Hamburger Icon is Awesome.

Hamburger Icon vs. Hamburger Menu

Menu vs. Nav

Menus

Navs

Why Does Any Of This Matter?

The Point

On CSS Tooltips

The Problem

Multiline

IE8 Compatible

No Extra HTML

`fetch` is for more than just JSON

`ease`

`ease-in`

`ease-out`

`ease-in-out`

`linear`

`step-start` / `step-end`

`steps(number_of_steps, direction)`

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