bitsofcode

When is :focus-visible visible?

2023-03-21T00:00:00Z

Focus outlines (and their styling) have frequently been a point of contention between aesthetics and usability. On the one hand, focus outlines are incredibly important for navigation, particularly by users navigating via keyboard or other non-pointer devices. On the other hand, for certain mouse or touchscreen users they can be unnecessary and detract from the design.

Before the :focus-visible CSS pseudo-class was introduced, there was no middle ground to this debate - you either sided with design or accessibility (hopefully the latter). But now, with :focus-visible, we can have focus styles that apply only when the browser / user agent determines that focus should be indicated on the element.

So, when do user agents determine that focus should be indicated? According to the :focus-visible specification, user agents are free to choose their own heuristics for indicating focus. However, the spec includes some suggestions, which most browsers have adopted. These suggestions can be broken down into four questions -

Has the user expressed a preference for always visible focus?
Does the focused element support keyboard input?
Is the user interacting with the focused element with a non-pointing device?
Did a script cause focus to move from a previously visibly-focused element?

Let’s break each of these questions down.

1. Has the user expressed a preference for always visible focus? #

This is a simple one. If a user has expressed a preference for focus to always be visible, then the :focus-visible pseudo-class should apply to the focused element. Fin.

2. Does the focused element support keyboard input? #

If the focused element supports keyboard input, the :focus-visible pseudo-class should apply. Elements that support keyboard input are typically form elements, such as <input> or <textarea>, basically any element that would trigger a virtual keyboard to be shown in the absence of a physical one.

In the example below, we have both a <button> and an <input>. For the <button>, whether the :focus or :focus-visible style is applied depends on how you interact with the element (more on that in the next section). But regardless of how you interact with the <input> element, it always displays both the :focus style and the :focus-visible style of the red border.

See the Pen Untitled by Ire Aderinokun (@ire) on CodePen.

3. Is the user interacting with the focused element with a non-pointing device? #

Next, if the user is interacting with the focused element using a keyboard or another non-pointing device, the :focus-visible pseudo-class should apply. So regardless of the type of element it is, focus should be visible.

In the example below, the <button> elements display the :focus and/or :focus-visible styles depending on what device you use to interact with it.

See the Pen :focus-visible - Is the user interacting with a non-pointing device? by Ire Aderinokun (@ire) on CodePen.

4. Did a script cause focus to move from a previously visibly-focused element? #

Finally, this question is to do with what happens if focus is moved via a script instead of user input. According to this guideline, the :focus-visible pseudo-class should apply based on the state of the previously focused element. If :focus-visible applied to the previously focused element, then it should also apply to the currently focused element.

We can see this play out in the example below. Depending on how you interact with the “reset” button, the :focus and/or :focus-visible styles will apply to the test button when focus is programatically moved.

See the Pen :focus-visible - script by Ire Aderinokun (@ire) on CodePen.

Bonus - User agent wildcard #

As a reminder, these are mostly guidelines/suggestions and user agents are still able to make decisions about when they want :focus-visible to apply. From my tests, I haven’t seen any of the major browsers respond in a different way, but it’s something to remember.

Because of this, best practice is always to only remove :focus styles if :focus-visible is not also applied to the element. Here’s what that looks like:

/* Apply focus styles */
:focus-visible, :focus {
  outline: 1px solid red;
}

/* Remove the focus outline */
:focus:not(:focus-visible) {
  outline: none;
}

From Ghost to 11ty

2023-02-22T00:00:00Z

Over 5 years ago, I migrated this blog From Jekyll to Ghost. Back then, my reasons for moving to Ghost were because -

I wanted a CMS

Managing all the posts’ raw markdown files in one folder was getting clunky

The Jekyll build process was starting to significantly lag

I no longer wanted to have to manually upload new posts via FTP

I wanted to be able to schedule posts (although Ghost doesn’t support this yet), or at least push one button to publish them

Today, I want the exact opposite 😅

I no longer need a CMS. Since I now post a lot less frequently than before, having a full-blown CMS isn’t necessary.
While raw markdown files can be a bit clunky, I prefer them to Ghost’s CMS. One of the reasons I chose Ghost in the first place was because, at the time, the editor allowed you to write in pure markdown. Over the years, they’ve made this more difficult and basically force you to use their WYSIWYG editor.
The build process of 11ty is fast, even with 160+ articles.
Luckily, the world has progressed from FTP 🥳 . Now, I can publish on Netlify just by pushing to GitHub.
While I haven’t yet set this up, scheduling blog posts is possible with 11ty and Netlify.

So, last week, I migrated this blog to 11ty. I managed to do the bulk of the migration in one day, but continued fixing some bugs over the next few days. Here’s how the migration process went.

Step 1 - Convert the Ghost export to markdown #

One of the great things about Ghost is it allows you to export all your site data into one big JSON file. So, the first thing to do in this migration was to convert that JSON export to individual markdown files for each post.

Luckily, there’s an NPM package for that - ghost-to-md. I did run into a slight issue with that package due to the library it was using to convert HTML content to Markdown. So, I created a fork of the package (ireade/ghost-to-md), using a different HTML-to-Markdown converter, which worked better for me.

Using this package, I was able to generate a folder filled with individual markdown files for each blog post.

Step 2 - Organise each post into sub-folders #

With 11ty, you have a lot of freedom with how and where you want to store all post files. For me, I wanted a structure where, within the directory for all posts, each post will have its own folder, and the markdown file will be within that folder. So, instead of a folder structure like this -

- content
  - blog
    - article.md

I'd have a structure like this -

- content
  - blog
    - article
      - article.md
      - [other files related to the article]

The reason I wanted it this way was so that within each article folder, I could also store all the media related to that article. This makes it easy to use the 11ty shortcode for responsive images (more on that in Step 4).

To achieve this, I wrote a script to read all the exported markdown files, and create new subdirectories for each of them.

const inputDir = './ghost-to-md-output';
const outputDir = './output';

// Read all files in inputDir
fs.readdir(inputDir, (err, files) => {
  if (err) return;

  // Loop through each file
  files.forEach((file) => {

    const fileName = path.parse(file).name;
    const inputFilePath = path.join(inputDir, file);
    const outputFolderPath = path.join(outputDir, fileName);

    // Create folder in outputDir
    fs.mkdir(outputFolderPath, err => {
      if (err && err.code !== 'EEXIST') return;

      const outputFilePath = path.join(outputFolderPath, file);

      // Copy markdown file to new folder
      fs.copyFile(inputFilePath, outputFilePath, err => {
        if (err) return;

        console.log(`Successfully copied ${file} to ${outputFolderPath}`);
      });
    }); // end fs. fs.mkdir
  }); // end files.forEach
});

The result was something like this -

Step 3 - Download media hosted on Ghost #

The next step was to download media content hosted on Ghost. If you look through the markdown files, you’ll notice that some of the URLs looks like this -

__GHOST_URL__/content/images/2019/01/image.png

This refers to images/media uploaded via the CMS and hosted on Ghost. The JSON export doesn’t include any media, so what I needed to do was manually download every image and place them in the correct folder.

Again, I used a script for this. I created a function that:

Takes the folder path to an article, plus the article file name;
Downloads all images starting with __GHOST_URL__; *
Places them in the articleFolderPath;
Replaces the URL in the markdown file with a local relative URL, (i.e. starting with ./)

// Takes the folder path to an article, plus the article file name
function downloadImages(articleFolderPath, fileName) {

  const markdownFilePath = articleFolderPath + "/" + fileName;

  fs.readFile(markdownFilePath, 'utf8', (err, data) => {
    if (err) return;

    //  🚨Warning - Very buggy! (see note below)
    // Find all images starting with __GHOST_URL__
    const regex = /\(__GHOST_URL__([\s\S]*?)\)/g;
    let match;

    while ((match = regex.exec(data)) !== null) {

      const ghostHostedUrl = 'https://bitsofco.de' + match[1];
      const filename = path.basename(ghostHostedUrl);
      const filePath = path.join(articleFolderPath, filename);

      console.log(`Downloading image from ${ghostHostedUrl} to ${filePath}`);

      const file = fs.createWriteStream(filePath);
      https.get(ghostHostedUrl, response => {
        response.pipe(file);
        console.log(`Successfully downloaded image to ${filePath}`);
      }).on('error', err => {
        console.log(`Error downloading image: ${err}`);
        fs.unlink(filePath, () => {});
      });

      // Replaces the URL in the markdown file with a local relative URL
      data = data.replace(match[0], `(./${filename})`);
    }

    fs.writeFile(markdownFilePath, data, err => {
      if (err) return;
      console.log(`Successfully updated file: ${markdownFilePath}`);
    });
  });

}

* Note - This regex was buggy. I later realised that there were more URLs that started with this same __GHOST_URL__ string. For example, links to other pages within the Ghost site started with that string, so the script replaced those instances as well. If you want to use this, I'd suggest you update the regex to only look for images.

Step 4 - Use the 11ty Image Plugin #

Since each blog post is written in markdown, I could link to images using the regular markdown syntax -

![Image description](image.png)

However, 11ty has an Image Plugin, which performs build-time image transformations for locally-stored images. By linking to one single image file, the plugin will automatically generate images in different sizes and formats. To take advantage of this, instead of using the markdown syntax above, we need to use this image shortcode -

{% image "image.png", "Image description" %}

So, I wrote a script to make this change. This script was also pretty buggy and resulted in the shortcode being inserted into places is shouldn’t have, so I wouldn’t recommend you use as-is. That said, it did work well enough for me, I just had to go through and fix some buggy places.

function convertMarkdownImagesTo11ty(articleFolderPath, fileName) {

  const markdownFilePath = articleFolderPath + "/" + fileName;

  fs.readFile(markdownFilePath, 'utf8', (err, data) => {
    if (err) return;

    //  🚨Warning - Very buggy!
	//  Find all images starting with "./"
    const regex = /!\[(.*?)\]\(\.\/(.*?)\)/g;
    let match;

    while ((match = regex.exec(data)) !== null) {
      const altText = match[1];
      const imagePath = match[2];
      const eleventyImage = `{% image "${imagePath}", "${altText}" %}`;
      data = data.replace(match[0], eleventyImage);
    }

    fs.writeFile(markdownFilePath, data, err => {
      if (err) return;
      console.log(`Successfully updated file: ${markdownFilePath}`);
    });
  });
}

Step 5 - Setup 11ty with eleventy-base-blog #

Now that the content was all set up, I could finally move on to 11ty! This part was pretty straightforward. To setup the new project, I used the 11ty/eleventy-base-blog starter repository. This already had setup all the relevant pages and templates. All I had to do was tweak the page structure and styling to the theme of my blog.

To add all my post content, I just pasted all the newly-created directories into the content/blog directory.

A few implementation details to mention -

Permalinks #

The URL structure for the articles on Ghost was pretty simple -

https://bitsofco.de/[article-slug]

Luckily, the ghost-to-md script does include the post slug in each file’s front matter. So, all I had to do was make it such that all posts used that slug for their permalink. To do that, I added the following to the content/blog/blog.11tydata.js file, which has global configuration for all posts.

module.exports = {
	/* other config */
	eleventyComputed: {
		permalink: data => `/${data.page.fileSlug}/`
	}
};

Tags #

One issue with the conversion from Ghost to Markdown is how tags are handled. In the export, multiple tags on a post are comma-separated, like this -

---
title: Example Article
slug: example-article
tags: one, two
---

However, 11ty needs them to be formatted like this -

---
title: Example Article
slug: example-article
tags:
  - one
  - two
---

This was an annoying bug to find out at the 11th hour, and I ended up having to fix it manually. If I were to do this again, I'd probably write a script to automate the process.

Update - An issue has been filed to support tags as a comma-separated list! (#2820)

Post excerpts #

As far as I know, 11ty doesn’t have a native way to show excerpts from posts, so I had to add a custom shortcode to do that. I got the code for that from this article - Excerpts with Eleventy, by Jonathan Yeong.

CanIUse Embed #

Since the embed I created to display caniuse data is an integral part of my posts, I wanted to create a custom plugin to make embedding them easier (similar to how the image plugin works). Luckily for me, someone already beat me to it 😅 . I integrated the plugin, KevinGimbel/eleventy-plugin-caniuse, and now I can add the embed by using the following shortcode -

{% caniuse "css-grid" %}

And get this result -

Set 6 - Run `npm start` and fix bugs #

After building the 11ty site, a lot of random bugs came up that I had to fix manually. I was able to debug them pretty easily due to the descriptive error messages, but here are some of the main ones in case you run into similar issues -

Markdown errors, especially with tables - This wasn't really an error but rather the markdown tables were sometimes strange. If you're going through this migration process, I would recommend that you go through all the places you have tables to make sure they look right.
Using nunjucks within the code examples - One weird bug I ran into was if I happened to be demonstrating a code example within my markdown file that was in Nunjucks. For example, the code above demonstrating how I use the caniuse shortcode. In these cases, I had to wrap the code block with a {% raw %}{% endraw %} to make sure it's not trying to execute the block itself.
Double-quotes in post titles - Another thing to look out for is if quotes are being used in the front-matter. In some cases, you may need to escape the quotes by adding a backwards slash \" in front of them
Broken links - I also did a check for broken links using this free broken link checker. This helped me track down and fix those random side-cases, a lot of which were closed by my own code above 😂

That was it! It’s only been a few days, but so far I’m loving 11ty. I'm also in the middle of doing a redesign, so more on that soon!

Web Performance Metrics Cheatsheet

2021-10-25T00:00:00Z

I recently gave a talk on “Making Sense of Performance Metrics” at the Web Unleashed Conference, and it was suggested that I turn the breakdown of all the performance metrics into a cheatsheet; so here it is!

The full cheatsheet, including a downloadable PDF version, are at the bottom of the page so feel free to skip to that.

Four Questions #

In a web.dev article on "User-centric Performance Metrics", they frame performance metrics around four questions:

Is it happening?
Is it useful?
Is it usable?
Is it delightful?

I really like this framework as a way to better understand what aspect of the user experience each metric is tracking.

1. Is it happening? #

This is about measuring if there is any response after a user starts the navigation to the page. There are three metrics that fall under this category.

Time to First Byte (TTFB) #

Time to First Byte measures the time from when the browser requests a page to the first byte of the page being received. This is really useful for measuring the roundtrip between the user’s device and the server. A good number to aim for is 600 milliseconds or less.

First Paint (FP) #

First Paint measures the time when the first pixel is painted on the screen. This isn't the most user-centric metric, since at first paint there still isn't any content on the screen, but it's useful to know. Because it's not so user-centric, I wasn't able to find any reliable guidelines for what a good number for FP should be, but it should of course fall somewhere between TTFB and and FCP.

First Contentful Paint (FCP) #

First Contentful Paint measures the time when the first piece of content from the DOM is rendered. This is a useful metric to track because this is the point at which a user actually gets recognisable feedback. A good number for this is 1.8 seconds or less.

2. Is it useful? #

While the previous metrics measure if there is any content on the page, these metrics measure if the content rendered is actually useful or meaningful to a user.

Largest Contentful Paint (LCP) ⭐️ #

Largest Contentful Paint, one of the three Core Web Vitals, measures the time when the largest piece of content within the viewport is rendered. It can also be configured to measure when a specific piece of content is loaded, instead of just the largest by size. LCP is a successor to the First Meaningful Paint metric, which is no longer recommended as it is not standardised. A good number for LCP is 2.5 seconds or less.

Visually Complete (VC) #

Visually Complete measures the time taken for the content within the viewport to be fully rendered. It's based on an algorithm that sets "visual completion" as the capture of the frame that is the least different to the final frame. There are different Visual Complete metrics you can use based on what percentage to completeness you are trying to track, e.g. Visually Complete 85% etc. A good number for VC is 3.4 seconds or less.

Speed Index (SI) #

Speed Index is a similar score to Visually Complete in that is also measures how quickly content is visually displayed during the page load. However, SI also takes into account how your site performs in comparison to other sites on the web. Like VC, a good number to aim for is 3.4 seconds or less.

3. Is it usable? #

These metrics are about measuring if a user can actually interact with the content that has been rendered.

First Input Delay (FID) ⭐️ #

First Input Delay, another Core Web Vital, measures the delay between the time a user can attempt to interact with a part of the site, and the time that the interface is able to respond to that interaction. This is an important metric to track because, generally, if users see an interactive element such as a button, they assume that it can be interacted with reliably. If there is a delay between when a user presses the button and when they get feedback, this can become an issue. Ideally, FID should not surpass 100 milliseconds.

Max Potential First Input Delay (mFID) #

Max Potential First Input Delay measures the maximum possible First Input Delay that could occur based on the duration of the longest task. This is a useful metric to have because FID is a field metric, which means it's based on real user data and cannot be measured by page simulations (i.e., in the lab). So, if you want an approximation of the worst case scenario of FID while you're still in a lab setting, mFID is a good option. Ideally, mFID should be 130 milliseconds or less.

Total Blocking Time (TBT) #

Total Blocking Time measures the total duration of Javascript tasks between the First Contentful Paint and Time to Interactive. This metric gives us a sense of how long a user could potentially be waiting if there are several blocking tasks. Because while mFID tells us the duration of the longest blocking task, a user may end up waiting even longer than that if there are several blocking tasks in a chain. TBT is expected to be 200 milliseconds or less.

Time to Interactive (TTI) #

Time to Interactive measures the time when the main thread has had up to 5 seconds with no network activity or JavaScript tasks. Having up to 5 seconds clear is important because that’s when the main thread is clear enough to reliably respond to user input. TTI should be at most 3.8 seconds.

4. Is it delightful? #

Finally, this category of metrics measures the experience of the interactions and how enjoyable and pleasant the website is to use.

Cumulative Layout Shift (CLS) ⭐️ #

Cumulative Layout Shift, the third Core Web Vital, measures the shifts in layout while a page is loading. This metric is calculated based on how much elements shift relative to the viewport (impact fraction) and what distance they travel (distance fraction). A good score for CLS is 0.1 or less.

Frame Rate #

Frame rate is the rate at which the browser can produce new frames in response to interactions and/or animations. The standard for a smooth frame rate is 60 frames per second.

The Cheatsheet #

Here are all the metrics together, including what a good score is to aim for, and whether they can be measure in the lab or field.

Metric	Description	✅	Lab?	Field?
Time to First Byte (TTFB)	Measures the time from when the browser requests a page to the first byte of the page being received	<600ms	✅	✅
First Paint (FP)	Measures the time when the first pixel is painted on the screen	<1.8s *	✅	✅
First Contentful Paint (FCP)	Measures the time when the first piece of content from the DOM is rendered	<1.8s	✅	✅
Largest Contentful Paint (LCP) ⭐️	Measures the time when the largest piece of content within the viewport is rendered	<2.5s	✅	✅
Visually Complete (VC)	Measures the time taken for the content within the viewport to be fully rendered	<3.4s	✅	❌
Speed Index (SI)	Measures how quickly visual content is rendered within the viewport	<3.4s	✅	❌
First Input Delay (FID) ⭐️	Measures the delay between the time a user can attempt to interact with a part of the site, and the time that the interface is able to respond to that interaction	<100ms	❌	✅
Max Potential First Input Delay (mFID)	Measures the maximum possible First Input Delay based on the duration of the longest task	<130ms	✅	❌
Total Blocking Time (TBT)	Measures the total duration of Javascript tasks between the FCP and TTI	<200ms	✅	❌
Time to Interactive (TTI)	Measures the time when the main thread has had up to 5 seconds with no network activity or JavaScript tasks	<3.8s	✅	❌
Cumulative Layout Shift (CLS) ⭐️	Measures the shifts in layout while a page is loading	<0.1	✅	✅
Frame Rate (FR)	Measures the rate at which the browser can produce new frames in response to interactions and/or animations	60 FPS	✅	✅

👉🏾Download the PDF !👈🏾

Setting up a Decentralised Website (ENS + IPFS = dWeb)

2021-06-18T00:00:00Z

One thing that I’ve been really into lately has been ENS names. As someone who’s already obsessed with buying domain names, ENS names have been an even greater obsession (mostly because of emoji names, like ✊🏾✊🏾✊🏾.eth)!

So what are ENS names, exactly? And what is a “decentralised website”?

A short intro to ENS, IPFS, and the dWeb #

Let’s start with ENS. The Ethereum Name Service is a naming system based on the Ethereum blockchain. It has a lot of parallels with the Internet’s Domain Name Service (DNS) in that both of these services are used to map human-readable names to less human-readable characters. Where DNS names map to IP addresses, ENS names can map to cryptocurrency addresses, content hashes, and other metadata.

For example, I have the ENS name bitsofcode.eth, which maps to the ETH address 0x3ca2FC4f1F207178Fee25a9Aa8676ec00292dcfc. If someone (👀) wanted to send me Ether, they could simply put in the ENS name instead of copying and pasting the longer, less user friendly, address.

As I mentioned, ENS names can map on to more than just cryptocurrency addresses, and this is where the really fun part comes in. In addition to metadata like a website or twitter username, we can also map an ENS name to what’s called a content hash. A content hash, similar to an IP address, is a unique identifier for hosted content, i.e. files. However, unlike IP addresses that are based on a location where content is stored, content hashes are based on the content itself. This may not make a lot of sense now, but we’ll see how this distinction matters when we setup our dWebsite below.

So how and where do we host these files? That’s where IPFS comes in! The InterPlanetary File System is a “distributed system for storing and accessing files, websites, applications, and data”. Unlike other hosting options which have a centralised server, IPFS is ✨decentralised✨. It’s powered by a peer-to-peer network that stores and relays content as needed. If you’ve ever used BitTorrent, it’s a very similar concept.

Both ENS and IPFS together form the Decentralised Web - websites that are hosted via a decentralised system such as IPFS, and accessed via a decentralised name service such as ENS.

How to publish a dWebsite #

So how does one setup and publish a dWebsite? Well, there are four steps:

1. Build your website #

You can build a dWebsite in pretty much the same way you’d build any other website. As long as, at the end, you have a directory with all your files contained in them, you’re good.

For my bitsofcode.eth example, I decided to create a simple page that loads an iframe of the original blog.

The entire website is just 3 files - 1 HTML and 2 CSS (view on GitHub).

2. Register an ENS name #

Depending on if you already have a cryptocurrency wallet (and some ETH stored in it), this may be an easy or difficult step. For an in-depth guide for how to set everything up from scratch, I suggest you read this great article on How to register an ENS name for your wallet address by Teju Adeyinka (teju.eth).

If you already have a wallet + ETH, go to ens.domains to register your .eth name.

3. Upload your files on IPFS #

Next, you’ll need to upload your website files on IPFS. I recommend using a service like Pinata, which makes this process really simple. Once you’ve uploaded your files, you’ll get an IPFS CID (Content Identifier).

The CID is a unique hash for your specific content. This is where the fact that a content hash (i.e., the CID) is based on content, not location, comes in. It means that, once you’ve uploaded your files on IPFS and get a CID for those specific files, you won’t be able to change the content of the files and retain the same CID. If the content changes, the CID changes.

4. Link your ENS name to your website #

Finally, we can connect the pieces. Going back to ENS, we now need to edit the records associated with the ENS name and add the content hash. Since we’re using IPFS to store our content, we need to add a prefix of ipfs:// before the CID from Pinata.

At this point, the site is now accessible via the raw ENS name in browsers like Opera or via browser extensions like Metamask. For other/all browsers, the site can be accessed by the ENS name with a .link appended, e.g. bitsofcode.eth.link.

Redirecting an ENS name to an existing website #

Given the limitations of not being able to update the content of a site hosted on IPFS without also changing the content hash, you may want to just redirect your ENS name to an existing website hosted elsewhere. This is the approach I took for my personal website, ireaderinokun.com, and my personal ENS name, ire.eth.

To do this, we need to replace step 1 of “building our dWebsite”, with a simple webpage that redirects to the existing website of our choice. Here’s an example of what that page could look like:

<!DOCTYPE html>
<html lang="en" dir="ltr">
    <head>
        <meta charset="utf-8">
        <title>ire.eth</title>

        <script>
            window.location.href = "https://ireaderinokun.com"
        </script>
    </head>
</html>

All the other steps remain the same.

Now, if you visit ire.eth, you’ll be automatically redirected to ireaderinokun.com! 🚀

Highlights from Chrome Dev Summit 2020

2020-12-14T00:00:00Z

CDS in 2020 was a bit different, like everything else. It was online, and the talks were more bite-sized at roughly 10 minutes each. I really enjoyed this new style of the summit and, while I missed the in-person aspects of the conference, this was a great way to end the year. So, without further ado, here’s what I’m most excited about from the conference!

Simplified performance metrics with the "Core Web Vitals" #

As we all know, there are a tonne of performance metrics out there we can use to track seemingly everything about how our websites perform. Although this granularity is great because it allows us to dig deep into specific areas we may need to track, it does make getting into performance metrics a little bit daunting.

The solution to this is what the Chrome team are calling the “Core Web Vitals”. These are 3 performance metrics that they present as the critical vitals to keep track of:

First Contentful Paint - this measures the loading experience
First Input Delay (or Total Blocking Time) - this measures the interactivity experience
Cumulative Layout Shift - this measures visual stability

Image from web.dev

Going forward, the Lighthouse performance score will be more heavily weighted to these metrics, so they are definitely the ones to start with.

Most of the first day of CDS was spent around what these metrics are, how to track them, and how to fix common issues with them. If you want to know more, I’d recommend you watch the following sessions:

State of speed tooling by Elizabeth Sweeny and Paul Irish
Fixing common Web Vitals issues by Katie Hempenius

New CSS properties for performance #

Continuing with the theme of performance, there are some new CSS features geared towards better performing sites.

The content-visibility property allows us to tell the browser when to render an element. The “magic” value here is auto, which tells the browser not to render an element until it’s visible in the viewport. This means that page loads will be significantly faster, if the browser only needs to render above-the-fold content initially. In Jake Archibald’s talk Beyond fast, he mentioned how the HTML Standard layout time went from 50 seconds to 400 milliseconds, just by using this property!

The content-visibility property works hand in hand with the contain-intrinsic-size property to prevent potential issues with Cumulative Layout Shift. Because the browser isn’t rendering the element fully on load, there may be some shift when it does need to render the element. In order to minimise shifts happening on the page, we can use the contain-intrinsic-size property to specify dimensions for the element even without the content being rendered.

.below-fold-element {
    content-visibility: auto;
    contain-intrinsic-size: 0 500px; /* set height to 500px */
}

I like to think of this property like adding a width or height to media elements to reserve that space so the page doesn’t shift when the media is eventually loaded.

These properties are already shipped in Chrome (and by extension Edge). But the great thing about CSS is they can be used today and will just be a nice enhancement for browsers that do support it.

Shipping modern Javascript #

According to Houssein Djirdeh and Jason Miller in their talk on Transitioning to modern JavaScript, over 90% of web traffic comes from browsers that support ES2017. This means that we could technically be shipping features like classes, arrow functions, and async/await directly to browsers with zero transpilation needed!

That said, we still need to figure out a way to work with both the 90% and the 10%. And, given that the majority of browsers support modern javascript, the solution isn’t to just ship the transpiled code to all browsers. Instead, we should have both modern and legacy versions of our app files, and serve them based on the support of

`type=module` #

This isn’t exactly new, but one way to serve different files based on browser support is to use type="module" on script tags for modern files, and to specify the nomodule attribute for the legacy files.

<script type="module" src="modern.js"></script>
<script nomodule src="legacy.js"></script>

Browsers that support type="module" will load that file, and it'll be ignored by the legacy browsers.

Package `exports` #

In our package.json file, we can now define another “main” script file using the exports key.

{
    "name": "my-package",
    "exports": "./modern.js",
    "main": "./legacy.js"
}

This exports field is only supported in Node 12.8 and above, which implies support for ES2019+ syntax.

Tabbed desktop PWAs! (& more) #

PWAs installed to desktops are receiving a lot of awesome new features. The most exciting for me is the fact that these apps can now be tabbed!

This is implemented via the display_override field in the web manifest, which allows us to specify a list of display modes we want to use, in order of priority.

{
    "display": "standalone",
    "display_override": ["tabbed", "minimal-ui"],
}

This will allow us to create tabs in our PWAs! This will be a critical feature for so many desktop PWAs.

Screenshot from Next-level web apps on desktop talk at CDS 2020

Another interesting new API will allow our desktop PWAs to be launched on login to the device.

if (navigator.runOnOsLogin) {

    navigator.runOnOsLogin.set({ mode: "windowed" })
        .then(() => {
            // Permission approved
        });

}

Other interesting new APIS coming soon include:

File Handling API
Notification Triggers API
Digital Goods API
Local Fonts API

PJ Mclachlan’s talk on Next-level web apps on desktop dives in further into all these features.

Read my summaries of previous Chrome Dev Summits:

What was your favourite talk from the conference?

What I wish I knew about React

2020-04-28T00:00:00Z

A couple weeks ago I started working on my first React application. Not only was it my first React application, but it was also my first React Native application, so a lot was new to me all in one go.

Coming from the Angular (and Ionic) world, it felt like all my preconceived notions and ideas were being turned upside down. I managed to put together (what I think is) a pretty decent application, but I had a lot of roadblocks along the way. This is partly because I prefer to learn by just diving in (the only tutorial I did was this React Native Crash Course). So, a lot of these roadblocks could have been solved by me just reading the documentation.

That said, in case there’s anyone else there like me, here are a few things I wish I knew before I got started.

React is a library, not a framework #

This is something I technically knew as I had heard it several times before, but I didn’t really internalise it. I sort of assumed this was more of a technicality, rather than a key piece of information around which I should redefine my expectations.

What’s the difference between a library and a framework? #

The difference between a library and a framework is, it turns out, very key. Let’s use an analogy of trying to build a house. With a framework, you’re essentially given all the materials to build that house, and it’s up to you in what arrangement you put them in. You will very rarely need to step outside the materials you have been given to use something third-party and, in some cases, you may not be allowed to step outside the materials.

With a library, on the other hand, you start with essentially nothing. The library’s materials are a limited set in comparison to a framework’s materials, and you can pick/choose when you want to use them and when you want to step outside that and use third-party materials.

What does that really mean? #

For me, this understanding allowed me to step away from thinking that a React-specific solution was what I needed for everything.

For example, I spent hours trying to figure out how to do simple things like making a request to an API in React. In Angular, I would use their Angular-specific HttpClient to make such requests, but that doesn’t exist in React. It wasn’t until a kind twitter user made the (now obvious) point that I could just use a simple Javascript fetch() request, that I had this moment of realisation.

So now, I’ve redefined my expectations of what React will do for me. When I have a problem to solve, I know to think Javascript-first instead of React-first.

React is a UI library #

Not only is React a library, it’s specifically for User Interfaces. Again, this should be obvious considering it says so on their website, but I didn’t internalise it enough. The reason this is so important to understand is similar to why it should have been obvious to me that I could just use the browser’s native fetch() API.

If what you’re trying to do isn’t directly related to something visual on screen, React does not care

The way I like to think of it in comparison to Angular is this: Angular is a framework for architecting and building applications. It, for the most part, doesn’t change the way you write your HTML or CSS, but it heavily controls the way you write Javascript.

React, on the other hand, is a library for building user interfaces. It, for the most part, doesn’t change the way you write Javascript that isn’t directly related to your UI, but it heavily controls the way you write HTML and CSS (or the equivalent of it). And this brings me to the next point…

React component libraries are always for UI #

This is something that really made no sense to me the first time I realised it. Take, for example, the apollo-react library. In that library, you can use a <Query> element, which will perform a GraphQL query and return the result, right in your component markup.

import React from ‘react’;
import {Text} from ‘react-native’;
import gql from ‘graphql-tag’;
import {Query} from ‘react-apollo’;

const MY_QUERY = gql`query …{} `;

const ExamplePage = (props) => {
	return (
		<View>
			<Query query={MY_QUERY}>
				{({ loading, error, data }) => {
                    if (loading) return <Text>Loading</Text>;
                    if (error) return <Text>Error</Text>;
                    return <Text>{ JSON.stringify(data) }</Text>;
                }}
            </Query>
        </View>
    );
};

Being so used to the model-view-controller way of architecting applications, this seemed (and, to be honest, still seems) like such an unnatural way to interface with an API. Granted, you can also use the useQuery() Javascript function from the react-apollo library, but it has its own pretty significant limitations too.

I also came across this issue when trying to use ActionCable with React. The react-actioncable-provider package is for subscribing to ActionCable channels in your UI component. If you just want to subscribe to a channel and not immediately display data on the page, the package isn’t what you need.

Components will update, whether you want them to or not #

Before I understood why and when components updated, it seemed like my entire application was stuck in an infinite loop. I would do something like make an API call right at the root of the component, which itself would update the state, causing the component to re-render, and the API call would be made again.

const BadExamplePage = (props) => {

	const [user, setUser] = useState();

	getUser().then((u) => setUser(u));

    return (
        …
    );
};

Don't do this

If you use React, you’ll understand why this is a terrible idea. The getUser() function is called when the component updates. It then changes the state of the user variable, and this change causes the component to update, and so on and so on.

What I have since learned is that we can't always control exactly when or how often the component will re-render so, for use cases like this, we need useEffect()…

useEffect is a major 🔑 #

useEffect() is like a safe haven to me in the confusing world of React components. It’s for those cases where you’re just like, “Can I just write Javascript that will execute once please?”.

Although by default, the code within a useEffect() block runs on each re-render, we can choose to execute them only when certain values have changed or just once. We do this by passing a second argument to useEffect(), with an array of variables that, if their value should change, we want the function to be run again.

const BetterExamplePage = (props) => {

	const [user, setUser] = useState();

	useEffect(() => {
		getUser().then((u) => setUser(u));
	}, [ /* dependencies */ ]);

    return (
        …
    );
};

If we leave the array empty, that effectively means that the function will only run once.

I’m still on this React journey so I'm sure there’s still a lot for me to learn, but these are the things that I've found challenging so far.

How I created 488 "live images"

2019-11-26T00:00:00Z

I've recently been going down a rabbit hole of making improvements to my CanIUse embed. To give a bit of a background, it is an interactive embed I created to easily embed data from caniuse.com in my blog posts and anywhere else. I previously wrote about how I first created the embed and how I progressively enhanced it by adding a fallback screenshot captured with puppeteer and hosted on Cloudinary.

The next improvement on my path down this hole was to create what I’m calling "live images" for each feature on caniuse.com. What I wanted to do was have a URL linking to an image (hosted on Cloudinary) that I would periodically update with the support table for that feature. For example, to get the latest image of CSS Grid support, anyone could use this URL:

https://caniuse.bitsofco.de/image/css-grid.png

That image will be periodically updated (right now I’m doing once a day) and could then be used in places where Javascript is completely unsupported, e.g. Github READMEs, or just as a fallback for the full blown embed.

Since it’s also hosted on Cloudinary, any file type is supported and can be accessed on the fly, simply by changing the extension.

https://caniuse.bitsofco.de/image/css-grid.webp
https://caniuse.bitsofco.de/image/css-grid.jpeg
https://caniuse.bitsofco.de/image/css-grid.gif

Here’s how I did this!

Step 1: Capture 488 images using Puppeteer #

The first step is to create the images for the live embed, which involved capturing a screenshot of the embed page. I’ve covered in previous articles how to use puppeteer to capture a screenshot, so I won’t go over that again here.

However, there are 488 features on caniuse.com, and there is one thing to mention about trying to take 488 screenshots using Puppeteer in a row. You need to be careful about how you’re navigating to 488 different pages with Puppeteer.

At first, I was launching a new browser then attempting to to open 488 different pages on that browser.

const features = [ ... ];
const browser = await puppeteer.launch({ ... });

const screenshots = [];

for (let i = 0; i < features.length; i++) {

    // Opening a new page for each feature - didn't work
    const page = await browser.newPage();

    await page.goto(`https://caniuse.bitsofco.de/embed/index.html?feat=${features[i]}&screenshot=true`);

    screenshots.push({
        feature: feature,
        screenshot: await page.screenshot({ ... });
    });
}

await browser.close();
return screenshots;

Doesn't work

This didn’t work because, unsurprisingly, you can’t open 488 different pages on the browser. After about 12 pages, Puppeteer would crash. I was able to fix this by slightly changing this around and using the same page to navigate to the 488 different pages.

const features = [ ... ];
const browser = await puppeteer.launch({ ... });

// Open a single page for all features
const page = await browser.newPage();

const screenshots = [];

for (let i = 0; i < features.length; i++) {
    await page.goto(`https://caniuse.bitsofco.de/embed/index.html?feat=${features[i]}&screenshot=true`);

    screenshots.push({
        feature: feature,
        screenshot: await page.screenshot({ ... });
    });
}

await browser.close();
return screenshots;

Works!

Step 2: Upload 488 images to Cloudinary #

I have also covered how to upload images from Puppeteer to Cloudinary in a previous article, so I won’t go into that here again. Luckily, there was no issue uploading 488 images to Cloudinary in one go, so I didn’t have to make any special considerations there.

The only thing I had to make sure I did was to make the file name of the image the exact slug as used by caniuse.com. So, for example, the slug for CSS Grid is css-grid, and that’s the file name for the image too.

I also had to ensure that any new images with that same name will override the previous image, and not just create another image. To do this, I set the file name by setting the public_id in the options passed.

const options = {
    folder: 'caniuse-embed/all',
    public_id: feature
};

cloudinary.uploader.upload_stream(options, (error, result) => {
    if (error) reject(error)
    else resolve(result);
}).end(screenshot);

With both those things covered, I was able to capture and upload all 488 images!

One thing you may have noticed is that Cloudinary adds a version number in the URL of any uploaded image. For example, a newly uploaded image may have the following URL:

https://res.cloudinary.com/ireaderinokun/image/upload/v1574685647/caniuse-embed/all/css-grid.png

They do this to allow bypassing of a previously cached version of an image. So, if we upload an image with the exact same URL, Cloudinary can know which one to use. This, of course, presents a problem as I want to maintain the same URL for an image that will update. That’s where the next step comes in.

Step 3: Create URL redirects on Cloudflare #

This is the step that ties everything together. Because of the version numbers in the URL of Cloudinary images, I didn’t want users of the live image to use the Cloudinary image path directly. I wanted a middle-man that will allow me to control the exact path of the image used. And that’s where Cloudflare comes in.

With Cloudflare, we can create Page Rules which allow us to create complex redirect paths. The Page Rule I created looks like this:

If the URL matches: caniuse.bitsofco.de/image/*.*

Forward URL (302 - Temporary Redirect) to: res.cloudinary.com/ireaderinokun/image/upload/v1/caniuse-embed/all/$1.$2

The asterisks in the incoming URL are numbered according to their position, and can be used in the forwarding URL. So, the following URL:

https://caniuse.bitsofco.de/image/css-grid.png

Will redirect to:

https://res.cloudinary.com/ireaderinokun/image/upload/v1/caniuse-embed/all/css-grid.png

The version number on Cloudinary doesn’t actually have to be the same one that was given in the upload phase, so I can use any version number I like. I just need to make sure that I change it to a different version number every time I upload new images, so Cloudinary knows to override the cache.

To do this programatically, I made use of Cloudflare’s API. They have a pretty straightforward REST API for reading or updating existing page rules. For example, to get the page rules for a given site, we would make a GET request to the following URL:

https://api.cloudflare.com/client/v4/zones/ZONE_ID/pagerules

The ZONE_ID is the ID for the site, in my case my bitsofco.de site. So, getting the page rules for bitsofco.de would look like this:

const fetch = require('node-fetch');

const url = `https://api.cloudflare.com/client/v4/zones/BITSOFCODE_ZONE_ID_HERE/pagerules`;
const options = {
    headers: {
        'Content-Type': 'application/json',
        'X-Auth-Email': process.env.CLOUDFLARE_EMAIL,
        'X-Auth-Key': process.env.CLOUDFLARE_API_KEY
    }
};

fetch(url, options);

This will return something like this:

const pageRules = [{
    id: 'bfb990382de1cfadb25b0dec7c113b27',
    priority: 3,
    status: 'active',
    targets: [{
        target: 'url',
        constraint: {
            operator: 'matches',
            value: 'caniuse.bitsofco.de/image/*.*'
        }
    }],
    actions: [{
        id: 'forwarding_url',
        value: {
            url: 'https://res.cloudinary.com/ireaderinokun/image/upload/v1574685900077/caniuse-embed/all/$1.$2',
            status_code: 302
        }
    }]
}];

To update a given page rule, we make a PUT request to the following URL:

https://api.cloudflare.com/client/v4/zones/ZONE_ID/pagerules/RULE_ID

For example:

const pageRule = { /* original page rule */ };

const url = `https://api.cloudflare.com/client/v4/zones/BITSOFCODE_ZONE_ID_HERE/pagerules/bfb990382de1cfadb25b0dec7c113b27`;
const options = {
    method: 'PUT',
    headers: { ... },
    body: JSON.stringify({
        targets: pageRule.targets,
        actions: [{
            id: pageRule.actions[0].id,
            value: {
                /* use timestamp as version number */
                url: `https://res.cloudinary.com/ireaderinokun/image/upload/v${new Date().getTime()}/caniuse-embed/all/$1.$2`,
                status_code: 302
            }
        }]
    })
};

fetch(url, options);

So now, I can update the version number in the page rule immediately after I upload the new images.

Step 4: Deploy to Heroku and Schedule Daily Job #

Finally, I needed to set everything up on Heroku so the script could be run automatically and without needing to be on my machine. I didn’t need to make any changes to my code for it to run on Heroku, but I did need to install the following buildpacks:

Buildpack	Purpose
heroku/nodejs	Run Node
https://github.com/jontewks/puppeteer-heroku-buildpack.git	Puppeteer
https://github.com/ello/heroku-buildpack-imagemagick	For trimming the images to remove whitespace (I didn’t cover that in this article)

Then, I used Heroku Scheduler to schedule the script to run once each day.

And that's it! The entire project is hosted publicly on github at ireade/caniuse-embed-screenshot-api so you can see how everything works together.

I'm really happy with how it all turned out, especially being able to automate the whole process so I never need to manually do anything myself!

Highlights from Chrome Dev Summit 2019

2019-11-18T00:00:00Z

I’ve been going to Chrome Dev Summit for a couple of years now (2016 & 2018) and I always like to do this roundup article, highlighting what I thought were the most interesting ideas and projects from the conference. So let’s get into it!

HTML is (finally) getting some 💕 #

It seems like the design and functionality of pretty much all control elements have stayed the same since the dawn of the browser. This is true even despite the fact that the way we use browsers have changed a lot, for example with the shift to mobile. Well, no more! In the talk, HTML isn’t done, Nicole and Greg discussed a few updates that will be introduced to Chrome soon.

Redesigned form elements #

Several form elements are finally getting a visual refresh! Not only are the elements being designed to look more modern, but they are being designed with accessibility and mobile in mind. The date picker, for example, will now allow for larger touch targets when selecting values.

Extensibility of form elements #

Form elements are also getting more flexible! An example of this is the <select> element. So many of us end up using custom select components because we want to do something as simple as adding an icon to an option, or something as complex as allowing users to search through options. In future versions of Chrome, this should all be possible with the native <select> element itself!

New elements? #

Although this is more an improvement for the further-away future, the Chrome team are looking to add elements to the web that don’t exist yet. Elements like a table view similar to a UITableView in iOS, or a toggle switch element are in the pipeline.

CSS is getting better too! #

CSS is also getting some much-needed refinements. In their packed talk on Next-generation web styling, Una and Adam talked about 12 new features coming to CSS. Although there were many shiny features like Houdini mentioned, what had me really excited were the refinements that will allow us to write CSS more simply and effectively.

The `:is()` selector #

The :is() selector allows us to group multiple alike selectors. This is better explained with an example.

Typically, if we want to apply the same style to multiple elements that share a part of their selector, we would still have to write out the entire selector each time.

body.theme--light button,
body.theme--light a,
body.theme--light p,
body.theme--light h1 {
    /* ... */
}

With :is(), we can group the parts of the selectors that are different together.

body.theme--light :is(button, a, p, h1) {
    /* ... */
}

Amazing, right?!

Logical properties #

Logical properties are a move from CSS that is biased to left-to-right languages like English, to a more agnostic approach. Instead of thinking of the block model as top, right, bottom, left, it’s changing to block-start, inline-end, block-end, inline-start.

Credit: Una Kravets

This can be a little difficult to wrap your head around the first time, but once you get the hang of it, you see why it makes more sense. A lot of times, when we want a margin or a padding to the left, what we actually want is a margin/padding to the start of the inline block. With these logical properties, we can apply those kinds of styles that will adapt based on the language of the user. For times when left really means left, the directional properties are still there.

The web is coming for native #

Through the new Project Fugu, the Chromium team is aggressively trying to bridge the gap between the capabilities of web and native applications. There were two talks at the conference that really dove into the new APIs that are coming to the web.

In What’s new in sign-up and sign-in, Eiji talked about the new SMS Receiver API, which will allow browsers to access text messages received on the device to help auto-fill during the authentication process.

He also talked about the Web Authentication API, which will allow browsers to access local credential mechanisms such as FaceID. Using what is definitely the longest ever method name, we can check if one of these credentialm mechanisms are available:

PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()
    .then((available) => {
        // Proceed with authentication...
    });

In Bridging the native app gap, Sam discussed several other APIs coming to the web soon, including:

Web Share API
Web Share Target API
Contact Picker API
Native File System API

In the sandbox area, I also witnessed some amazing demos of APIs like WebXR, Web Bluetooth, and Web NFC.

WebAR demo at #ChromeDevSummit ! It's really amazing what can be done in the browser nowadays, the WebVR demo was so powerful too! pic.twitter.com/njrMyK0QeD — Ire Aderinokun (@ireaderinokun) November 11, 2019

Progressive enhancement through “adaptive loading” #

I’m always interested in the topic of progressive enhancement and how we can better serve appropriate experiences based on the user’s capabilities. Addy Osmani introduced a a concept he called “Adaptive Loading", which is the practice of adapting the experience for the user depending on their device/network/browser capabilities.

In order to create this adaptive experience, we can leverage several browser APIs that let us know what type of device/network/browser the user is currently on.

For example, with the Network Information API, we can determine if the user is on a 4g network, or if they have the data savings setting on.

const network = navigator.connection.effectiveType;
// => 4g

const isOnSaveData = navigator.connection.saveData;
// => true

It’s worth noting that the support for these features isn’t widely available yet. That said, they can still be used for extra information wherever available.

That's it for my roundup! All the videos from the conference are available to watch on YouTube on the Chrome Dev Summit 2019 playlist. What were your favourite talks?

How to use Puppeteer in a Netlify (AWS Lambda) function

2019-10-28T00:00:00Z

I recently gave a talk at JAMstack_conf San Francisco about how I used headless chrome (via Puppeteer) and Cloudinary to capture screenshots of my interactive caniuse embed. I did this to have a fallback image to use in case the embed couldn’t be loaded, for example in cases where Javascript couldn’t be run.

My talk, which you can watch on YouTube, focused on the code I wrote to capture the screenshot with Puppeteer and upload the screenshot to Cloudinary. Because it was just a 10-minute talk, I didn’t have time to go into where that server-side code was hosted, Netlify.

Using Puppeteer in a Netlify function requires some additional consideration, so in this article, I want to show a stripped down example of how to get everything working.

Puppeteer 101 #

Before getting into the Netlify portion of this, let’s briefly go over what we are trying to achieve with Puppeteer. In order to take a screenshot of a given URL with Puppeteer, we have to go through four steps:

Launch a new browser
Open a new page
Navigate to the given URL
Capture the screenshot

Here’s what that looks like:

const puppeteer = require('puppeteer');

(async () => {

    // 1. Launch a new browser
    const browser = await puppeteer.launch();

    // 2. Open a new page
    const page = await browser.newPage();

    // 3. Navigate to the given URL
    await page.goto('https://bitsofco.de');

	  // 4. Take screenshot
    const screenshot = await page.screenshot({encoding: 'binary'});

    await browser.close();
})();

From there, we can do whatever we like with the screenshot variable. If you’re interested in seeing how I went from this to Cloudinary, you can read my other article on how to upload a screenshot from Puppeteer to Cloudinary.

Netlify functions 101 #

Now onto Netlify functions. These are node functions that can be called from our frontend website. They give us the power of a backend server, without having to worry about actually creating and maintaining a fully blown API. All we have to do is create a function file, for example take-screenshot.js, and we can call that function by making a request to the URL /.netlify/functions/take-screenshot from our frontend.

Here’s what that looks like. First, we create the take-screenshot.js function file. This typically lives in a functions directory in the Netlify project.

functions/take-screenshot/take-screenshot.js

exports.handler = async (event, context) => {
    /* do stuff here */
}

The file exports one function, which is what is called when a request is made to the function. We have access to any arguments passed in the event variable. For example, if we were expecting a string, pageToScreenshot, which would define which URL of page to capture the screenshot of with cloudinary, we would be able to access that from the event.body.

functions/take-screenshot/take-screenshot.js

exports.handler = async (event, context) => {
    const params = JSON.parse(event.body);
    const pageToScreenshot = params.pageToScreenshot;
}

To call this function from our frontend, we just need to make a request to the special Netlify functions path, /.netlify/functions/take-screenshot. Note that the name of the function file is used in the URL.

public/script.js

const options = {
    method: "POST",
    headers: {
        "Content-Type": "application/json; charset=utf-8"
    },
    body: JSON.stringify({
        pageToScreenshot: "https://bitsofco.de"
    })
};

fetch("/.netlify/functions/take-screenshot", options);

Putting it all together #

Next, we need to put it all together. Although it should be as simple as moving the Puppeteer logic into the Netlify function file, there are a couple gotchas to be aware of.

Gotcha 1: Puppeteer vs Puppeteer Core #

Netlify functions have a maximum file size of 50MB. This means that we can’t actually use the full Puppeteer node library because it’s too large. Instead, we need to use puppeteer-core, which comes without any headless browser installed. Then we’ll need to add a lite version of chrome to use with it instead.

The two packages we need are puppeteer-core and chrome-aws-lambda.

functions/take-screenshot/take-screenshot.js

const puppeteer = require('puppeteer-core');
const chromium = require('chrome-aws-lambda');

We’ll also have to make a few changes to how we configure our browser. When launching the browser, we need to pass an executablePath option, so Puppeteer knows which browser to work with.

functions/take-screenshot/take-screenshot.js

const puppeteer = require('puppeteer-core');
const chromium = require('chrome-aws-lambda');

exports.handler = async (event, context) => {

    /* ... */

    const browser = await puppeteer.launch({
        // Required
        executablePath: await chromium.executablePath,

        // Optional
        args: chromium.args,
        defaultViewport: chromium.defaultViewport,
        headless: chromium.headless
    });
}

We can also pass some other optional confirmation options that the chromium package defines as shown above.

Gotcha 2: Local development #

Another thing to be aware of is that this probably won’t work locally. This is because, when working locally, the chromium.headless boolean will likely return false, which in turn means that chromium.executablePath will return null.

The best way I found to get around this is documented in the chrome-aws-lambda Wiki page. They suggest the following changes:

Install the full puppeteer package as a development dependency
Install puppeteer-core and chrome-aws-lambda as production dependencies
Access Puppeteer via the chromium package, which will determine which Puppeteer package to use

Here’s what that looks like. First, we install our packages.

npm install puppeteer --save-dev
npm install puppeteer-core chrome-aws-lambda --save-prod

Next, we access Puppeteer via the chromium package, which will determine which of the Puppeteer packages to use.

functions/take-screenshot/take-screenshot.js

const chromium = require('chrome-aws-lambda');

exports.handler = async (event, context) => {

    /* ... */

    const browser = await chromium.puppeteer.launch({ /* ... */ });
}

So even though we are installing and saving two different Puppeteer packages to our function project's package.json, we never directly access either package.

Putting it all together (again) #

Finally, we’re done! This is what the final take-screenshot.js function file looks like:

functions/take-screenshot/take-screenshot.js

const chromium = require('chrome-aws-lambda');

exports.handler = async (event, context) => {

    const pageToScreenshot = JSON.parse(event.body).pageToScreenshot;

    const browser = await chromium.puppeteer.launch({
        executablePath: await chromium.executablePath,
        args: chromium.args,
        defaultViewport: chromium.defaultViewport,
        headless: chromium.headless,
    });

    const page = await browser.newPage();

    await page.goto(pageToScreenshot);

    const screenshot = await page.screenshot({ encoding: 'binary' });

    await browser.close();

    return {
        statusCode: 200,
        body: JSON.stringify({
            message: `Complete screenshot of ${pageToScreenshot}`,
            buffer: screenshot
        })
    }

}

To illustrate how it all works, I put together a simple website to demo all of this.

You can visit the site at netlify-puppeteer-screenshot-demo.netlify.com and view the source code on GitHub.

Calling smart contract functions using web3.js - call() vs send()

2019-09-03T00:00:00Z

I’ve recently been doing Udacity’s Blockchain Developer Nanodegree, and the gotcha that has caused me the most wasted hours is the difference between calling a method in my smart contract using the call() vs send() web3.js methods.

Using web3.js to call smart contract functions #

Web3.js is a library that allows you to do a number of things related to developing for the ethereum ecosystem, including interacting with a smart contract from a frontend application.

Let’s say we have a simple smart contract that allows you to do just two things - get a string variable name, and set that name variable to a new string.

pragma solidity >=0.4.24;

contract NameContract {

    string private name = "Ire";

    function getName() public view returns (string)
    {
        return name;
    }

    function setName(string newName) public
    {
        name = newName;
    }

}

In order to interact with this smart contract via a frontend application, we would first initialise web3.js with the smart contract ABI and address.

import Web3 from 'web3';

const web3 = new Web3(window.ethereum);
await window.ethereum.enable();

const NameContract = web3.eth.Contract(contract_abi, contract_address);

Once initialised, we can call any of the methods of our smart contract using either the call() or send() methods.

NameContract.methods.getName().call();
NameContract.methods.setName("bitsofcode").send();

What’s the difference between `call()` and `send()`? #

The difference between the call() and send() methods has to do with the type of function they are calling and their effect. Solidity functions can be divided into two categories:

Functions that alter the state of the contract
Functions that do not alter the state of the contract

To make it clear which category a function belongs to, we can specify the function type.

contract MyContract {

    function myFunction () [visibility] [type] {
        // do something
    }

}

There are 4 function type keywords we can use, including leaving the function type unspecified.

&nsp;	Description	Alter's State?
`pure`	Doesn't read or write data	🚫
`view`	Reads, but doesn't write data	🚫
`payable`	Expecting payment of ether	✅
(unspecified)	Probably writes data	✅

Going back to my example contract, we can see that the function getName() has the type view which means it does not change the state of the contract. When calling this function via web3.js, we should use the call() method.

NameContract.methods.getName().call();

On the contrary, the setName() function doesn’t have a specified type and does change the state of the contract, in this case the value of the name variable. For these types of funtions, we should use the send() method.

NameContract.methods.setName("bitsofcode").send();

What’s the effect of `call()` vs `send()`? #

The reason we have two separate methods for calling functions that do or do not alter the state of a smart contract is because the former requires a transaction on the blockchain and the expense of ether in order to be effective.

The ether required to execute a smart contract function is called “gas” and it is a transaction that the user of the application will have to accept. If the user is using an ethereum wallet such as the Metamask plugin in their browser, they will have to accept the expense of the transaction via a popup window.

With functions called via the call() method on the other hand, they can happen silently in the background and do not require user input to complete.

&nsp;	Creates Transaction?	Alter's State?
`call()`	🚫	🚫
`send()`	✅	✅

What happens if you use the wrong method? #

The reason this difference is such a big gotcha is because there is no explicit warning if you are using the wrong method to call your smart contract function.

For example, if I were to use the call() method to execute the setName() function, I would get no warnings.

NameContract.methods.setName("bitsofcode").call();

Will not work

Ostensibly, the method would have successfully completed with no errors. However, if we were to query the name variable that is supposed to have changed, we will see that it was not changed.

NameContract.methods.getName().call(); // => "Ire"

NameContract.methods.setName("bitsofcode").call();

NameContract.methods.getName().call(); // => "Ire"

This is why I spent hours trying to debug why my function wasn't working, when in fact the problem was I was using the wrong method to call it!

Solidity function visibility, explained

2019-08-27T00:00:00Z

When writing a smart contract, we can control who/what can call functions within that contract by specifying what is known as the function visibility. This allows us to easily secure certain parts of a contract without having to write too much custom logic.

Who can call a smart contract function? #

Before getting into the different types of function visibility, it’s helpful to understand what the different categories of potential callers to a function are first.

There are three types of callers:

The main contract itself (MyContract)
A contract derived (i.e. inheriting) from the main contract (DerivedContract)
A third party (AnotherContract)

The visibility of a function determines what subset of these callers can legitimately execute the function.

Function visibility types #

The visibility of a smart contract function is specified using one of the four visibility keywords (private, internal, external, or public) and placed immediately following the function parameter list.

contract MyContract {

    function myFunction () [visibility-here] {
        // do something
    }

}

`private` #

A private function is one that can only be called by the main contract itself. Although it’s not the default, it is generally good practice to keep your functions private unless a scope with more visibility is needed.

`internal` #

An internal function can be called by the main contract itself, plus any derived contracts. As with private functions, it's generally a good idea to keep your functions internal wherever possible.

`external` #

An external function can only be called from a third party. It cannot be called from the main contract itself or any contracts derived from it.

External functions have the benefit that they can be more performant due to the fact that their arguments do not need to be copied to memory. So, where possible, it's advisable to keep logic that only needs to be accessed by an external party to an external function.

`public` #

Finally, a public function can be called from all potential parties. Unless otherwise specified, all functions are made public by default.

Your first performance budget with Lighthouse

2019-05-28T00:00:00Z

I asked on Twitter the other day how many people had created and enforced a performance budget for a website they were working on. Not surprisingly, the vast majority of people hadn't.

I'm curious, have you ever created (and enforced) a performance budget for a site you're working on? — Ire Aderinokun (@ireaderinokun) May 24, 2019

Until recently, I also hadn't setup an official performance budget and enforced it. This isn’t to say that I never did performance audits. I frequently use tools like PageSpeed Insights and take the feedback to make improvements. But what I had never done was set a list of metrics that I needed the site to meet, and enforce them using some automated tool.

The reasons for this were a combination of not knowing what exact numbers I should use for budgets as well as there being a disconnect between setting a budget and testing/enforcing it. This is why I was really excited when, at Google I/O this year, the Lighthouse team announced support for performance budgets that can be integrated with Lighthouse. We can now define a simple performance budget in a JSON file, which will be tested as part of the lighthouse audit!

The Lighthouse performance budget #

As we know, there are countless performance metrics out there. From user-centric milestones such as Time to Interactive, to resource-centric metrics such as the size of your javascript files.

The performance budget we can set on Lighthouse focuses on the latter and is purely based on the raw values of your website’s assets and resources. There are two types of budgets we can create:

The number of a given resource - e.g., a budget which enforces that only 2 javascript files be loaded by the given page
The size of a given resource - e.g., a budget which enforces that the given page only loads 500kb of javascript

Creating the `budget.json` #

Lighthouse expects the performance budget to be written in a JSON file, typically named budget.json.

The JSON file is setup as an array of objects, each object being a set of budgets for a single path. It should be noted that currently, Lighthouse only supports one set of budgets for one path, which means that the array in budgets.json should only have one object. However, the intention is that we'll be able to specify budgets for different paths in a single file, so it's setup this way for future proofing.

The main budget object is organised by budget type (resourceCounts or resourceSizes), each containing an array of budgets for each type of resource. For example, let’s create a budget.json that enforces the following budget -

10 third-party resources
300kb Javascript
100kb CSS

Here’s what the corresponding budget.json would look like:

[
  {
    "resourceCounts": [
      {"resourceType": "third-party","budget": 10}
    ],
    "resourceSizes": [
      {"resourceType": "script","budget": 300},
      {"resourceType": "stylesheet","budget": 100}
    ]
  }
]

The following resource types are available:

Resource type	Description
`document`	HTML documents
`script`	Javascript files
`stylesheet`	CSS files
`image`	Images
`media`	Other media
`font`	Webfonts
`other`	Any resources that don’t match the above, e.g. data transfers over Websocket connections
`third-party`	All resources from a third-party domain
`total`	All resources combined

Choosing a performance budget #

Now that we know how to create a performance budget, the next question is what should we put in it? Although the answer to this will change dramatically depending on the specifics of your site, you can use this Performance Budget Calculator to get an idea of what different budgets will mean for user-centric metrics such as time to interactive.

For the example, the default budget below will result in an estimated 4.4s time to interactive:

[
  {
    "resourceSizes": [
      {"resourceType":"document","budget":20},
      {"resourceType":"stylesheet","budget":50},
      {"resourceType":"font","budget":50},
      {"resourceType":"image","budget":300},
      {"resourceType":"script","budget":100}
    ]
  }
]

Enforcing the performance budget with Lighthouse #

At the moment, the performance budget can only be consumed by the Lighthouse CLI. This means that we can’t yet use it with the in-browser audit panel or online tools like PageSpeed Insights or Web.dev. These integrations are being worked on, but for now, there are primarily 2 ways you’ll want to use the Lighthouse performance budget.

Basic command line usage #

The simplest way is to install the Lighthouse CLI, and run the audit command, passing in your budget.json file as an option.

lighthouse [url] --budget-path=[path/to/budget.json]

For example:

lighthouse https://bitsofco.de --budget-path=budget.json

This command will trigger the lighthouse audit and will output the typical lighthouse results page with one addition - a section on how your page performs against your specified budgets.

Continuous integration #

Because the audits are available using the command line interface, they can be used wherever the CLI can be installed. This means we can include it in our continuous integration process.

There’s an excellent article on web.dev that shows how you can setup the Lighthouse Bot to run checks against GitHub Pull Requests.

Image from github.com/GoogleChromeLabs/lighthousebot

This is probably the best way to set things up so the checks happen automatically.

Removing duplicate objects from an Array (is hard)

2019-03-12T00:00:00Z

Let’s say we have an array of objects such as the following:

const books = [
    {
        name: "My Sister the Serial Killer",  
        author: "Oyinkan Braithwaite" 
    },
    {
        name: "Educated",  
        author: "Tara Westover" 
    },
    {
        name: "My Sister the Serial Killer",  
        author: "Oyinkan Braithwaite" 
    }
];

The first and the last objects in the array are identical. So what if we want to remove such duplicate objects from the array? Surprisingly, this is quite a difficult problem to solve. To understand why, let’s look at how we could remove duplicates from an Array of flat items, such as strings.

Removing duplicate flat items from an Array (is easy) #

Let’s say we had an Array of strings such as the following:

const strings = [
    "My Sister the Serial Killer", 
    "Educated", 
    "My Sister the Serial Killer"
];

If we wanted to remove any duplicates from this array, we could use the filter() method along with the indexOf() method to check if any given item is a duplicate.

const filteredStrings = strings.filter((item, index) => {

    // Return to new array if the index of the current item is the same 
    // as the first occurence of the item
    return strings.indexOf(item) === index;

});

Since strings.indexOf(item) will always return the index of the first occurrence of the item, we can tell if the current item within the filter loop is a duplicate. If it is, we don't return it to the new array created by the filter() method

Objects don’t work the same way #

The reason this same method doesn’t work with objects is because any 2 objects that have identical properties and values are not actually considered identical.

const a = {
    name: "My Sister the Serial Killer",  
    author: "Oyinkan Braithwaite" 
};
const b = {
    name: "My Sister the Serial Killer",  
    author: "Oyinkan Braithwaite" 
};

a === b // false

This is because objects are compared based on reference rather than structure. The fact that the two objects have the same orperties and values is not considered when comparing the two. Therefore, the indexOf(object) within an array of objects will always return the index of the exact object passed, even if there exists another object with the exact same properties and values.

My solution #

Given this information, the only way to check if two objects have the same properties and values is to actually check the properties and values of each object. The solution I came up with involved doing this manual check, but with some enhacements to improve performance and reduce unnecessary nested loops.

In particular, I did 3 things -

Only check each item in the array against every other item that comes after it in order to avoid comparing the same objects more than once
Only check items that have not been found to be a duplicate of any other item
Before checking if the values of each property are the same, check that both objects have the same keys

Here’s the final function:

function removeDuplicates(arr) {

    const result = [];
    const duplicatesIndices = [];

    // Loop through each item in the original array
    arr.forEach((current, index) => {
    
        if (duplicatesIndices.includes(index)) return;
    
        result.push(current);
    
        // Loop through each other item on array after the current one
        for (let comparisonIndex = index + 1; comparisonIndex < arr.length; comparisonIndex++) {
        
            const comparison = arr[comparisonIndex];
            const currentKeys = Object.keys(current);
            const comparisonKeys = Object.keys(comparison);
            
            // Check number of keys in objects
            if (currentKeys.length !== comparisonKeys.length) continue;
            
            // Check key names
            const currentKeysString = currentKeys.sort().join("").toLowerCase();
            const comparisonKeysString = comparisonKeys.sort().join("").toLowerCase();
            if (currentKeysString !== comparisonKeysString) continue;
            
            // Check values
            let valuesEqual = true;
            for (let i = 0; i < currentKeys.length; i++) {
                const key = currentKeys[i];
                if ( current[key] !== comparison[key] ) {
                    valuesEqual = false;
                    break;
                }
            }
            if (valuesEqual) duplicatesIndices.push(comparisonIndex);
            
        } // end for loop

    }); // end arr.forEach()
  
    return result;
}

Tips for making interactive elements accessible on mobile devices

2019-02-12T00:00:00Z

The Web Content Accessibility Guidelines (WCAG) is a set a guidelines for how to make websites accessible. The second version was published in 2008, before websites were available on mobile devices in any meaningful way.

A few months ago, the WCAG was updated to version 2.1, which includes a whole new section on guidelines for mobile accessibility. There are several new mobile-specific rules, such as rule 1.3.4, that “content should not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.”

In this article, I will cover some of the new guidelines that relate to interactive elements on a web page.

Place interactive elements where they can be easily accessed #

The first thing to consider with mobile devices is where any interactive/actionable elements are placed. Compared to the relatively rigid way we interact with desktop devices, mobile devices can be and are used in many different ways - one hand, two hands, left hand, right hand, etc.

Due to this dynamic handling of mobile devices, this guideline suggests to create interfaces that are flexible. For example, it may be easy to think that placing a call-to-action in the bottom right corner is best because most users may use their device with their right hand. However, this would be the most inconvenient place to put it for left-handed users. A better placement for a critical call-to-action could be spanning the entire width of the viewport.

Make it clear that an element is actionable #

Compared to desktop, it can be a bit more challenging to let a user know that an element is actionable on touchscreen devices. Without hover states, we have to use the upfront look of the element alone to convey that a user can interact with it.

The best way to convey that an element is actionable is by relying on convention and what actionable elements are expected to look like. For example, links are typically underlined and/or have a distinct colour from the body text and are usually a rectangular shape with rounded corners.

We can also use the position of an element to convey it’s use. The navigation, for example, is typically at the top of the page for conventional websites. For mobile devices, a navigation fixed to the bottom of the viewport is also common.

On Instagram desktop, the navigation is at the top of the page, whereas on mobile, it is in a bar at the bottom of the viewport

Provide instructions for custom gestures #

Following on from the previous guideline, it’s also more important on touchscreen devices to provide clear instructions on the gestures available.

A good example of this is the pull to refresh gesture. Unless there is some indication that this gesture is possible, users will never interact with it. On mobile twitter, they have an icon that pops up when the user scrolls to the top of the page, showing that there is an interaction available if they pull up more.

Scrolling up on a profile page on Twitter mobile will reveal an icon to pull to refresh

Provide a reasonable touch target size and spacing #

On touchscreen devices, the pointer is the user’s finger which, of course, is going to be a lot less precise that a mouse. Therefore, the area in which a user can tap to activate an interactive element needs to be big enough to accommodate different finger sizes.

According to guideline 2.5.5, actionable elements should generally have a size of at least 44px by 44px, unless the target element is inline within a block of text.

Group elements that perform the same action #

This guideline is best illustrated with an example. Let’s say we have a navigation link going to the website homepage, and beside it we also have a home icon. For layout purposes, we may want to separate the two elements and have two links going to the same place.

<a href="/"><img src="/home/png" alt="Home icon"></a>
<a href="/">Home</a>

Not advisable

This method has two main drawbacks:

It reduces the touch target space, since the space between the two links will not be clickable
It increases the number of elements that would need to be traversed through for a keyboard user. If navigating the page by tabbing on the keyboard, this duplication could become tedious if repeated numerous times

A better alternative would be to group both elements under the same interactive link.

<a href="/">
    <img src="/home/png" alt="Home icon">
    Home
</a>

Better!

This not only increases the touch target size for the link, it reduces the number of links that will need to be navigated through on the page.

Make typing easier with custom keyboard layouts #

One big hassle with touchscreen devices is typing on onscreen keyboards. We can make this a little easier by providing a custom keyboard layout that is specific to the type of input required.

For example, if a numeric input is required, we can use a number-only keyboard layout by specifying the type on the <input> element.

<label>
    How old are you?
    <input type="number">
</label>

In some cases, we need the type of the <input> element to be one thing, e.g. text, but we still want to restrict the keyboard layout to a numeric one. This can be achieved using the inputmode attribute, which allows us to specify what particular keyboard layout we want for the input, regardless of the input type.

<label>
    How old are you?
    <input type="text" inputmode="numeric">
</label>

At the time of writing, the inputmode attribute is not very well supported.

Provide alternatives to typing #

Another way to handle the hassle of typing on a touchscreen device is to reduce the amount of typing the user needs to do in the first place.

Generally speaking, on mobile devices, inputs such as checkboxes, radios, and selects are easier to work with on mobile than plain text boxes.

In places that need text entry, we can try to automatically fill out information. For example, by pulling location data to fill out addresses.

Revisiting the abbr element

2019-02-05T00:00:00Z

A few weeks ago, I wrote about how to make the abbr element work for touchscreen, keyboard, and mouse. My suggestion involved making the <abbr> element focusable with the tabindex attribute and using pseudo-elements to create a tooltip from the title attribute.

<abbr title="Cascading Style Sheets" tabindex="0">CSS</abbr>

abbr[title]:hover::after,
abbr[title]:focus::after {
  content: attr(title);

  /* more styles to position the elelent like a tooltip */
}

Since then, I’ve gotten some feedback on some accessibility-related issues to the implementation. Scott O’Hara in particular raised a lot of important concerns, which can be summarised in the following points:

It’s generally a bad idea to add tabindex to non-interactive elements for a few reasons:
1. It’s unexpected behaviour. Especially as there is no associated role, users of assistive technology may be left wondering why it is in the focus order since it’s not an interactive element.
2. If there are many instances of it, it makes navigating the DOM a pain for keyboard users as they have to traverse through each one.
3. Having focus move to the <abbr> element resulted in some awkward behaviour for users of the NVDA screen reader. With Firefox for instance, the content of the <abbr> would be would announced on first focus, but if re-navigating to an <abbr>, NVDA might not announce anything.
4. While not a popular pairing, IE11 and NVDA would go into forms mode when an <abbr> with a tabindex received focus.
There’s no acceptable way to dismiss the tooltip. Particularly on touch devices where the user would have to click on another focusable element. This would fail the new WCAG 1.4.13 rule.
There can be duplication of content for users of the JAWS screen reader who already have a setting to announce the title attribute of <abbr> elements.

With this feedback, I decided to revisit this and create a more accessible solution.

A quick aside - avoid tooltips! #

Before I go on to how I attempted to fix my original solution, it should be noted that, if all you want to use a tooltip for is to provide the full description of an abbreviation, you’re probably better off just providing it inline.

The first time an abbreviation is used, spell it out entirely.

<p>Cascading Style Sheets (<abbr>CSS</abbr>)</p>

Everywhere else in the document, you can use the <abbr> element as normal. Since the abbreviation has already been defined earlier in the document, the limitations of the native <abbr> element are not so harmful.

<p><abbr title="Cascading Style Sheets">CSS</abbr> is awesome.</p>

For most use cases, this is probably the simplest solution and provides an adequate experience for all users.

Enhancing the `abbr` element #

All of that said, here’s my attempt at enhancing the <abbr> element and creating a tooltip experience that works for touchscreen, keyboard, and mouse. This solution isn’t perfect, as I discuss below under the limitations, but I wanted to make an attempt anyway :)

Refactoring the markup #

One thing I gathered from the feedback was that the actual <abbr> element will never be acceptable to use if we want to create the experience of the tooltip. So, I needed to change the actual markup to look something more like this:

<span data-tooltip>
    <a href="#tt" aria-describedby="tt"><abbr>CSS</abbr></a>
    <span id="tt" role="tooltip" class="hidden">
        Cascading Style Sheets
    </span>
</span>

To start with, I changed the element that contains the abbreviation to a <a>, which links to the tooltip. I used an <a> element because I needed an element that was actually interactive, instead of applying tabindex to a non-interactive element.

Next, I made the tooltip itself an element within the HTML (as opposed to a CSS pseudo-element), and added the tooltip ARIA role so it’s clear what its purpose is. To comply with the tooltip requirements, I added an aria-describedby attribute that references the tooltip itself.

Handling events #

In order to make the tooltip usable by touchscreen, keyboard, and mouse users, I needed a lot of event listeners.

Event	Action	Input device
`mouseenter`	Show Tooltip	Mouse
`mouseleave`	Hide Tooltip	Mouse, Touchscreen
`keyup`	Show Tooltip	Keyboard
`keydown`	Hide Tooltip	Keyboard
`click`	Show Tooltip	Touchscreen

Besides the mouseenter and mouseleave events, I could listen for each of these events on the document and show/hide the tooltip depending on the element that triggered the event. For example, this is what the keyup event looks like.

document.addEventListener("keyup", (e) => {
  if (e.keyCode === 9 && e.target.parentElement.hasAttribute("data-tooltip")) {
    showTooltip(e.target.parentElement);
  }
});

To show or hide the tooltip, I simply toggled the .hidden class, which sets the display to none.

function showTooltip(tt) {
  tt.querySelector("[role='tooltip']").classList.remove("hidden");
}

function hideTooltip(tt) {
  tt.querySelector("[role='tooltip']").classList.add("hidden");
}

Progressive enhancement and automation #

Because the functionality of the tooltip requires Javascript to work, I wanted a case where the written markup would be a plain <abbr> element and, only if Javascript is enabled, would the element be changed to the refactored tooltip markup above.

So, I wrote a small script that would take a regular <abbr>, and change it to the markup required. Here’s what that script looks like -

const abbrs = Array.from(document.querySelectorAll("abbr[data-tooltip]"));

abbrs.forEach((abbr, index) => {

  const tooltipContainer = document.createElement("span");
  tooltipContainer.setAttribute("data-tooltip", "");
  tooltipContainer.innerHTML = `
    <a href="#tt-${index}" aria-describedby="tt-${index}">
        <abbr>${abbr.innerHTML}</abbr>
    </a>
    <span role="tooltip" id="tt-${index}" class="hidden">${abbr.getAttribute("title")}</span>
  `;

  abbr.parentElement.replaceChild(tooltipContainer, abbr);

  tooltipContainer.addEventListener("mouseenter", (e) => showTooltip(tooltipContainer));
  tooltipContainer.addEventListener("mouseleave", (e) => hideTooltip(tooltipContainer));
});

So, without Javascript enabled, my markup would simply look like this -

<abbr data-tooltip title="Cascading Style Sheets">CSS</abbr>

This is easy to write and maintain. If Javascript is enabled, the markup will be changed to the tooltip.

You can view the full project on CodePen to see how this works.

Limitations #

As I mentioned, this implementation isn’t without it’s limitations.

For example, using the <a> element here may not be the most semantic, as it is not really intended to be a link. I used the <a> because I wanted an element that was interactive, not because I wanted anyone to be able to link to the tooltip itself. There doesn't seem to be a widely-accepted implementation of tooltips at the moment, so I just went with what I thought was best given. An alternative to this would be to use a <button> instead, which will require specifying that it controls another element via the aria-controls attribute.

On the other hand, the fact that a link is used could be leveraged on to provide more useful information. For example, instead of linking to the tooltip itself, the link could go to a page with more information about the abbreviated word.

Additionally, breaking up the DOM into too many links / interactive elements is still a concern. Even if this tooltip were to be used, it should probably only be used for the very first instance of the abbreviation on the page.

What self.skipWaiting() does to the service worker lifecycle

2019-01-29T00:00:00Z

The ServiceWorker.skipWaiting() method is a life saver. It ensures that any new versions of a service worker will take over the page and become activated immediately.

To understand why this is so important and useful, we need to revisit the service worker lifecycle. I have a more detailed article about each step of the lifecycle, but you just need to know that there are six states that a service worker can be in - parsed, installing, installed (waiting), activating, activated, and redundant.

When we first try to register a service worker via navigator.serviceWorker.register(), the file passed is parsed and, assuming there are no errors, the service worker is installed. For a page with no previous service worker files, the newly installed service worker becomes activated immediately.

If, however, the page already has an activated service worker file, things are more complicated.

Endless waiting #

If the page already has an activated service worker and a new file is pushed, the new file will still be parsed and installed. Once installed, it will wait for an opportunity to become activated.

Without self.skipWaiting(), a waiting service worker will only become active itself once the currently active service worker is released and becomes redundant. This can only happen in two scenarios:

If the user has navigated away from the page, thereby releasing the previous active worker
If a specified period of time has passed, thereby releasing the previous active worker

So, unlike we are used to when pushing new versions of assets to our website, a new version of a service worker can be waiting for what seems like forever. Even if a user refreshes their page, they may not receive the updated version for a very long time.

`self.skipWaiting()` to the rescue! #

The ServiceWorker.skipWaiting() method solves this problem by telling the newly installed service worker to skip the waiting state and move directly to activating.

The self.skipWaiting() method is typically used in the install event of the service worker. As long as the method is called before the waiting phase itself, the service worker will skip the waiting phase and become immediately activated.

service-worker.js

self.addEventListener('install', function (event) {

    self.skipWaiting();

    event.waitUntil(
        // Do stuff
    );
});

What is tree shaking and how does it work?

2019-01-22T00:00:00Z

When Javascript applications get to a certain size, it’s helpful to separate the code into modules. However, when we do so, we can end up with code imported that isn’t actually used. Tree shaking is a method of optimising our code bundles by eliminating any code from the final file that isn’t actually being used.

Let’s say we have a utilities file with some math operations we may want to use in our main script.

mathUtils.js

export function add(a, b) {
    console.log("add");
    return a + b;
}

export function minus(a, b) {
    console.log("minus");
    return a - b;
}

export function multiply(a, b) {
    console.log("multiply");
    return a * b;
}

export function divide(a, b) {
    console.log("divide");
    return a / b;
}

In our main script, we may only ever import and use the add() function.

index.js

import { add } from "./mathUtils";

add(1, 2);

Assuming we are using a tool like webpack to create our bundle, we will see that all functions from the mathUtils.js file are included in the final bundle, even though we only imported and used the add() function.

bundle.js

/***/ "./src/mathUtils.js":
/*!**************************!*\
  !*** ./src/mathUtils.js ***!
  \**************************/
/*! exports provided: add, minus, multiply, divide */
/***/ (function(module, __webpack_exports__, __webpack_require__) {

"use strict";
eval("__webpack_require__.r(__webpack_exports__);\n/* harmony export (binding) */ __webpack_require__.d(__webpack_exports__, \"add\", function() { return add; });\n/* harmony export (binding) */ __webpack_require__.d(__webpack_exports__, \"minus\", function() { return minus; });\n/* harmony export (binding) */ __webpack_require__.d(__webpack_exports__, \"multiply\", function() { return multiply; });\n/* harmony export (binding) */ __webpack_require__.d(__webpack_exports__, \"divide\", function() { return divide; });\nfunction add(a, b) {\n    console.log(\"add\");\n    return a + b;\n}\n\nfunction minus(a, b) {\n    console.log(\"minus\");\n    return a - b;\n}\n\nfunction multiply(a, b) {\n    console.log(\"multiply\");\n    return a * b;\n}\n\nfunction divide(a, b) {\n    console.log(\"divide\");\n    return a / b;\n}\n\n\n//# sourceURL=webpack:///./src/mathUtils.js?");

/***/ })

With tree shaking enabled, only what is imported and actually used will make it to the final bundle.

How does tree shaking work? #

Although the concept of tree shaking has been around since at least the 1990s, it has only been able to work with Javascript since the introduction of ES6-style modules. This is because tree shaking can only work if the modules are "static".

Before ES6 modules, we had CommonJS modules which used the require() syntax. These modules were "dynamic", meaning that we could import new modules based on conditions in our code.

var myDynamicModule;

if (condition) {
    myDynamicModule = require("foo");
} else {
    myDynamicModule = require("bar");
}

This dynamic nature of the CommonJS modules meant that tree shaking couldn’t be applied because it would be impossible to determine which modules will be needed before the code is actually run.

In ES6, a new syntax for modules was introduced, which was entirely static. Using the import syntax, we can no longer dynamically import a module.

if (condition) {
    import foo from "foo";
} else {
    import bar from "bar";
}

Doesn't work

Instead, we have to define all imports in the global scope, outside of any conditions.

import foo from "foo";
import bar from "bar";

if (condition) {
    // do stuff with foo
} else {
    // do stuff with bar
}

Among other benefits, this new syntax allows for effective tree shaking, as any code that is used from an import can be determined without the code needing to be first run.

What does tree shaking shake off? #

Tree shaking, at least webpack's implementation of the feature, is pretty good at eliminating as much unused code as possible. For example, imports that are import-ed but not used are eliminated.

import { add, multiply } from "./mathUtils";

add(1, 2);

In the above example, the multiply() function is never used and will be removed from the final bundle.

Even specific properties from imported objects that are never accessed are removed.

myInfo.js

export const myInfo = {
    name: "Ire Aderinokun",
    birthday: "2 March"
}

index.js

import { myInfo } from "./myInfo.js";

console.log(myInfo.name);

In the above example, the birthday property never makes it to the final bundle because it is never actually used.

However, tree shaking doesn’t eliminate all unused code. The details of what is and isn’t eliminated is beyond the scope of this article, but it should be noted that the use of tree shaking doesn’t solve the problem of unused code entirely.

What about "side effects"? #

A side effect is code that performs some action when imported, not necessarily related to any export. A good example of a side effect is a polyfill. Polyfills typically don’t provide an export to be used in the main script, but rather add to the project as a whole.

Tree shaking can’t automatically tell which scripts are side effects, so it’s important to specify them manually, as we will see below.

How to tree shake #

Tree shaking is typically implemented via a code bundler. If you’re using webpack, for example, you can simply set the mode to production in your webpack.config.js configuration file. This will, among other optimisations, enable tree shaking.

module.exports = {
    ...,
    mode: "production",
    ...,
};

To mark certain files as side effects, we need to add them to our package.json file.

{
    ...,
    "sideEffects": [
        "./src/polyfill.js"
    ],
    ...,
}

For more information on how to implement tree shaking using webpack, check out their documentation.

Use the :lang pseudo-class over the lang attribute selector for language-specific styles

2019-01-16T00:00:00Z

The content of HTML documents can be in many different languages. To specify the primary language of a document, we use the lang attribute on the root element.

<html lang="en">

We can also use the lang attribute within the page to demarcate specific elements or sections that are in a different language to the document’s primary language.

<html lang="en">
<head></head>
<body>
    <section lang="fr">
        <p>Comment dites-vous "Bonjour" en Espanol?</p>
    </section>
</body>
</html>

If we wanted to style these sections of the page differently, we could use the [lang] attribute selector to select all elements, or children of elements, with the specific language attribute.

[lang="fr"] p {
    background-color: #002295;
    color: #fff;
}

The `[lang]` attribute selector doesn’t know the element’s language #

The problem with having language-specific styles based on the [lang] attribute selector is that the selector isn’t actually aware of the language of the element. It’s just like any other “dumb” attribute selector.

This can become a problem if we have a document with multiple, nested elements of different languages. Let’s take this section below. The section has a French lang attribute but, within the section, we have a quote in Spanish.

<section lang="fr">
    <p>Comment dites-vous "Bonjour" en Espanol?</p>
    <blockquote lang="es">
        <p>Hola!</p>
    </blockquote>
</section>

In our CSS, we may have simply styled all elements with a particular lang attribute and its descendants.

[lang="es"] p {
  background-color: yellow;
  color: #000;
}

[lang="fr"] p {
    background-color: blue;
    color: #fff;
}

CSS has no concept of prioritising closer parents, so it doesn’t matter that the Spanish lang attribute is closer to the block quote paragraph element than the French one. Both of these styles are equally applicable. Because the style of the French language happened to be declared later in the CSS file, it prevails, even though, looking at the markup, we would have wanted the Spanish style to be used.

The `:lang` pseudo-class #

The :lang pseudo-class provides a solution to the limitations of styling the lang attribute in two ways:

It uses the actual language of the element selected
It can be applied to any element and is not directly based on the lang attribute

`:lang` and the "content language" #

The :lang pseudo-class is used to select an element based on its content language. The content language of an element is determined by a combination of three things:

Any lang attributes
Meta tags, e.g. <meta http-equiv="content-language" content="en">
HTTP headers, e.g. Content-language: en

This means that the :lang pseudo-class can be used even in cases where no lang attribute is specified.

`:lang` and nesting #

Being a pseudo-class, :lang is best used on specific elements rather than on children.

Using the same example as above, we can switch to using the :lang() attribute to select the paragraph elements. But instead of selecting the child paragraph elements of the specified languages, we can select the paragraph elements that are themselves of the specified language.

p:lang(es) {
  background-color: yellow;
  color: #000;
}

p:lang(fr) {
    background-color: blue;
    color: #fff;
}

Even though there is no lang attribute on the paragraph elements themselves, we are still able to use the pseudo-class because the content language of the paragraph is inherited from its parent.

As we can see, the correct colours are applied to each paragraph.

A Siri Shortcut to Generate PWA Icons and Web App Manifest

2018-12-25T00:00:00Z

If you've been following along with my daily blogging challenge, this is my final article! I've done 30 articles in 42 days!

Since Siri Shortcuts were announced in iOS 12, I’ve been trying to find some interesting and useful applications for it. Suprisingly, it packs a lot of power and is actually a great automation tool. In addition to being able to run actual scripts, we can do things image manipulation, which gave me the idea of creating a shortcut to automate the generation of the different icon sizes for progressive web applications.

Using the shortcut #

To use the shortcut, all you need to do is pass in the name of the application and the original icon file. Here's what that looks like:

The shortcut will generate icons in sizes 32px, 48px, 128px, 144px, 152px, 192px, 256px, and 512px. Additionally, a basic manifest.json file is generated along with a head.html file with <link>s to all the icons.

manifest.json

{
    "name": "bitsofcode",
    "start_url": "/",
    "scope": "/",
    "display": "standalone",
    "background_color": "#fff",
    "icons": [
        {
            "src": "/icon-32.png",
            "sizes": "32x32",
            "type": "image/png"
        },
        {
            "src": "/icon-48.png",
            "sizes": "48x48",
            "type": "image/png"
        },
        {
            "src": "/icon-128.png",
            "sizes": "128x128",
            "type": "image/png"
        },
        {
            "src": "/icon-144.png",
            "sizes": "144x144",
            "type": "image/png"
        },
        {
            "src": "/icon-152.png",
            "sizes": "152x152",
            "type": "image/png"
        },
        {
            "src": "/icon-192.png",
            "sizes": "192x192",
            "type": "image/png"
        },
        {
            "src": "/icon-256.png",
            "sizes": "256x256",
            "type": "image/png"
        },
        {
            "src": "/icon-512.png",
            "sizes": "512x512",
            "type": "image/png"
        }
    ]
}

head.html

<head>
    <title>bitsofcode</title>
    <link rel="manifest" href="/manifest.json">
    <link rel="icon" type="image/png" sizes="32x32" href="/icon-32.png">
    <link rel="icon" type="image/png" sizes="48x48" href="/icon-48.png">
    <link rel="icon" type="image/png" sizes="128x128" href="/icon-128.png">
    <link rel="icon" type="image/png" sizes="144x144" href="/icon-144.png">
    <link rel="icon" type="image/png" sizes="152x152" href="/icon-152.png">
    <link rel="icon" type="image/png" sizes="192x192" href="/icon-192.png">
    <link rel="icon" type="image/png" sizes="256x256" href="/icon-256.png">
    <link rel="icon" type="image/png" sizes="512x512" href="/icon-512.png">
    <meta name="apple-touch-icon" sizes="152x152" href="/icon-152.png">
    <meta name="msapplication-TileImage" sizes="144x144" href="/icon-144.png">
</head>

Breaking it down #

The syntax of Siri Shortcuts can take a while to get used to, but it is actually quite similar to regular code. We can have variables, if/else statements, loops, and even structured data like arrays and objects.

You can view an image of the full shortcut here, but here is a breakdown of each step and what it does.

Get application name #

The first thing I do is prompt the user for the name of the application and save it to the Application Full Name variable. I use this variable to name the folder that the resulting icons and files are stored to, as well as to fill in the name in the web app manifest.

Get full-sized icon #

Next, I prompt the user to select an image from the Photos library, which will be used to generate the different icon sizes needed. I save the image to the Image variable and the image file extension to the Image Extension variable.

I also check if the image selected is square. If not, I show an alert to the user warning that the icon will be distorted and asking if they want to continue.

In the future, I plan to add more checks to the image such as making sure the image format is appropriate and the size is at least 512px.

Prepping the directory, manifest file, and head file #

Next, I create the directory that the files will be stored in and save it to the Folder variable. The directory is named after the application name.

Then, I start the files that will become the head.html and the manifest.json. As the shortcut progresses, more will be added to these files.

Generating the icons #

Next is to generate the different icon sizes. I start by creating a Dictionary with an icon_sizes array. This array contains all the icon sizes that we want to generate.

Referencing the Image that was selected by the user, I loop through each icon size and resize the image to whichever size we are currently on in the loop (Repeat Item variable).

In addition to resizing the image, I also add to the head.html and manifest.json files with the icon details.

Completing the head.html and manifest.json #

Finally, I complete the head.html and manifest.json files and save them to the same directory.

Get the shortcut #

If you want to use the shortcut yourself, you can download the shortcut here.

Understanding the Virtual DOM

2018-12-24T00:00:00Z

I’ve recently been writing about what exactly the DOM and the shadow DOM are and how they differ. To recap, the Document Object Model is an object-based representation of an HTML document and an interface to manipulating that object. The shadow DOM can be thought of as a “lite” version of the DOM. It is also an object-based representation of HTML elements, but not of a full standalone document. Instead, the shadow DOM allows us to separate our DOM into smaller, encapsulated bits that can be used across HTML documents.

Another similar term you may have come across is the “virtual DOM”. Although the concept has been around for several years, it was made more popular by its use in the React framework. In this article, I will cover exactly what the virtual DOM is, how it differs from the original DOM, and how it is used.

Why do we need a virtual DOM? #

To understand why the concept of the virtual DOM arose, let’s revisit the original DOM. As I mentioned, there are two parts to the DOM - the object-based representation of the HTML document and the API to manipulating that object.

For example, let’s take this simple HTML document with an unordered list and one list item.

<!doctype html>
<html lang="en">
 <head></head>
 <body>
    <ul class="list">
        <li class="list__item">List item</li>
    </ul>
  </body>
</html>

This document can be represented as the following DOM tree:

html
- head lang="en"
- body
  - ul class="list"
    - li class="list__item"
      - "List item"

Let’s say we want to modify the content of the first list item to "List item one" and also add a second list item. To do this, we will need use the DOM APIs to find the elements we want to update, create the new elements, add attributes and content, then finally update the DOM elements themselves.

const listItemOne = document.getElementsByClassName("list__item")[0];
listItemOne.textContent = "List item one";

const list = document.getElementsByClassName("list")[0];
const listItemTwo = document.createElement("li");
listItemTwo.classList.add("list__item");
listItemTwo.textContent = "List item two";
list.appendChild(listItemTwo);

The DOM wasn’t made for this… #

When the first specification for the DOM was released in 1998, we built and managed web pages in very differently. There was far less reliance on the DOM APIs to create and update the page content as frequently as we do today.

Simple methods such as document.getElementsByClassName() are fine to use on a small scale, but if we are updating multiple elements on a page every few seconds, it can start to become really expensive to constantly query and update the DOM.

Even further, because of the way the APIs are setup, it is usually simpler to perform more expensive operations where we update larger parts of the document than to find and update the specific elements. Going back to our list example, it is in some ways easier to replace the entire unordered list with a new one than to modify the specific elements.

const list = document.getElementsByClassName("list")[0];
list.innerHTML = `
<li class="list__item">List item one</li>
<li class="list__item">List item two</li>
`;

In this particular example, the performance difference between the methods is probably insignificant. However, as the size of the web page grows, it becomes more important to only select and update what is needed.

… but the virtual DOM was! #

The virtual DOM was created to solve these problems of needing to frequently update the DOM in a more performant way. Unlike the DOM or the shadow DOM, the virtual DOM isn't an official specification, but rather a new method of interfacing with the DOM.

A virtual DOM can be thought of as a copy of the original DOM. This copy can be frequently manipulated and updated, without using the DOM APIs. Once all the updates have been made to the virtual DOM, we can look at what specific changes need to be made to the original DOM and make them in a targetted and optimised way.

What does a virtual DOM look like? #

The name "virtual DOM" tends to add to the mystery of what the concept actually is. In fact, a virtual DOM is just a regular Javascript object.

Let’s revisit the DOM tree we created earlier:

html
- head lang="en"
- body
  - ul class="list"
    - li class="list__item"
      - "List item"

This tree can also be represented as a Javascript object.

const vdom = {
    tagName: "html",
    children: [
        { tagName: "head" },
        {
            tagName: "body",
            children: [
                {
                    tagName: "ul",
                    attributes: { "class": "list" },
                    children: [
                        {
                            tagName: "li",
                            attributes: { "class": "list__item" },
                            textContent: "List item"
                        } // end li
                    ]
                } // end ul
            ]
        } // end body
    ]
} // end html

We can think of this object as our virtual DOM. Like the original DOM, it is an object-based representation of our HTML document. But since it is a plain Javascript object, we can manipulate it freely and frequently without touching the actual DOM until we need to.

Instead of using one object for the entire object, it is more common to work with small sections of the virtual DOM. For example, we may work on a list component, which would corespond to our unordered list element.

const list = {
    tagName: "ul",
    attributes: { "class": "list" },
    children: [
        {
            tagName: "li",
            attributes: { "class": "list__item" },
            textContent: "List item"
        }
    ]
};

Under the hood of the virtual DOM #

Now that we’ve seen what a virtual DOM looks like, how does it work to solve the performance and usability problems of the DOM?

As I mentioned, we can use the virtual DOM to single out the specific changes that need to be made to the DOM and make those specific updates alone. Let's go back to our unordered list example and make the same changes we did using the DOM API.

The first thing we would do is make a copy of the virtual DOM, containing the changes we want to make. Since we don't need to use the DOM APIs, we can actually just create a new object alltogether.

const copy = {
    tagName: "ul",
    attributes: { "class": "list" },
    children: [
        {
            tagName: "li",
            attributes: { "class": "list__item" },
            textContent: "List item one"
        },
        {
            tagName: "li",
            attributes: { "class": "list__item" },
            textContent: "List item two"
        }
    ]
};

This copy is used to create what is called a “diff” between the original virtual DOM, in this case the list, and the updated one. A diff could look something like this:

const diffs = [
    {
        newNode: { /* new version of list item one */ },
        oldNode: { /* original version of list item one */ },
        index: /* index of element in parent's list of child nodes */
    },
    {
        newNode: { /* list item two */ },
        index: { /* */ }
    }
]

This diff provides instructions for how to update the actual DOM. Once all the diffs are collected, we can batch changes to the DOM, making only the updates that are needed.

For example we could loop through each diff and either add a new child or update an old one depending on what the diff specifies.

const domElement = document.getElementsByClassName("list")[0];

diffs.forEach((diff) => {

    const newElement = document.createElement(diff.newNode.tagName);
    /* Add attributes ... */

    if (diff.oldNode) {
        // If there is an old version, replace it with the new version
        domElement.replaceChild(diff.newNode, diff.index);
    } else {
        // If no old version exists, create a new node
        domElement.appendChild(diff.newNode);
    }
})

Note that this is a really simplified and stripped-back version of how a virtual DOM could work and there are lot of cases I didn't cover here.

The virtual DOM and frameworks #

It's more common to work with the virtual DOM via a framework, rather than interfacing with it directly as I showed in the example above.

Frameworks such as React and Vue use the virtual DOM concept to make more performant updates to the DOM. For example, our list component can be written in React in the following way.

import React from 'react';
import ReactDOM from 'react-dom';

const list = React.createElement("ul", { className: "list" },
    React.createElement("li", { className: "list__item" }, "List item")
);

ReactDOM.render(list, document.body);

If we wanted to update our list, we could just rewrite the entire list template, and call ReactDOM.render() again, passing in the new list.

const newList = React.createElement("ul", { className: "list" },
    React.createElement("li", { className: "list__item" }, "List item one"),
    React.createElement("li", { className: "list__item" }, "List item two");
);

setTimeout(() => ReactDOM.render(newList, document.body), 5000);

Because React uses the virtual DOM, even though we are re-rendering the entire template, only the parts that actually change are updated. If we look at our developer tools when the change happens, we will see the specific elements and the specific parts of the elements that change.

The DOM vs the virtual DOM #

To recap, the virtual DOM is a tool that enables us to interface with DOM elements in an easier and more performant way. It is a Javascript object representation of the DOM, which we can modify as frequently as we need to. Changes made to this object are then collated, and modifications to the actual DOM are targetted and made less often.

My CSS Reset/Base

2018-12-21T00:00:00Z

Since writing about the state of CSS resets in 2018, I’ve had a few people ask what my modified CSS reset looks like. As I mentioned in that article, my reset is more like a base at this point because, in addition to resetting some default browser styles, I also include some utilities that I want in every project.

You can view the entire CSS file in my Github repository, which will be kept more up to date, but here is an explanation of everything I’ve included at the time of writing.

A warning, this is very opinionated. I’m writing about this to share my personal preferences and not arguing that anyone else should work the way I do. That said, I’m interested to hear what you think and how you reset/base your projects, so do leave a comment below.

Resetting margins, paddings, and borders #

html, body,
h1, h2, h3, h4, h5, h6,
a, p, span,
em, small, strong,
sub, sup,
mark, del, ins, strike,
abbr, dfn,
blockquote, q, cite,
code, pre,
ol, ul, li, dl, dt, dd,
div, section, article,
main, aside, nav,
header, hgroup, footer,
img, figure, figcaption,
address, time,
audio, video,
canvas, iframe,
details, summary,
fieldset, form, label, legend,
table, caption,
tbody, tfoot, thead,
tr, th, td {
    margin: 0;
    padding: 0;
    border: 0;
}

The first thing I always do is remove the margin, padding, and border on all elements besides the form fields. This is largely taken from Meyer’s CSS Reset with two modifications.

The first modification is that I only included the selectors of elements I'm likely to still use. For example, I removed deprecated elements such as menu, but I also didn't include valid elements I never need to use, such as the ruby element.

The second modification is that I moved the resetting of the font styles to another selector, as you'll see below.

Typography #

html {
    font-size: 62.5%;
}

body {
    font-size: 1.6rem;
    line-height: 1.4;
}

* {
    font-family: inherit;
    font-size: inherit;
    line-height: inherit;
}

a,
a:visited {
    color: inherit;
}

I’m still partial to the method of setting 62.5% font-size on the html element then using the rem unit everywhere else. I don’t have a strong reason for doing it this way, it’s more inertia at this point for me.

I also reset the font-family, font-size, and line-height on every element to inherit from its parent. This is pretty opinionated and is actually a new addition to my reset file. I do it this way because, generally speaking, I want to be proactive about setting any font styles that are different from the paragraph elements. Also, it’s really handy for the form elements like input or button to already be styled like the default body text. Using the default Meyer Reset, I always had to style the font of these elements separately.

Finally, I generally prefer the link colour to be the same as the body text so I set that to inherit as well.

Layout & box sizing #

article,
aside,
footer,
header,
nav,
section,
main {
    display: block;
}

* {
    box-sizing: border-box;
}

*:before,
*:after {
    box-sizing: inherit;
}

Here, I set the correct display on the HTML5 elements and set the box-sizing on all elements to border-box.

Resetting specific element styles #

table {
    border-collapse: collapse;
    border-spacing: 0;
}

ol,
ul {
    list-style: none;
}

img,
video {
    max-width: 100%;
}

img {
    border-style: none;
}

blockquote,
q {
    quotes: none;
}

blockquote:after,
blockquote:before,
q:after,
q:before {
    content: "";
    content: none;
}

In this section, I target specific elements and undo some of the styling that the browsers add by default. Most of this is pretty standard for CSS resets.

Attributes & states #

[hidden] {
    display: none !important;
}

[disabled] {
    cursor: not-allowed;
}

:focus:not(:focus-visible) {
    outline: none;
}

Next, I handle the styling for certain HTML attributes or states.

Any element with the hidden attribute should not be visible.

Setting the cursor to not-allowed for disabled elements is a style I personally like to add to all projects.

The :focus:not(:focus-visible) selector allows me to remove the outline in cases where the browser has deemed that the focus does not need to be visible. For browsers that don’t yet support the :focus-visible pseudo-class, the entire rule is ignored and the outline remains as normal.

.sr-only {
    position: absolute;
    clip: rect(1px, 1px, 1px, 1px);
    left: -9999px;
    top: -9999px;
}

Finally, I always add this sr-only utility class. I add this to HTML elements that should remain in the document, but should be visually hidden.

What’s in your CSS reset/base? #

I wouls really love to see what you include in your CSS reset or base, if you have a custom one. Feel free to write your own article and comment the link below!

Making the abbr element work for touchscreen, keyboard, and mouse

2018-12-20T00:00:00Z

The <abbr> element is used to denote and define an acronym. For example, if we want to write the acronym “CSS” anywhere on a web page, we can also provide the full name “Cascading Style Sheets” for readers unfamiliar with the acronym.

This is done by wrapping the acronym in an <abbr> element and adding the full definition in a title attribute.

<abbr title="Cascading Style Sheets">CSS</abbr>

If a user hovers their mouse over the acronym, the full definition is displayed in a native browser tooltip.

The problem(s) with the `abbr` element #

The <abbr> element works well enough on desktop devices as long as the user is interacting with a pointing device. However, it fails for users who are interacting with the page via the keyboard or a touchscreen device. This is because of two things:

The <abbr> element isn’t able to be brought into focus, e.g. by a keyboard user pressing the tab key
Mobile browsers don’t display the tooltip on any interaction from the user

Additionally, I’ve always thought the delay before the native browser tooltip shows up was too long. It takes about 2 seconds, which is really slow compared to most other interactions on the web.

Fixing the `abbr` element #

These issues can be fixed by modifying the HTML and adding some custom styles to re-implement the native browser tooltip in a more effective way.

Enabling focus #

The first thing we need to do is allow the <abbr> element to be brought into focus to enable keyboard users to interact with it. We can do this by adding the tabindex attribute to the element.

<abbr title="Cascading Style Sheets" tabindex="0">CSS</abbr>

A tabindex value of 0 will place the element in the default focus order as determined by the element’s position in the HTML document.

Displaying the `title` element #

Next, we need a way to display the contents of the title element to the user. This can be done by using the attr() function, which allows us to retrieve and use the contents of any element’s attribute as a CSS value.

For example, we can take the title of the <abbr> and display it immediately after the element in an ::after pseudo-element.

abbr[title]::after {
  content: attr(title);
}

Although we can leave it at displaying the title of the <abbr> element immediately after it, our goal here is to recreate a tooltip. So, instead of just plainly displaying the title by default, we can wait for the user interaction we want first.

In order to have the custom tooltip display in the three scenarios we want - mouse hover, keyboard focus, or finger tap - we need to combine the display of the pseudo-element with both the :hover and :focus pseudo-classes.

abbr[title]:hover::after,
abbr[title]:focus::after {
  content: attr(title);
}

The :hover pseudo-class takes care of when the user hovers over the device with a mouse, but also when the user taps on the element on a touchscreen device. Additionally, unlike the :focus or :active pseudo-classes, the :hover pseudo-class works on all mobile browsers, including mobile Safari.

The :focus pseudo-class takes care of when the user brings the element into focus via their keyboard. With the tabindex attribute we added, this is now possible for users to do.

Finally, we can add more styles to make the tooltip appear as a tooltip, and not just as text next to the element.

abbr[title] {
  position: relative;

  /* ensure consistent styling across browsers */
  text-decoration: underline dotted;
}

abbr[title]:hover::after,
abbr[title]:focus::after {
  content: attr(title);

  /* position tooltip like the native one */
  position: absolute;
  left: 0;
  bottom: -30px;
  width: auto;
  white-space: nowrap;

  /* style tooltip */
  background-color: #1e1e1e;
  color: #fff;
  border-radius: 3px;
  box-shadow: 1px 1px 5px 0 rgba(0,0,0,0.4);
  font-size: 14px;
  padding: 3px 5px;
}

And that’s it! Here's what it would look like when active:

You can also checkout the codepen I created to demo this.

Handling broken images with the service worker

2018-12-19T00:00:00Z

A few years ago, I wrote about how we can use css to style broken images. The technique leveraged on the fact that any styling to the ::before or ::after pseudo-elements on the <img> element will only be applied if the image doesn’t load. So, we could style those elements and they would only display if the image was broken.

Here’s an example of how I’ve styled broken images on this site:

There are pros and cons to handling broken images this way. One limitation is browser support, as this technique doesn’t work in some major browsers like Safari.

Having recently done a lot of work with service workers, it occurred to me that we could use the service worker to handle broken images in a different way. Since the service worker can tell if an image file isn’t able to be fetched, we can handle that condition by, for example, serving a different image to the browser.

Intercepting requests for broken images #

In the service worker fetch event, we can tell if and when a request the browser makes goes wrong, whether that be because the user is offline or because the response to the fetch request was bad.

self.addEventListener('fetch', (e) => {
    e.respondWith(
        fetch(e.request)
            .then((response) => {
                if (response.ok) return response;

                // User is online, but response was not ok

            })
            .catch((err) => {

                // User is probably offline

            })
    )
});

In either of these scenarios, we can check to see if the failed request was for an image and do whatever we like in response.

function isImage(fetchRequest) {
    return fetchRequest.method === "GET"
           && fetchRequest.destination === "image";
}

self.addEventListener('fetch', (e) => {
    e.respondWith(
        fetch(e.request)
            .then((response) => {
                if (response.ok) return response;

                // User is online, but response was not ok
                if (isImage(e.request)) {
                    // do something
                }

            })
            .catch((err) => {

                // User is probably offline
                if (isImage(e.request)) {
                    // do something
                }

            })
    )
});

Serving a “broken image” image #

One way to handle requests for images that don’t resolve would be to send a placeholder image in its place. For example, we can have an image like the one below to show the user that the image is broken.

We can implement this by responding to the fetch request with a new request for the palceholder file, /broken.png.

self.addEventListener('fetch', (e) => {
    e.respondWith(
        fetch(e.request)
            .then((response) => {
                if (response.ok) return response;

                // User is online, but response was not ok
                if (isImage(e.request)) {
                    // Fetch the broken image placeholder instead
                    return fetch("/broken.png");
                }

            })
            .catch((err) => {

                // User is probably offline
                if (isImage(e.request)) {
                    // do something
                }

            }) // end fetch
    )
});

This will work when the user is online, but if we want this to also work offline, we will need to cache the placeholder image. This is typically done during the install phase of the service worker lifecycle.

self.addEventListener('install', (e) => {
    self.skipWaiting();
    e.waitUntil(
        caches.open("precache").then((cache) => {

            // Add /broken.png to "precache"
            cache.add("/broken.png");

        })
    );
});

Once the image is in the cache, we can respond to the fetch request with a response from the cache instead of having to make a new request over the network.

self.addEventListener('fetch', (e) => {
    e.respondWith(
        fetch(e.request)
            .then((response) => {
                if (response.ok) return response;

                // User is online, but response was not ok
                if (isImage(e.request)) {
                    // Get broken image placeholder from cache
                    return caches.match("/broken.png");
                }

            })
            .catch((err) => {

                // User is probably offline
                if (isImage(e.request)) {
                    // Get broken image placeholder from cache
                    return caches.match("/broken.png");
                }

            })
    )
});

I created a GitHub Gist with the full implementation in case you want to use it in your own projects.

A one-line solution to highlighting search matches

2018-12-18T00:00:00Z

I’ve recently been making some improvements to the search page of this blog, and wanted to implement a feature where the search term was highlighted everywhere it appeared in the results.

Although libraries for this exist, I wanted to try to implement it myself as it seemed like an interesting challenge. I initially spent hours coming up with weird and convoluted solutions, until I realised that the String.replace() method could solve this in one line!

Primer on `String.replace()` #

The replace() method on Strings allows us to simultaneously search for matches of a substring within an original string, and replace that substring with something new. Here’s a basic example of how we can replace the substring “Hi” with "Hello", within the original string “Hi, how are you?”.

const substring = "Hi";
const original = "Hi, how are you?";

original.replace(substring, "Hello");

// Result => "Hello, how are you?"

Instead of searching for a basic substring, we can also use regular expressions, which can allow us to search for all instances of a substring.

const substring = new RegExp("Hi", "gi"); // "g" for global, "i" for case-insensitive
const original = "Hi, how are you? hi, I'm alright";

original.replace(substring, "Hello");

// Result => "Hello, how are you? Hello, I'm alright"

What I didn’t realise before was that the second argument of the replace() method could be a function. This function has one argument, which is the original matched string.

const substring = new RegExp("Hi", "gi");
const original = "Hi, how are you? hi, I'm alright";

original.replace(substring, (match) => {

  // Replace with the original text, but upper case
  return match.toUpperCase();

});

// Result => "HI, how are you? HI, I'm alright"

This allows us to have greater control over what we replace the substring with. And, it provides the exact use case that I needed which is to modify the original string in order to highlight it.

One-line match highlighting #

Here’s the solution I came up with:

const term; // search query we want to highlight in results
const results; // search results

results.replace(new RegExp(term, "gi"), (match) => `<mark>${match}</mark>`);

Let’s break this down. We have two variables; term, the search term that we want to highlight, and results, the string of text that the search term may be in.

Using the replace() method, I am performing a search for all instances (g) of the query in any case (i). With each match found, I am replacing the original matched text with the same text, but with the <mark> element surrounding it.

The <mark> HTML element is used to highlight text, so is the perfect element for this use case.

You can see how this fits within my greater search implementation on my GitHub repository for this theme.

A limitation #

One limitation of this solution to note is that it only works if your search string is plain text. That is, we can't use this replace() if the original string (i.e. the results variable) includes HTML. This is because it will reaplce all instances of the search term, including in HTML attributes such as the href of links.

Take this example:

const term = "visibility"
const results = `
<h2>
    <a href="/the-visibility-property-isnt-just-about-visibility/">
        The visibility property isn’t just about visibility
    </a>
</h2>
`

results.replace(new RegExp(term, "gi"), (match) => `<mark>${match}</mark>`);

This will add the mark element to the link matches too :(

This will result in the link itself having the <mark> element around it:

<h2>
    <a href=\"/the-<mark>visibility</mark>-property-isnt-just-about-<mark>visibility</mark>/\">
        The <mark>visibility</mark> property isn’t just about <mark>visibility</mark>
    </a>
</h2>

This wasn't an issue for me because, due to the way my search script is implemented, I was easily able to separate the text I wanted to perform the highlight on. However, if you need to perform the highlight on actual HTML, you may need to use one of the highlighting libraries out there.

There’s no reason to use pointer-events for HTML elements

2018-12-17T00:00:00Z

UPDATE: Some people have pointed out some genuinely great use cases for this property which I've listed at the end of the article. I still stand by all the points I made against the use cases I pointed out in this article, but I now believe there are some good reasons to use pointer-events for HTML elements!

The pointer-events CSS property controls if and how elements can be targeted by pointer inputs such as a mouse. It initially formed part of the specification for SVGs to allow more fine-tuned control of where in a shape a user could interact with.

This is useful, for example, if we have shapes placed on top of each other and want the shape that is not necessarily at the top of the stack to receive (or not receive) mouse events. In the example below, I have a rectangle placed behind a circle. The circle has a stroke but no fill, meaning that the rectangle behind it is visible.

<style>
    circle { pointer-events: visiblePoint; }
</style>

<svg viewBox="0 0 20 10" xmlns="https://www.w3.org/2000/svg">
  <rect x="0" y="0" height="10" width="10" fill="black" />
  <circle cx="5" cy="5" r="3" stroke="yellow" />
</svg>

By applying pointer-events: visiblePoint; to the circle, it allows the middle of the circle to be clicked, even though it appears that we are clicking the rectangle behind it.

Try clicking in the middle of the circle below. Even if you click on an area that looks like it belongs to the rectangle behind, the circle receives the click event and the stroke changes colour.

document.querySelector("circle").addEventListener("click", (e) => {
  const randomColour = Math.round(Math.random() * 0xFFFFFF);
  e.target.style.stroke = `#${randomColour.toString(16).padStart(6,"0")}`;
});

`pointer-events` and HTML elements #

Since the initial specification in SVG, the point-events property has made its way to CSS. Although limited, we can now use the pointer-events property with regular HTML elements.

<style>
    button:hover, button:focus { background-color: #ffdb3a; }
</style>

<button>Hover or focus over me</button>
<button style="pointer-events: none;">Hover or focus over me too</button>

When used with non-SVG elements, only three values are available - inherit, auto and none.

The inherit value works as it does with any other CSS property. When applied to an element, it will use the same value for the property as the element’s parent.

The auto value will restore the default functionality. That is, the pointer events for the element will behave as it does without the pointer-events property.

Finally, we have none. As we saw in the example above, this value will prevent all pointer events - hover, active, click - from being applied to the element.

Reasons to (not) use `pointer-events: none` #

As you can tell from the title of this article, my opinion is that there is no reason to use the pointer-events: none CSS rule on non-SVG, and by extension non-graphical, HTML elements.

My main reason for thinking so is because, by definition, this CSS rule will only be used when the HTML order would result in the element being able to be interacted with. The purpose of this rule seems to be to change source order in a pretty significant way.

Doing some research, I’ve come across a few scenarios in which people use this rule. Here’s what they are, and why I think they aren’t the best reasons.

Disabling interactive elements #

The most popular use case I have come across for the pointer-events: none rule is to stop users from interacting with disabled elements, such as submit buttons or input fields.

<style>
    .disabled {
        pointer-events: none;
    }
</style>

<form>
    <button class="disabled">Submit</button>
</form>

Don’t do this!

This isn’t an effective way to disable a form field because it only affects pointer events. Users can still interact with the element if navigating using a keyboard and there is no communication to assistive technology that the button is actually disabled.

A much better solution would be to use the disabled attribute in addition to visual styles to let the user know that the button is disabled.

<style>
    [disabled] {
        cursor: not-allowed;
    }
</style>

<form>
    <button disabled>Submit</button>
</form>

Better alternative

If we’re using the disabled attribute, there would be no need for the pointer-events: none rule, as the button will be properly disabled to all inputs.

Overlays #

Another example I’ve seen for the pointer-events: none rule is to allow the content behind an overlay to remain interactive.

In this case, it seems almost counterproductive to allow pointer events to the elements behind the overlay. Typically, when an overlay is used, it is a visual indication that only the elements within a restricted section, usually a modal, should be interacted with. For example, it is recommended that keyboard focus should be restricted to elements within a modal if it is active.

Therefore, it seems like cases in which an overlay is used are the exact cases where you would not want users to be able to click on elements behind the overlay.

Targeting specific children of interactive elements #

One interesting example of the pointer-events: none rule I’ve seen is to restrict the interactive sections of certain interactive elements. For example, let’s say we have a button with some text and an icon, and we only want the click of the icon to trigger the behaviour.

<button style="pointer-events: none;">
    <img src="icon" alt="Icon" style="pointer-events: auto;">
    <span>Click the icon to do stuff!</span>
</button>

This actually does have some benefit, as the text content and label remains within the <button> element. However, I think a better and more semantic solution would be to restructure the markup.

<button aria-labelled-by="label">
    <img src="icon" alt="Icon">
</button>

<span id="label">Click the icon to do stuff!</span>

Better alternative

This way, it is clear from the markup alone what each element is for and what each element will do. The <span> is purely to label, whereas the <img> is what is interactive. Looking at this markup as compared to the previous solution, it is much clearer what the abilities of the elements are.

Is there any reason to use pointer-events for non-SVG elements? #

As I’ve said, which is purely my opinion, I don’t think there is a reason to use pointer-events for regular, interactive, HTML elements. However, it exists in CSS which makes me think it might have some use I’m not thinking of. I would love to hear from you if you’ve found any genuinely good use case for it.

UPDATE: Here's some answers I've already got from people who have found some use cases for pointer-events: none on regualr HTML elements.

Also, on https://t.co/sCMU334ga8 it's used on layout elements where the children of a flexbox should be interactive, but clicks between them should fall to elements in the background — Jake Archibald (@jaffathecake) December 17, 2018

Here's one of the examples. This div is pointer-events:none, but all the children are pointer-events:auto.

That means you can click through to the canvas in between the buttons. pic.twitter.com/Ua5oKKFPP7 — Jake Archibald (@jaffathecake) December 17, 2018

- making labels inside an input non-responsive, such as the unit of measurement, which typically floats inside the input to the right side. — Dan Burzo, birdsite edition (@danburzo) December 17, 2018

- for CSS-only tooltips (with the :before pseudo-element and generated content), I'm assuming we have pointer-events: none on them to avoid weird hover effects. - for enhancing performance while transforming some things (I need to source this statement) — Dan Burzo, birdsite edition (@danburzo) December 17, 2018

Using aria-live

2018-12-14T00:00:00Z

Many web pages today have their content dynamically changed using Javascript. An example of this is the search page on this blog. When the page is initially loaded, the only content in the <main> section of the page is a search form. But, when you type in a query such as “css” and search, several articles related to that term begin to appear on the page.

If you are looking at the page, it is obvious when the articles appear because you can see the content change. However, if you’re using a screen reader, there is no way to tell exactly when this happens. The aria-live attribute allows us to tell assistive technology what parts of the page are likely to change. With this information, it can listen for changes to those particular elements and notify the user of any updates made.

How `aria-live` works #

The aria-live attribute is added to specific HTML elements which we expect the content within them to change and we want the change to be communicated to users of assistive technology.

<div aria-live="polite">
    <!-- content will be updated with Javascript -->
</div>

The attribute has three potential values which control if and how changes are communicated.

`aria-live="off"` #

The off value is practically the same as if the attribute was omitted entirely. Assistive technology will not keep track of changes to the elements content and, as such, will not notify its users of any changes.

In the example below, I have a <button> element which, on click, will update the content of the <div> below it.

<button onclick="document.getElementById('content').textContent = 'I have changed!'">
    Click me to change the content of the div element below
</button>

<div id="content" aria-live="off">
  My content will change
</div>

As you’ll see in the video below, since the <div> has the aria-live value of off, nothing happens when the button is clicked and the content changes.

`aria-live="polite"` #

The polite value, will ensure that users of assistive technology will be notified of any changes to the element. The notification will happen at the next available point, meaning that there will not be an interruption to whatever task or information the user was currently in the process of.

Using the same example above but with the polite value, you’ll see that the screen reader waits to finish reading the label of the button before speaking the contents of the changed <div>.

`aria-live="assertive"` #

Finally, the assertive value will communicate changes to the element immediately, disrupting any other task or information the user was currently in the process of.

Again, using the same example above but with the assertive value, you’ll see that the screen reader interrupts reading the label of the button to speak the contents of the changed <div>.

Considerations when using `aria-live` #

If applied incorrectly, the aria-live attribute can do more harm than good. So, it’s important to take into account a few things if we want to use it.

Include `aria-live` in the initial markup #

Assistive technology will initially scan the document for instances of the aria-live attribute and keep track of elements that include it. This means that, if we want to notify users of a change within an element, we need to include the attribute in the original markup. In other words, we should not use Javascript to add the aria-live attribute to elements dynamically.

<div class="will-change">
    <!-- content will be updated with Javascript -->
</div>

<script>
document.querySelector(".will-change").setAttribute("aria-live", "polite");

document.querySelector(".will-change").textContent = "New content!";
<script>

Don’t do this!

Instead, make sure that any elements that will change and needs their changes communicated, already have the aria-live attribute:

<div aria-live="polite" class="will-change">
    <!-- content will be updated with Javascript -->
</div>

<script>
document.querySelector(".will-change").textContent = "New content!";
<script>

Do this instead

Only apply `aria-live` to specific elements, not the entire page #

You may be thinking that a good workaround to using aria-livewould be to just include the attribute on the <body> element so assistive technology will keep track of any and all changes on the page.

<body aria-live="polite">
    <header></header>
    <main>
        <p class="will-change"><!-- content will change --></p>
        <div class="will-change"><!-- content will change --></div>
    </main>
    <footer></footer>
</div>

Don’t do this!

The problem with this is every single change made on the page will be communicated to the user. Think of a single page application, for example. If the main content of the page changes, the assistive technology will try to read out every single piece of text that has changed on the page, which will essentially be the entire content of the page.

This is rarely what we actually want to happen. So, we should only use aria-live on the elements which we want their change in content actively communicated to the user.

<body>
    <header></header>
    <main>
        <p aria-live="polite" class="will-change"><!-- content will change --></p>
        <div aria-live="polite" class="will-change"><!-- content will change --></div>
    </main>
    <footer></footer>
</div>

Do this instead

Be `polite` #

As we saw in my demo above, the assertive value will interrupt whatever task the screen reader user is in the middle of to announce any changes to the page. Therefore, it is important to only use this value if it is absolutely necessary to communicate changes immediately as they come. In most cases, the polite value is sufficient.

Switch `off` #

If we are certain that an element will no longer be updated, use the off value to tell assistive technology that it no longer needs to keep track of changes.

// Change content
document.querySelector(".will-change").textContent = "New content!";

// Stop tracking changes to the element
document.querySelector(".will-change").setAttribute("aria-live", "off");

Applying `aria-live`: an example #

As I mentioned at the start of this article, a good use case for the aria-live attribute is for places where content on the page is dynamically updated, such as the search page on this blog.

I recently updated that page to include this attribute. All I did was add the aria-live attribute to a <span> element, the content of which is updated when a user interacts with the form.

<section id="search-results" role="region">
    <span id="search-results-message" aria-live="polite">
        Use the <a href="#search-form">search form</a> above to search for articles.
    </span>
</section>

When the form is submitted, the contents of the #search-results-message element changes to display the number of articles found. This way, the user is informed of the completion of the search and they can continue to navigate the page as expected.

Here is how a screen reader user would interact with the form, before and after the implementation.

Cache API 101

2018-12-13T00:00:00Z

A cache is a form of storage for “requests” and “responses”. When you visited this page, you made a request for /cache-api-101. The response to that request was the HTML document you are viewing in your browser right now. The cache API allows us to store these requests and responses locally in the browser.

The cache API was created as part of the service worker specification to “allow authors to fully manage their content caches for offline use”. In my tutorial, Going Offline First, I demonstrated how I used the cache API to convert this blog to an offline-first strategy, enabling readers to save articles for offline. If you want to see a real-world use case of cache, I would suggest you watch that.

In this article, I want to go over the cache API terminology and how to use the API methods.

Cache storage organisation and terminology #

Before we dive into the specifics of how to create and use a cache, let’s go over how the cache storage is organised and what the different bits are called.

If you open up your browser developer tools, you will see a section for “Cache Storage”.

Firefox: Storage > Cache Storage
Google Chrome: Application > Cache > Cache Storage

Each origin, e.g. for this website https://bitsofco.de, has one cache storage. This object can contain multiple cache objects, each containing a request-response list.

Let’s take this in reverse. An example of a request-response could be, as I mentioned at the start of this article, this page’s URL (the request) and the HTML content (the response). We can save this request-response in a cache object that I call “articles-cache”. This “articles-cache” cache would belong to the cache storage for the https://bitsofco.de origin.

CRUD with the cache API #

Like any form of storage, we need to be able to perform create, read, update, and delete operations to use it. To illustrate this, let’s create a cache I will call “my-cache”, which will store a page, /subscribe, and an image, /assets/images/profile.png.

Creating a new cache and adding items #

To add a request-response item to a cache, we need to first create the cache to add to it. As I mentioned, an origin can have multiple caches within the cache storage, so we need to specify which cache we want to add the request-response item to.

The method for creating and/or accessing a cache is caches.open(). The caches name is a global variable that refers to the cache storage object. The open() method accepts one argument, the name of the cache we want to access.

caches.open("my-cache").then((myCache) => {
    // Do stuff with myCache
});

To add a request-response item to a cache, we use the add() method on the cache object returned. This method accepts a request, which can either be a full request object, or just a URL.

caches.open("my-cache").then((myCache) => {
    // URL only
    myCache.add("/subscribe");

    // Full request object
    myCache.add(new Request('/subscribe', {
        method: "GET",
        headers: new Headers({
		    'Content-Type': 'text/html'
	    }),
        /* more request options */
    });
});

The browser will make the fetch request given the specified Request, and save the response to the cache.

If we have multiple items to add, we can use the addAll() method, which accepts an array of requests.

caches.open("my-cache").then((myCache) => {
    myCache.addAll([
        "/subscribe",
        "/assets/images/profile.png"
    ]);
});

Reading items from cache storage #

To find an item from the cache storage, we can use the caches.match() method.

caches.match("/subscribe").then((cachedResponse) => {
    if (cachedResponse) {
        // Do something with cachedResponse
    } else {
        // Handle if response not found
    }
});

We can also look within a particular cache with the same method on the cache object. This is helpful if we have multiple cache objects and we know that an item may exist in a particular one.

caches.open("my-cache").then((myCache) => {
    myCache.match("/subscribe").then((cachedResponse) => {

        if (cachedResponse) {
            // Do something with cachedResponse
        } else {
            // Handle if response not found
        }

    });
});

Similar to the addAll() method, we also have a matchAll() method, which will return an array of cached responses. This is useful for searching for all items that match a URL fragment, e.g. any items with /images/ in their path.

caches.open("my-cache").then((myCache) => {
    myCache.matchAll("/images/").then((cachedResponses) => {

        if (cachedResponses) {
            // Do something with cachedResponses
        } else {
            // Handle if response not found
        }

    });
});

Updating an item in the cache #

Next, we may want to update a request-response item in the cache. Let’s say, for example, the content of the /subscribe page has changed and we want to update what is in the cache with the new version.

We can do this in one of two ways. First, we can call the same, cache.add() method. This will first perform a fetch for the request page and replace any request-response item in the cache that has the same URL.

caches.open("my-cache").then((myCache) => {
    // browser will request and cache the response
    myCache.add("/subscribe");
});

Alternatively, if we want more control over what response is put in the cache, we can use the cache.put() method. Using this method, we need to specify both a request and a response. This means we will need to fetch the document ourselves first.

const request = new Request("/subscribe");

fetch(request).then((fetchResponse) => {
    caches.open('my-cache').then((myCache) => {
        cache.put(request, fetchResponse);
    });
});

Deleting an item from the Cache #

Finally, we need to be able to remove a request-response item from the cache or delete a cache altogether.

To remove a specific item from the Cache, we use the cache.delete() method, passing in the request URL.

caches.open("my-cache").then((myCache) => {
    myCache.delete("/subscribe");
});

To remove a cache altogether, we can use the same method on the caches object.

caches.delete("my-cache");

Where to use the cache API #

Although the cache API was created with the Service Worker, it can be used in the main document as well.

The caches object is available to the window. We can check if it exists in the current browser before using it.

if ('caches' in window) {
    caches.open("my-cache").then((myCache) => {
        // Do stuff
    });
}

In our service worker file, we can use the same cache API to intercept fetch requests and return cached responses if they exist.

/service-worker.js

self.addEventListener('fetch', (e) => {
    e.respondWith(

        // Check if item exists in cache
        caches.match(e.request).then((cachedResponse) => {

            // If found in cache, return cached response
            if (cachedResponse) return cachedResponse;

            // If not found, fetch over network
            return fetch(e.request);
        });

  );
});

The visibility property isn’t just about visibility

2018-12-12T00:00:00Z

I recently ran into an issue where the text content of a <button> I created wasn’t in the accessibility tree and therefore wasn’t visible to screen readers. After some debugging, I realised that the reason was because I was animating the text visually by changing the opacity and, more importantly the visbility property.

It was definitely an oversight, as I know and have previously written about the different effects of different ways to hide elements with CSS. But this made me think about the behaviour of the visibility property, particularly the hidden value, as it relates to the different kinds of “visibility” - visual, spatial, assistive technology, and interaction. When we hear the world “visibility”, we tend to only think of vision. As we will see, the visibility property isn’t just about (visual) visibility.

`visibility: hidden` and visual visibility #

When visual visibility is concerned, the visibility: hidden rule has the effect we would expect. The element becomes, more or less, “invisible”.

It's gone! ---> <span style="visibility: hidden;">I'm gone!</span>

It's gone! ---> I'm gone!

To understand exactly what is happening, let’s revisit the browser’s rendering pipeline, a.k.a. the critical rendering path. Typically, once the page’s styles have been determined, three things happen:

Layout - what space does the element take up on the page?
Paint - what goes in each pixel?
Composite - in what order is each pixel drawn?

For an element with the visibility: hidden rule, it would make sense for browsers to optimise by not taking the paint and composite steps, since there are no pixels drawn in the place where the element would be. Although this isn’t set in the specification that browsers must make this optimisation, it helps me understand how this rule works by thinking of it in this way.

`visibility: hidden` and space #

Although it is technically true to say that an element is invisible when the visibility: hidden rule is applied to it, it can be argued that it isn’t truly invisible because it still occupies space on the page.

As I mentioned, an element with visibility: hidden may not have to go through the paint and composite steps in the rendering pipeline. However, it will go through the layout stage. This means that, although the pixels aren’t painted, they still occupy space on the page. It’s sort of like Harry Potter and his invisibility cloak - you couldn’t see him, but he was still there.

Let’s take these three <div> elements, each with a width of 100px, with the middle <div> having the visibility: hidden rule.

<style>
    div {
        width: 100px;
        display: inline-block;
        background-color: #ffdb3a;
    }
</style>

<div>One</div>
<div style="visibility: hidden;">Two</div>
<div>Three</div>

One

Two

Three

Although the middle <div> is technically “visually hidden”, it can be argued that it isn’t truly invisible due to the fact that it still occupies space.

`visibility: hidden` and interactivity #

Because an element with the visibility: hidden rule will still occupy physical space on the page, it may seem as if all this rule does is visually hide the element in a similar way to setting opacity to 0. On the contrary, the visibility: hidden rule is actually much more similar to display: none.

Any interactive elements, such as forms or links will also lose their ability to be interacted with. For example, take the <button> below that should pop up an alert when clicked.

It's gone! --->
<button style="visibility: hidden;"
        onclick="alert('Hello!')">I'm gone!</button>
<--- You can't touch it!

It's gone! ---> <--- You can't touch it!

Although the button has physical space, it can’t be interacted with in any way.

`visibility: hidden` and assistive technology #

The main reason the visibility: hidden rule isn’t just about visual visibility is because it affects the elements visibility to assistive technology as well. When we apply visibility: hidden to an element, it also removes it from the accessibility tree, which makes it invisible to technologies like screen readers.

Take, for example, the issue I came across. I have a <button> element, with a nested <span> .

<button>
    <span style="visibility: hidden">Button label here</span>
</button>

If we look at the accessibility properties of the element, we will see that the <button> appears to have no text content within it and therefore no accessible name.

Although the visibility property may seem to only affect visual visibility, we can see that it does much more than that.

When do the :hover, :focus, and :active pseudo-classes apply?

2018-12-11T00:00:00Z

When we select an element by its .class or #id, we’re using predefined and unchanging attributes that are baked into the DOM. With pseudo-classes, we can select elements using information that isn’t already in the DOM and can change based on how a user interacts with the page.

:hover, :focus, and :active are pseudo-classes that are determined by a user’s actions. They each correspond to a very specific point in how a user will interact with an element on a page such as a link or a button or an input field.

With the range in input devices we have today, these pseudo-classes also behave slightly differently depending on if the user is interacting with the element with a mouse 🐭, keyboard ⌨️, or touchscreen 📱, which can make it difficult to know how and when to style these situations.

When `:hover` is applied #

The :hover pseudo-class, also called the “pointer hover pseudo-class”, applies when a pointing device interacts with an element without necessarily activating it.

A typical example of this is when a mouse 🐭 hovers over an element. If you hover your mouse over the button below, you’ll see that it turns yellow.

button:hover { background-color: #ffdb3a; }

When on a mobile device 📱, there’s basically only one interaction you can take with any interactive element, which is tapping/clicking it. You may notice that if you tap on the button above, it also changes the colour despite the fact that you aren’t “just” hovering over it. This is because, on mobile devices, the events that trigger these pseudo-classes can become conflated. We’ll see with :focus and :active pseudo-classes as well.

Finally, for users of keyboard devices ⌨️, the :hover pseudo-class is never triggered. The keyboard is not considered a “pointer” device and so can’t apply to this pointer hover pseudo-class.

When `:focus` is applied #

The :focus pseudo-class applies when an element is in a state that is ready to be interacted with, i.e. it has the focus of the input device. When this applies differs quite greatly between the different input devices.

When using a mouse 🐭 or similar pointing device, the :focus pseudo-class will apply once the user has begun activating the element and, importantly, it will continue to stay in focus until the user activates another element. For example, if you click the button below with a mouse, you’ll notice that it turns yellow once you begin the click interaction. The button will only return to its default state if you click somewhere else on the page.

button:focus { background-color: #ffdb3a; }

For keyboard users ⌨️, focusing on an element is very similar to hovering over it for mouse users. I like to think of the :focus pseudo-class as a hover state for keyboard devices, because it signals a similar intention for interaction.

For touchscreen users 📱, the :focus pseudo-class applies, again, when the user taps on the element. However, it should be noted that this doesn’t apply for the mobile Safari browser.

When `:active` is applied #

Finally, the :active pseudo-class applies during the period in which the element is being activated. For example, if using a mouse 🐭, it would be the time between when the mouse button is clicked and when it is released.

If you click the button below quickly, you may not notice the brief change in colour, but if you press and maintain, you’ll see when the pseudo-class is applied.

button:active { background-color: #ffdb3a; }

The :active pseudo-class works in the same way for mouse and keyboard ⌨️ interactions.

On mobile devices 📱, like the :focus pseudo-class, the :active pseudo-class applies on the tap of the element. And again, it doesn’t apply at all in the mobile Safari browser.

Combining `:hover`, `:focus`, and `:active` #

One thing you may have noticed is that the conditions in which each of these pseudo-classes can be applied are not mutually exclusive. In fact, most times when an element is being clicked with a mouse, all three conditions are valid - the mouse if over the element, the element is in focus, and the element is being activated.

We can test this by only changing the background of the button if all three conditions apply.

button:hover:focus:active {
  background-color: #ffdb3a;
}

If you click and hold the button below, you’ll see that it turns yellow. But if you click and hold while dragging your mouse away from hovering over it, you’ll see that it loses the colour.

This ability to combine the pseudo-classes can be really helpful for fine-tuning how we want to style the different states.

Order of styles - `:hover` then `:focus` then `:active` #

Due to the fact that these conditions can and frequently are applied at the same time, the order in which we add these styles is important.

Let’s say we have the following styles:

button:active {
  background-color: green;
}

button:focus {
  background-color: blue;
}

button:hover {
  background-color: red;
}

Only the :hover styles will be visible

When you hover and interact with the element above, only the styles applied to :hover will prevail as long as you are still hovering over it. As we’ve seen, since all three events are applied during a typical click event, the cascade takes over and the last-defined style wins.

This is why it’s important to define these styles in the order in which they typically happen, so it becomes clear to the user when a new interaction is recognised. Typically, a user will first hover over an element, then bring it to focus, then activate it. So, the best way to order your pseudo-class styles are :hover then :focus then :active .

button:hover {
  background-color: green;
}

button:focus {
  background-color: blue;
}

button:active {
  background-color: red;
}

All styles will be visible

Recap #

The :hover, :focus, and :active pseudo-classes allow us to style elements in response to how a user interacts with it. Depending on the device being used, these pseudo-classes become active at different points (or not at all).

	`:hover`	`:focus`	`:active`
Mouse 🐭	Yes	Yes	Yes
Keyboard ⌨️	No	Yes	Yes
Touchscreen 📱	Yes (on click)	Yes* (on click)	Yes* (on click)

* Will not apply on mobile (iOS) Safari

What is the Shadow DOM?

2018-12-10T00:00:00Z

A couple of weeks ago, I wrote an article on what exactly the DOM is. To recap, the Document Object Model is a representation of an HTML document. It is used by browsers to determine what to render on the page, and by Javascript programs to modify the content, structure, or styling of the page.

For example, let’s take the following HTML document:

<!doctype html>
<html lang="en">
 <head>
   <title>My first web page</title>
  </head>
 <body>
    <h1>Hello, world!</h1>
    <p>How are you?</p>
  </body>
</html>

The above HTML document will result in the following DOM tree.

html
- head
  - title
    - My first web page
- body
  - h1
    - Hello, world!
  - p
    - How are you?

In the past few years, you may have heard of terms like “Shadow DOM” and “Virtual DOM”. These, although of course related to the original DOM, refer to very different concepts. In this article, I will cover what, exactly, the shadow DOM is and how it differs from the original DOM. In a future article, I’ll do the same for the virtual DOM.

Everything is global 👍🏾! Wait, everything is global 👎🏾 #

All elements and styles within an HTML document, and therefore the DOM, are in one big global scope. Any element on the page can be accessed by the document.querySelector() method, regardless of how deeply nested it is in the document or where it is placed. Similarly, CSS applied to the document can select any element, regardless of where it is.

This behaviour can be really great when we want to apply styles to the entire document. It’s incredibly useful to be able to select every single element on a page and set, for example, their box-sizing, all in a single line.

* { box-sizing: border-box }

On the other hand, there are times where an element requires complete encapsulation and we don’t want it to be affected by even global styles. A good example of this is third-party widgets, such as the “follow” button for Twitter. Here’s an example of of what that widget looks like:

Follow @ireaderinokun

Assuming you have Javascript enabled and you inspect the element, you’ll notice that the button is an <iframe> element, which loads a small document with the styled button you actually see.

This is the only way that Twitter can ensure the intended styling of their widget will remain unaffected by any CSS in the hosting document. Although there are ways to use the cascade to try and achieve the same result, no other method will give the same guarantee that an <iframe> would, and that’s not ideal.

Shadow DOM was created to allow encapsulation and componentisation natively on the web platform without having to rely on tools like <iframe>s, which really weren’t made for this purpose.

A DOM within a DOM #

You can think of the shadow DOM as a “DOM within a DOM”. It is its own isolated DOM tree with its own elements and styles, completely isolated from the original DOM.

Although only recently specified for use by web authors, the shadow DOM has been used by user agents for years to create and style complex components such as form elements. Let’s take the range input element, for example. To create one on the page, all we have to do is add the following element:

<input type="range">

That one element results in the following component:

If we dig deeper, we will see that this one <input> element is actually made up of several smaller <div> elements, controlling the track and the slider itself.

This is achieved using the shadow DOM. The element that is exposed to the host HTML document the simple <input>, but underneath it there are elements and styles related to the component that do not form part of the DOM’s global scope.

How the shadow DOM works #

To illustrate how the shadow DOM works, let’s recreate the Twitter “follow” button using the shadow DOM instead of an <iframe>.

First, we start with the shadow host. This is the regular HTML element within the original DOM that we want to attach the new shadow DOM to. For a component like the Follow button, it could also contain the fallback element that we would want displayed if Javascript was not enabled on the page or shadow DOM wasn't supported.

<span class="shadow-host">
  <a href="https://twitter.com/ireaderinokun">
     Follow @ireaderinokun
  </a>
</span>

Note that we didn’t just use the <a> element as the shadow host, because certain elements, primarily interactive elements, can’t be shadow hosts.

To attach a shadow DOM to our host, we use the attachShadow() method.

const shadowEl = document.querySelector(".shadow-host");
const shadow = shadowEl.attachShadow({mode: 'open'});

This will create an empty shadow root as a child of our shadow host. The shadow root is the start of a new shadow DOM in the way that the <html> element is the start of the original DOM. We can see our shadow root in the devtools inspector by the #shadow-root.

Although the regular HTML children are viewable in the inspector, they are no longer visible on the page as the shadow root takes over.

Next, we want to create the content to form our new shadow tree. The shadow tree is like a DOM tree, but for a shadow DOM instead of a regular DOM. To create our follow button, all we need is a new <a> element, which will be almost exactly the same as the fallback link we already have, but with an icon.

const link = document.createElement("a");
link.href = shadowEl.querySelector("a").href;
link.innerHTML = `
    <span aria-label="Twitter icon"></span>
    ${shadowEl.querySelector("a").textContent}
`;

We add this new element to our shadow DOM the same way we add any element as a child to another, with the appendChild() method.

shadow.appendChild(link);

At this point, here's what our element looks like:

Finally, we can add some styles by creating a <style> element and appending that to the shadow root too.

const styles = document.createElement("style");
styles.textContent = `
a, span {
  vertical-align: top;
  display: inline-block;
  box-sizing: border-box;
}

a {
    height: 20px;
    padding: 1px 8px 1px 6px;
    background-color: #1b95e0;
    color: #fff;
    border-radius: 3px;
    font-weight: 500;
    font-size: 11px;
    font-family:'Helvetica Neue', Arial, sans-serif;
    line-height: 18px;
    text-decoration: none;
}

a:hover {  background-color: #0c7abf; }

span {
    position: relative;
    top: 2px;
    width: 14px;
    height: 14px;
    margin-right: 3px;
    background: transparent 0 0 no-repeat;
    background-image: url(data:image/svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%2072%2072%22%3E%3Cpath%20fill%3D%22none%22%20d%3D%22M0%200h72v72H0z%22%2F%3E%3Cpath%20class%3D%22icon%22%20fill%3D%22%23fff%22%20d%3D%22M68.812%2015.14c-2.348%201.04-4.87%201.744-7.52%202.06%202.704-1.62%204.78-4.186%205.757-7.243-2.53%201.5-5.33%202.592-8.314%203.176C56.35%2010.59%2052.948%209%2049.182%209c-7.23%200-13.092%205.86-13.092%2013.093%200%201.026.118%202.02.338%202.98C25.543%2024.527%2015.9%2019.318%209.44%2011.396c-1.125%201.936-1.77%204.184-1.77%206.58%200%204.543%202.312%208.552%205.824%2010.9-2.146-.07-4.165-.658-5.93-1.64-.002.056-.002.11-.002.163%200%206.345%204.513%2011.638%2010.504%2012.84-1.1.298-2.256.457-3.45.457-.845%200-1.666-.078-2.464-.23%201.667%205.2%206.5%208.985%2012.23%209.09-4.482%203.51-10.13%205.605-16.26%205.605-1.055%200-2.096-.06-3.122-.184%205.794%203.717%2012.676%205.882%2020.067%205.882%2024.083%200%2037.25-19.95%2037.25-37.25%200-.565-.013-1.133-.038-1.693%202.558-1.847%204.778-4.15%206.532-6.774z%22%2F%3E%3C%2Fsvg%3E);
}
`;

shadow.appendChild(styles);

Here's our final element: Follow @ireaderinokun

The DOM vs the shadow DOM #

In some ways, the shadow DOM is a "lite" version of the DOM. Like the DOM, it is a representation of HTML elements, used to determine what to render on the page and enables the modification of the elements. But unlike the DOM, the shadow DOM is not based on a full, standalone document. A shadow DOM, as it's name suggests, is always attached to an element within a regular DOM. Without the DOM, a shadow DOM doesn't exist.

Going Offline First (Video Series)

2018-12-05T00:00:00Z

You may have noticed that I recently updated this blog to allow for users like yourself to save an article to view offline. You can do this by clicking the bookmark icon above.

If you are ever offline, you will still be able to view articles previously bookmarked. If you try to visit a page that isn't bookmarked, you'll be redirected to the offline page, which lists all the saved articles.

The Video Series #

In order to show how I did this, I created a 5-part video tutorial. You can watch it below or on my YouTube channel.

Part 1 - Introduction & Ghost Theme Setup #

Part 2 - Saving Pages to Cache Storage #

Part 3 - Creating an Offline Page #

Part 4 - Service Worker & Serving Offline Pages #

Part 5 - Handling Assets while Offline #

A look at CSS Resets in 2018

2018-11-30T00:00:00Z

All browsers ship with a set of default styles that are applied to every web page in what is called the “user agent stylesheet”. Most of these stylesheets are open source so you can have a look through them:

Chromium UA stylesheet - Google Chrome & Opera
Mozilla UA stylesheet - Firefox
WebKit UA stylesheet - Safari

A lot of styles are consistent across all user agent stylesheets. For example, I used to think that the <head> element was not visible due to some special feature, but it is actually hidden like any other element on a page, with display: none! You can see this same style in WebKit, Chromium, and Mozilla.

A lot of styles, however, are inconsistent between the user agent stylesheets. For example, see how a search input is styled across the browsers.

The case for CSS resets #

In order to deal with the inconsistencies between user agent stylesheets, CSS resets were born. A CSS reset is a set of styles applied to a page before any other custom styles, with the purpose of creating a more standardised base between browsers.

Eric Meyer wrote an article on the reasoning behind CSS resets in 2007, which I think still holds true:

The basic reason is that all browsers have presentation defaults, but no browsers have the same defaults… We think of our CSS as modifying the default look of a document but with a “reset” style sheet, we can make that default look more consistent across browsers, and thus spend less time fighting with browser defaults.

Although things are different than they were in 2007, I think resets can still be useful.

Aren’t user agent stylesheets less inconsistent nowadays? #

Yes, a lot of default styles between user agent stylesheets are now very similar. For example, most browsers apply the same 0.67em horizontal margin and 2em font size to the <h1> element. However, this consistency is relatively new and we still need to consider support for the older browsers that have less consistent default styling.

Additionally, depending on the type of reset we want to apply (as we will see below), we may still want a reset even if only the modern, more consistent, browsers were in use.

Don’t we apply our own styles to override reset anyway? #

One of the major arguments against using CSS resets is that a lot of the styles are eventually overridden by our main stylesheet, which means that the reset styles unnecessarily add to page load time. Although this is definitely true, it isn’t a good enough argument for me to stop using them for two reasons.

The first is that I think resets allow us to write cleaner styles. We can separate my styles that are targeted to specific browsers and my styles for the actual design of the website. Instead of having browser-specific corrections in the same place as my design-specific styles, we can separate them.

Second, resets are (typically) very small and should have a negligible effect on load times. We frequently use the cascade to override and modify element styling, and although there may be some performance gains to never doing this, it may not be worth the time.

Types of CSS resets #

There are many, many different CSS resets. Since the first in 2004, undohtml, there has been a plethora of resets ranging in complexity and specificity.

Broadly, there are three goals that a CSS reset tries to achieve. Some reset stylesheets combine these three goals, whereas others only try to solve one.

Correct user agent styling errors
Undo any "opinionated" user agent styling
Create a consistent, largely opinionated, style base

Corrective resets #

One goal of CSS resets is to correct errors in user agent stylesheets. As you would imagine, this is more for older browsers. A good example of this is when HTML5 was introduced and browsers such as Internet Explorer 9 didn’t apply the correct display type to the new elements.

In resets like normalize.css, these errors are specifically targeted and fixed:

Normalize.css

/**
 * Add the correct display in IE.
 */

main {
  display: block;
}

Since these styles only apply to older browsers, we can also use a PostCSS processor such as PostCSS Normalize, along with browserlist. This allows us to conditionally add these types of styles only if we are supporting that particular browser.

Another example, which applies to some modern browsers, is correcting the display on elements with the hidden attribute.

Pure CSS

[hidden] {
    display: none !important; // One of the good use cases of !important
}

Undoing opinionated user agent styling #

Another goal of CSS resets was to undo any opinionated styles from user agents.

There are many opinions for what an opinionated style is. My definition of an opinionated style is anything that isn’t the, for lack of a better word, “bare” version. For example, I would consider adding a 2em margin on headings, as most user agent stylesheets do, an opinionated style because why 2em? Why not 3em? Or 4em? An “unopinionated” style in my opinion would just be a margin of 0 instead. Okay, back to the resets.

A simple version of this is the “Universal Reset”, which removes all margin and padding from all elements:

* {
    margin: 0;
    padding: 0;
}

This reset is probably too heavy-handed, as it removes padding from elements you may not expect, such as <input> elements. An alternative, more commonly used reset is Eric Meyer’s CSS Reset. It returns margin, padding, borders, and font size on specific elements to 0 or none. And, it doesn't include elements where you would expect a padding.

Meyer's CSS Rest

html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed,
figure, figcaption, footer, header, hgroup,
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
	margin: 0;
	padding: 0;
	border: 0;
	font-size: 100%;
	font: inherit;
	vertical-align: baseline;
}

Resets for consistent, opinionated, styles #

Where the previous category of resets attempted to correct opinionated user agent styles by undoing them entirely, this category of resets does this by setting its own opinionated styles.

For example, instead of setting all font sizes to 1em or margins to 0, this type of reset will set an opinionated style.

Sanitize.css

/**
 * Correct the font size and margin on `h1` elements within `section` and
 * `article` contexts in Chrome, Firefox, and Safari.
 */

h1 {
  font-size: 2em;
  margin: 0.67em 0;
}

Bootstrap’s Reboot is another example of this. They take things a bit further, even declaring font families and background colours for the <body> element.

Reboot.css

// Body
//
// 1. Remove the margin in all browsers.
// 2. As a best practice, apply a default `background-color`.
// 3. Set an explicit initial text-align value so that we can later use the
//    the `inherit` value on things like `<th>` elements.

body {
  margin: 0; // 1
  font-family: $font-family-base;
  font-size: $font-size-base;
  font-weight: $font-weight-base;
  line-height: $line-height-base;
  color: $body-color;
  text-align: left; // 3
  background-color: $body-bg; // 2
}

How are we using CSS resets today? #

I recently ran a poll on Twitter asking people what CSS resets they currently use.

Thinking of writing about CSS resets and how they're used today. Do you use a CSS reset/normaliser? Which one? — Ire Aderinokun (@ireaderinokun) November 26, 2018

Most people use resets like Normalize.css, which is a combination of correcting browser errors and setting consistent, opinionated, styles. A good amount of people reported their own customised resets, which generally fell into the third category as well.

My opinion #

I have always used a slightly-modified version of Eric Meyer’s CSS reset for two reasons.

The first is that I generally prefer to work with as blank a slate as possible, adding styles as I see fit. This is just a personal preference for the way I work.

The second is that I’m a strong believer in only applying margins in one direction (usually down) and most opinionated resets, like most user agent stylesheets, don’t follow this rule. Therefore, I would rather start with zero margin and padding anywhere, and add it as I go.

Nowadays, I’ve been tweaking my reset file a lot more, even adding utilities that I want in every project I work on, such as a .sr-only class. This has made me think that it isn’t really a reset anymore and is more of a “base”. With new resets coming out like Reboot, it seems like this is the general theme of where things are going.

I'm really interested to hear what everyone uses. Do leave a comment with what you think about resets today!

How and when to use the tabindex attribute

2018-11-29T00:00:00Z

tabindex is a global attribute that can be applied to most HTML elements with content. It controls two things:

If an element is focusable, either by an input method such as the keyboard, or programatically such as with the focus() method; and
At what point an element becomes focusable when a user is interacting with the page via a keyboard

Focus order #

To understand how the tabindex attribute works, we first need to understand how focus is controlled on a page.

There are six ¹ HTML elements which, by default, are focusable:

<a> elements with an href attribute
<link> elements with an href attribute
<button> elements
<input> elements that are not type="hidden"
<select> elements
<textarea> elements

By default, only these elements can be brought into focus either with a user tabbing around the page with a keyboard or via the focus() method in Javascript.

document.querySelector("a").focus();

Without any intervention, calling focus() on any other element simply will not work.

document.querySelector("div").focus();

Will not work

The order in which these elements are placed in the source HTML document controls the order in which they become focusable when navigating with a keyboard.

Although this default behaviour covers most of the interaction we would need, there may be cases where we want to remove, add, or re-arrange items in the focus order. This is where the tabindex attribute becomes handy.

How to use `tabindex` #

The tabindex attribute can be applied to almost any element, whether it is by default focusable or not. The value of the attribute must be a valid integer and can either be negative, positive, or exactly zero.

Negative `tabindex` values #

A negative tabindex, for example -1, will omit the element from the focus order entirely. A user navigating the page using a keyboard will not be able to access the element at all.

<button type="button">Click me to start, then press the "tab" key</button>
<button type="button">I’ll be in focus first</button>
<button type="button" tabindex="-1">I won’t be in focus :(</button>
<button type="button">I’ll be in focus last</button>

The exact negative value chosen doesn’t actually matter. Since any negative value will remove the element from focus, there is no difference if the value is -1 or -99999. Therefore, for readability and consistency, it is best to stick with -1.

A `tabindex` value of zero #

A tabindex equals to exactly zero will place the element in the default focus order, determined by its position in the source HTML. It can be applied to elements that are not typically focusable, and will add them to the natural focus order as if they were.

<button type="button">Click me to start, then press the "tab" key</button>
<button type="button">I’ll be in focus first</button>
<div tabindex="0">I’m a DIV and will be in focus second</div>
<button type="button">I’ll be in focus last</button>

I’m a DIV and will be in focus second

Positive `tabindex` values #

Finally, a positive tabindex will place the element in the focus order, but it’s position will be determined by the specific number, starting from 1 and going up. Elements with a positive tabindex will also be placed in front of elements that don’t have a tabindex attribute.

<button type="button" tabindex="1">I’m the first focusable item on the page</button>
<button type="button" tabindex="500">I’m the second</button>

To test this out, click on the URL bar of your browser, then hit tab. You'll see that the first two focusable items on this page are the buttons below, even though they are in the middle of the source HTML.

Programmatic focus and `tabindex` #

Besides controlling which elements can be focusable via the keyboard and focus order, the tabindex attribute also controls which elements can be focusable via Javascript.

Adding the tabindex attribute to an element, regardless of the value, makes it focusable via Javascript. This means that we can make elements that are previously unfocusable to be focusable via Javascript, without also making them able to be focused via the user tabbing around using their keyboard.

Let’s take this <div>, for example, with a negative tabindex.

<div tabindex="-1">I'm a div</div>

If we were to navigate using the keyboard, we will see that it is not able to grab focus.

I'm a div

However, we can bring focus to it using the focus() method.

<button type="button"
        onclick="document.getElementById('demo-div').focus();">
        Click me to focus the DIV
</button>
<div id="demo-div" tabindex="-1">I'm a div</div>

I'm a div

Next, we’ll see how this difference between tab and programmatic focus makes the tabindex attribute useful.

When to use `tabindex` #

The tabindex attribute can be very useful, but has potentially destructive consequences if not used correctly. Each category of tabindex value should be used in different circumstances.

When to use a negative `tabindex` value #

As we have covered, a negative tabindex value will remove the element from tab focus, but can add elements to programmatic focus.

A great example of when this is useful is modals. Modal containers are typically unfocusable elements like <div> or <section>. When a modal window is open, we may want to move focus to it so that screen readers will read out its content. But, we don’t want the modal container itself to be able to receive tab focus. This can be achieved using a negative tabindex.

<div id="modal" tabindex="-1">
    <!-- Modal content -->
</div>

<script>
function openModal() {
    document.getElementById("modal").focus();

    // Other stuff to show modal
}
</script>

When to use a `tabindex` value of zero #

A tabindex of zero is typically used either to add focus back to elements that it was programatically removed from.

Another good use case for this value is for custom elements. For example, we may need to create a custom button element, which will not be focusable by default because it's not actually a <button>. We can add this functionality back with the tabindex attribute, and specify its focus order as any regular button element would have.

<my-custom-button tabindex="0">Click me!</my-custom-button>

When to use a positive `tabindex` value #

There is almost no reason to ever use a positive value to tabindex, and it is actually considered an anti-pattern. If you’re finding the need to use this value to change the order in which elements become focusable, it is likely that what you actually need to do is change the source order of the HTML elements.

#1 - I excluded the menuitem element as it’s no longer valid HTML

Everything about CSS environment variables

2018-11-28T00:00:00Z

When the iPhone X came out with the infamous notch, you may have heard of the new safe-area-inset values, which allowed browsers to detect the area of the screen that was covered by the notch and move content around appropriately.

Recently, these values have been formalised as part of a new specification for CSS Environment Variables. This specification is still in the stage of Editor’s Draft which means that, although some browsers may begin implementation, it is not yet an official part of the specification. However, it does have good support with browsers that need it, e.g. iOS Safari on the iPhone X, and can be used in a progressive way.

We already have CSS variables, don’t we? #

CSS Custom Properties, better known as CSS Variables, officially became a W3C recommendation in 2015, making it safe for web page authors to use (with appropriate fallbacks for non-supporting browsers).

For the first time in CSS, these variables allowed us to create references to frequently-used values and use those references around our stylesheet instead. The references, or “variables”, were scoped to an element and created in a similar way to how we define normal property-value declarations.

button {
  --padding: 10px;
}

These variables could then be accessed using the var() notation.

button {
  padding-top: var(--padding);
}

Although these type of variables solved a lot of problems, they also had a few limitations.

Because CSS variables are scoped to an element, they are only accessible to that specific element, not globally. In order to make variables accessible to our whole stylesheet, we would have to apply the variables to the :root element. Since these variables are cascading, they will be available to all child elements.

:root {
  --colour-primary: #bae;
}

button {
  background-color: var(--colour-primary);
}

h1 {
  color: var(--colour-primary);
}

Another side-effect of the variables being scoped to an element is that they can’t be used outside CSS declarations. CSS variables can’t be used in other places such as with @media rules.

:root {
  --breakpoint: 600px;
}

@media (min-width: var(--breakpoint)) {
  /* Doesn't work :( */
}

Will not work

Finally, because CSS variables are cascading, the browser needs to be prepared for their value to change at any moment. This means that, even if they aren’t being changed, the browser will not be able to perform any optimisations to store the value in a permanent way.

Enter environment variables #

CSS environment variables were created as a solution to the constraints of the custom properties, also called “cascading variables”. They have three key differences to the cascading variables:

They are defined once, globally, and can never be changed
They can be used as any value to any property or @ rule, e.g. media queries
They can be defined by either the user agent or the stylesheet author

How environment variables are created #

CSS environment variables can either be created by the user-agent, or by the author of the stylesheet.

User-agent environment variables #

User agents, e.g. browsers, will be able to set their own environment variables. Currently, the only ones that exist are the safe area inset variables.

The safe area insets are four length variables, which create a rectangle on the screen, outlining the area that is safe for content to be placed within.

Variable Name	Value type
`safe-area-inset-top`	length
`safe-area-inset-right`	length
`safe-area-inset-bottom`	length
`safe-area-inset-left`	length

Author environment variables #

Although the specification says that stylesheet authors, i.e. web developers, will be able to create environment variables, how this will be done has not been decided on yet.

Using environment variables (today) #

A CSS environment variable is accessed using the env() notation. This notation accepts two values - the variable name, and a fallback value for if the variable wasn’t found.

env('VARIABLE_NME', FALLBACK_VALUE);

For example, we can use the safe area inset variables to apply padding to the body element and ensure all content is within a safe area.

body {
  padding-top: env(safe-area-inset-top, 12px);
  padding-right: env(safe-area-inset-right, 12px);
  padding-bottom: env(safe-area-inset-bottom, 12px);
  padding-left: env(safe-area-inset-left, 12px);
}

Support and progressive enhancement #

As I mentioned, the specification for CSS environment variables is still in Editor’s Draft, which means things will probably change. Despite this, the support for this feature is already at 70% and therefore can be used.

A good way to use this feature today is to rely on the cascade and use appropriate fallbacks.

body {
  /* No variables */
  padding-top: 12px;

  /* iOS Safari 11.2, Safari 11 */
  padding-top: constant(safe-area-inset-top, 12px);

  /* iOS Safari 11.4+, Safari 11.1+, Chrome 69+, Opera 56+ */
  padding-top: env(safe-area-inset-top, 12px);
}

Git aliases for lazy developers

2018-11-27T00:00:00Z

I prefer to interface with git via the command line, at least for the simple commands. However, I’m a bit lazy, and don’t like having to repeatedly type out the same long commands multiple times a day. Over the years, I have created some short aliases that allow me to more quickly use git via the command line.

How to create an alias #

Bash aliases allow us to set keywords that can trigger longer commands. They are defined in a .bash_profile or . bashrc, typically in the home directory for the user on the machine. For example, my .bash_profile lives in Macintosh HD > Users > ireaderinokun > .bash_profile .

A bash alias looks like this:

alias ALIAS_NAME="ALIAS_COMMAND"

The name can be whatever we want, as long as it isn’t already mapped to some other command. The command is what we want the alias to map to. For example, an alias to open up this website in Chrome could look like this:

alias bitsofcode="chrome https://bitsofco.de"

Then, in a new terminal window, if I type in bitsofcode, the URL will open in Chrome.

Lazy git aliases #

Now onto the aliases.

Commits #

The first alias I ever created was to shorten the process of adding all the unstaged changes and committing them with a particular message.

alias gac="git add . && git commit -m" # + commit message

To use this, I would type out the alias, plus the commit message I wanted.

gac "My commit message"

Initialising #

Another useful alias is initialising a repo with the "Initial commit" first commit message.

alias gi="git init && gac 'Initial commit'"

As you can see here, we can use other aliases within the commands for new aliases.

Pushing & pulling #

Pushing to remotes and pulling from remotes is another common command.

alias gp="git push" # + remote & branch names
alias gl="git pull" # + remote & branch names

To get even lazier, I created aliases for pushing from and pulling to the common origin remote and/or the common master branch.

# Pushing/pulling to origin remote
alias gpo="git push origin" # + branch name
alias glo="git pull origin" # + branch name

# Pushing/pulling to origin remote, master branch
alias gpom="git push origin master"
alias glom="git pull origin master"

Branches #

Finally, I have a few aliases for working with branches. To create create a new branch or checkout into an existing branch, I have the following aliases:

alias gb="git branch" # + branch name
alias gc="git checkout" # + branch name

To create a new branch and checkout into it, I have the following alias:

alias gcb="git checkout -b" # + branch name

You can view my .bash_profile on my Github dotfiles repository. What aliases do you have?

What, exactly, is the DOM?

2018-11-26T00:00:00Z

The Document Object Model, or the “DOM”, is an interface to web pages. It is essentially an API to the page, allowing programs to read and manipulate the page’s content, structure, and styles. Let’s break this down.

How is a web page built? #

How a browser goes from a source HTML document to displaying a styled and interactive page in the viewport is called the “Critical Rendering Path”. Although this process can be broken down into several steps, as I cover in my article on Understanding the Critical Rendering Path, these steps can be roughly grouped into two stages. The first stage involves the browser parsing the document to determine what will ultimately be rendered on the page, and the second stage involves the browser performing the render.

The result of the first stage is what is called a “render tree”. The render tree is a representation of the HTML elements that will be rendered on the page and their related styles. In order to build this tree, the browser needs two things:

The CSSOM, a representation of the styles associated with elements
The DOM, a representation of the elements

How is the DOM created (and what does it look like)? #

The DOM is an object-based representation of the source HTML document. It has some differences, as we will see below, but it is essentially an attempt to convert the structure and content of the HTML document into an object model that can be used by various programs.

The object structure of the DOM is represented by what is called a “node tree”. It is so called because it can be thought of as a tree with a single parent stem that branches out into several child branches, each which may have leaves. In this case, the parent “stem” is the root <html> element, the child “branches” are the nested elements, and the “leaves” are the content within the elements.

Let’s take this HTML document as an example:

<!doctype html>
<html lang="en">
 <head>
   <title>My first web page</title>
  </head>
 <body>
    <h1>Hello, world!</h1>
    <p>How are you?</p>
  </body>
</html>

This document can be represented as the following node tree:

html
- head
  - title
    - My first web page
- body
  - h1
    - Hello, world!
  - p
    - How are you?

What the DOM is not #

In the example I gave above, it seems like the DOM is a 1-to-1 mapping of the source HTML document or what you see your DevTools. However, as I mentioned, there are differences. In order to fully understand what the DOM is, we need to look at what it is not.

The DOM is not your source HTML #

Although the DOM is created from the source HTML document, it is not always exactly the same. There are two instances in which the DOM can be different from the source HTML.

1. When the HTML is not valid #

The DOM is an interface for valid HTML documents. During the process of creating the DOM, the browser may correct some invalidities in the HTML code.

Let’s take this HTML document for example:

<!doctype html>
<html>
Hello, world!
</html>

The document is missing a <head> and <body> element, which is a requirement for valid HTML. If we look at the resulting DOM tree, we will see that this has been corrected:

html
- head
- body
  - Hello, world!

2. When the DOM is modified by Javascript #

Besides being an interface to viewing the content of an HTML document, the DOM can also be modified, making it a living resource.

We can, for example, create additional nodes to the DOM using Javascript.

var newParagraph = document.createElement("p");
var paragraphContent = document.createTextNode("I'm new!");
newParagraph.appendChild(paragraphContent);
document.body.appendChild(newParagraph);

This will update the DOM, but of course not our HTML document.

The DOM is not what you see in the browser (i.e., the render tree) #

What you see in the browser viewport is the render tree which, as I mentioned, is a combination of the DOM and the CSSOM. What really separates the DOM from the render tree, is that the latter only consists of what will eventually be painted on the screen.

Because the render tree is only concerned with what is rendered, it excludes elements that are visually hidden. For example, elements that have display: none styles associated to them.

<!doctype html>
<html lang="en">
  <head></head>
  <body>
    <h1>Hello, world!</h1>
    <p style="display: none;">How are you?</p>
  </body>
</html>

The DOM will include the <p> element:

html
- head
- body
  - h1
    - Hello, world!
  - p
    - How are you?

However, the render tree, and therefore what is seen in the viewport, will not include that element.

html
- body
  - h1
    - Hello, world!

The DOM is not what is in DevTools #

This difference is a bit more minuscule because the DevTools element inspector provides the closest approximation to the DOM that we have in the browser. However, the DevTools inspector includes additional information that isn’t in the DOM.

The best example of this is CSS pseudo-elements. Pseudo-elements created using the ::before and ::after selectors form part of the CSSOM and render tree, but are not technically part of the DOM. This is because the DOM is built from the source HTML document alone, not including the styles applied to the element.

Despite the fact that pseudo-elements are not part of the DOM, they are in our devtools element inspector.

This is why pseudo-elements cannot be targetted by Javascript, because they are not part of the DOM.

Recap #

The DOM is an interface to an HTML document. It is used by browsers as a first step towards determining what to render in the viewport, and by Javascript programs to modify the content, structure, or styling of the page.

Although similar to other forms of the source HTML document, the DOM is different in a number of ways:

It is always valid HTML
It is a living model that can be modifed by Javascript
It doesn't include pseudo-elements (e.g. ::after)
It does include hidden elements (e.g. with display: none)

How to upload a screenshot from Puppeteer to Cloudinary

2018-11-23T00:00:00Z

In my article yesterday, I wrote about the problem I was trying to solve with my caniuse embed. To recap, I was trying to create a fallback image for the live embed and I did this by taking a screenshot of the page using puppeteer.

Yesterday, I covered how to use headless Chrome, via Puppeteer, to capture that screenshot. The next thing I needed to do was upload the screenshot to my Cloudinary (affiliate link) account in order to have a hosted image that could be referenced.

This is quite a specific problem I had to solve, but I couldn’t find any examples or documentation of how to do it, so I thought it would be useful to share the process.

Save the screenshot as a buffer #

Using Puppeteer, we can capture a screenshot and save it to disk using the page.screenshot() method. However, in my use case, I didn’t need to save the image to the file system. Instead, I wanted to capture it as a buffer, which could then be uploaded to Cloudinary.

The page.screenshot() method returns a buffer, so all we need to do is save it.

const screenshotBuffer = await page.screenshot({
    encoding: 'binary',
    // other options...
});

// Do something with screenshotBuffer

Upload the stream to Cloudinary #

Next, we need to upload the buffer to Cloudinary. The Cloudinary node module has a specific method for uploading images as streams, the upload_stream method.

const cloudinary = require('cloudinary').v2; // Make sure to use v2

cloudinary.config({
  cloud_name: YOUR_CLOUDINARY_CLOUD_NAME,
  api_key: YOUR_CLOUDINARY_API_KEY,
  api_secret: YOUR_CLOUDINARY_API_SECRET
});

cloudinary.uploader.upload_stream(
  uploadOptions,
  (error, result) => { /* Do something with result! */ }
).end(screenshotBuffer);

If successful, the result will be an object with information about the image, such as the url!

Putting it all together in an API #

Since we are working with private keys and API secrets, all of this should ideally be done server-side. I created a simple express application to handle everything from taking the screenshot to uploading the image, then returning the resulting image data from Cloudinary.

You can view the full API on my GitHub repository, caniuse-embed-screenshot-api, but here's a stripped-down version of the basic functionality:

/* main.js */
const express = require("express");
const app = express();

const puppeteer = require('puppeteer');
const cloudinary = require('cloudinary').v2;
cloudinary.config(/* config here */);

// Create an express route
app.post("/upload", (req, res) => {
  takeScreenshot()
    .then((screenshot) => uploadScreenshot(screenshot))
    .then((result) => res.status(200).json(result));
});

// See https://bitsofco.de/using-a-headless-browser-to-capture-page-screenshots
async function takeScreenshot() {
  const browser = await puppeteer.launch({
    defaultViewport: {
      width: 800,
      height: 800,
      isLandscape: true
    }
  });

  const page = await browser.newPage();

  await page.goto(
    embedUrl,
    { waitUntil: 'networkidle2' }
  );

  const screenshot = await page.screenshot({
    omitBackground: true,
    encoding: 'binary'
  });

  await browser.close();

  return screenshot;
}

function uploadScreenshot(screenshot) {
  return new Promise((resolve, reject) => {
    const uploadOptions = {};
    cloudinary.uploader.upload_stream(uploadOptions, (error, result) => {
      if (error) reject(error)
      else resolve(result);
    }).end(screenshot);
  });
}

Using a headless browser to capture page screenshots

2018-11-22T00:00:00Z

A headless browser is a browser without the graphical user interface. It is a way to navigate the web via the command line.

Headless browsers are useful for automating tests of websites as it allows us to navigate to a page and perform actions without having to manually open up a browser and click around. Another great use of headless browsers is to take screenshots of web pages dynamically.

What am I trying to achieve? #

A couple of years ago, I created an embed for caniuse data of any particular feature. Here’s an example of how this looks:

In case you are interested, I wrote about how I created the embed. One thing that always bothered me about it is that was dependent on Javascript to display any data. If for whatever reason Javascript was disabled, or even if the network was slow, this is what would be displayed:

This is because, until the script generates the iframe, the embed code looks like this:

<p class="ciu_embed" data-feature="css-grid" data-periods="future_1,current,past_1,past_2" data-accessible-colours="false">
    <a href="https://caniuse.com/#feat=css-grid">Can I Use css-grid?</a>
    Data on support for the css-grid feature across the major browsers from caniuse.com.
</p>

I had been thinking about how to solve this problem for a while, and finally settled that the best solution would be to programmatically take a screenshot of the embed page using a headless browser and adding that to the fallback code.

In order to achieve this end result, I had to go through a few steps:

Generate a screenshot of the embed page
Create an API to handle the image generation and upload the image to Cloudinary
Update the fallback code to include the screenshot

In this article, I will cover the first part of this solution, which is using a headless browser to create a screenshot of the page.

Headless Chrome #

Since version 59, headless Chrome has been available via the chrome command (Note: you may need to add an alias to use the command).

To get the DOM contents of a page, for example, we can use the --dump-dom flag.

chrome --headless --disable-gpu --dump-dom https://bitsofco.de

To take a screenshot, we can use the --screenshot flag instead.

chrome --headless --disable-gpu --screenshot https://bitsofco.de

Puppeteer - A headless Chrome node API #

Puppeteer brings the power of headless chrome to a simple node API, enabling us to use headless chrome almost anywhere.

To take a screenshot using Puppeteer, we have to go through four steps:

Launch the browser
Open a new page
Navigate to the chosen URL
Take a screenshot

Here is how that looks:

const puppeteer = require('puppeteer');

(async () => {

  // 1. Launch the browser
  const browser = await puppeteer.launch();

  // 2. Open a new page
  const page = await browser.newPage();

  // 3. Navigate to URL
  await page.goto('https://bitsofco.de');

	// 4. Take screenshot
  await page.screenshot({path: 'screenshot.png'});

  await browser.close();
})();

This will take a screenshot of the page, https://bitsofco.de, and save a PNG file to the current directory with the name screenshot.png.

Taking a screenshot for the embed #

For my use case, I needed to take a screenshot of the embed and save it as binary data, to later be uploaded to Cloudinary (affiliate link). To do that, I had to make a few modifications to the default example from above.

Defining the browser viewport #

By default, Puppeteer will use a 800px by 600px viewport size for the browser. To change this, we can manually set the height and width of the viewport we prefer in options passed to puppeteer.launch().

const browser = await puppeteer.launch({
    defaultViewport: {
        width: 800,
        height: 500,
        isLandscape: true
    }
});

We can also set if the viewport is in landscape mode with the isLandscape boolean.

Waiting for page load #

When the embed page is initially loaded, all that exists is some text that lets the user know that the data is being fetched. When we take the screenshot, we need to make sure that the page has fully loaded.

We can specify when puppeteer will take the screenshot with options passed to page.goto().

await page.goto(
    pageUrl,
    { waitUntil: 'networkidle2' }
);

The networkidle2 value means that puppeteer will consider the page fully loaded when there are no more than 2 network connections for at least 500ms.

Removing the background #

Finally, we only want to capture the embed on the page, omitting any white background. We can do this by passing an option to the page.screenshot() method.

await page.screenshot({
    omitBackground: true
});

In my article tomorrow, I will cover the next step in solving this problem - How to upload a screenshot from Puppeteer to Cloudinary.

Why and how to use WebP images today

2018-11-21T00:00:00Z

WebP is an image format developed by Google in 2010. It was created to be an alternative to formats like PNG and JPG, producing much smaller file sizes while maintaining similar image qualities.

Why use WebP? #

WebP is an incredibly useful format because it offers both performance and features. Unlike other formats, WebP supports both lossy and lossless compression, as well as transparency and animation.

	WebP	PNG	JPG	GIF
Lossy compression	✓	✓	✓	✗
Lossless compression	✓	✓	✓	✓
Transparency	✓	✓	✗	✓
Animation	✓	✗	✗	✓

Even with these features, WebP provides consistently smaller file sizes than its alternatives. In a comparative study of these image formats, it was found that WebP lossy images were on average 30% smaller than JPGs and WebP lossless images were on average 25% smaller than PNG.

How to covert images to the WebP format #

There are several tools we can use to convert our JPGs, PNGs, and other file formats to WebP.

Online tools #

Squoosh - Online image compression and conversion
Online-Convert.com - Online image conversion

Command line tools #

cwebp is the most popular command line tool for converting images to the WebP format. Once installed, we can use it to convert images by passing in, among other options, a quality, input file, and output file.

# cwebp -q [quality] [input_file] -o [output_file]

cwebp -q 75 image.png -o image.webp

Node tools #

imagemin, and it's plugin imagemin-webp, is the most popular node library for converting images to the WebP format.

Below is an example script that will convert all PNG and JPG files in the directory to WebP.

/* convert-to-webp.js */

const imagemin = require("imagemin");
const webp = require("imagemin-webp");

imagemin(["*.png", "*.jpg"], "images", {
  use: [
    webp({ quality: 75})
  ]
});

We can then use this script via the command line, or via build tool

node convert-to-webp.js

Sketch #

In Sketch, we can export any slice in the WebP image format.

How to use to WebP on the web today #

At the time of writing, WebP is supported in 72% of browsers globally used.

Although this is good enough to make a compelling case to use WebP, it isn’t good enough to rely on the format without providing fallbacks. In browsers that don’t support this file format, the image will appear broken.

We can provide fallbacks to images using the <picture> element. This HTML5 element allows us to provide multiple sources for a single image.

<picture>
    <source type="image/webp" srcset="image.webp">
    <source type="image/jpeg" srcset="image.jpg">
    <img src="image.jpg" alt="My Image">
</picture>

To provide an alternate image source, we use the <source> element within the <picture> element. The <source> element has a number of attributes we can use to define the image and when it should be used:

type: The MIME type of the source
srcset: The path to the image file. Multiple files can be used to provide different image sizes/densities (see Responsive Images - The srcset and sizes Attributes)
sizes: A list of sizes of each source file (see article above)
media: A media query that will determine when the image is used (see article above)

In addition to the various <source>s, a regular <img> element must also be provided as a fallback for browsers that do not support multiple file formats via the <picture> element.

Web workers vs Service workers vs Worklets

2018-11-20T00:00:00Z

Web workers, service workers, and worklets. All of these are what I would call “Javascript Workers”, and although they do have some similarities in how they work, they have very little overlap in what they are used for.

Broadly speaking, a worker is a script that runs on a thread separate to the browser’s main thread. If you think about your typical Javascript file that is included in your HTML document via a <script> tag, that runs on the main thread. If there is too much activity on the main thread, it can slow down the site, making interactions jittery and unresponsive.

Web workers, service workers, and worklets are all scripts that run on a separate thread. So what are the differences between these three types of workers?

Web workers #

Web workers are the most general purpose type of worker. Unlike service workers and worklets as we will see below, they do not have a specific use case, other than the feature of being run separately to the main thread. As a result, web workers can be used to offload pretty much any heavy processing from the main thread.

Web workers are created using the Web Workers API. After creating a dedicated Javascript file for our worker, we can add it as a new Worker.

/* main.js */

const myWorker = new Worker('worker.js');

This will start to run whatever code we have in the worker.js file. As I mentioned, this can be almost anything, but web workers are most useful for offloading processes that might take a long time or are run in parallel to other processes. A great example is the image processing web application, Squoosh, which uses web workers to handle image manipulation tasks, leaving the main thread available for the user to interact with the application without interruption.

Like all workers, web workers do not have access to the DOM, which means that any information needed will have to be passed between the worker and the main script using window.postMessage().

/* main.js */

// Create worker
const myWorker = new Worker('worker.js');

// Send message to worker
myWorker.postMessage('Hello!');

// Receive message from worker
myWorker.onmessage = function(e) {
  console.log(e.data);
}

In our worker script, we can listen for messages from the main script, and return a response.

/* worker.js */

// Receive message from main file
self.onmessage = function(e) {
  console.log(e.data);

  // Send message to main file
  self.postMessage(workerResult);
}

Service workers #

Service workers are a type of worker that serve the explicit purpose of being a proxy between the browser and the network and/or cache.

Like web workers, service workers are registered in the main javascript file, referencing a dedicated service worker file.

/* main.js */

navigator.serviceWorker.register('/service-worker.js');

Unlike regular web workers, service workers have some extra features that allow them to fulfil their proxy purpose. Once they are installed and activated, service workers are able to intercept any network requests made from the main document.

/* service-worker.js */

// Install
self.addEventListener('install', function(event) {
    // ...
});

// Activate
self.addEventListener('activate', function(event) {
    // ...
});

// Listen for network requests from the main document
self.addEventListener('fetch', function(event) {
    // ...
});

Once intercepted, a service worker can, for example, respond by returning a document from the cache instead of going to the network, thereby allowing web applications to function offline!

/* service-worker.js */

self.addEventListener('fetch', function(event) {
    // Return data from cache
    event.respondWith(
        caches.match(event.request);
    );
});

Worklets #

Worklets are a very lightweight, highly specific, worker. They enable us as developers to hook into various parts of the browser’s rendering process.

When a web page is being rendered, the browser goes through a number of steps. I cover this in more detail in my article on Understanding the Critical Rendering Path, but there are four steps we need to worry about here - Style, Layout, Paint, & Composite.

Image credit: Rendering Performance, by Paul Lewis

Let’s take the Paint stage. This is where the browser applies the styles to each element. The worklet that hooks into this stage of rendering is the Paint Worklet.

The Paint Worklet allows us to create custom images that can be applied anywhere CSS expects an image, for example as a value to the background-image property.

To create a worklet, as with all workers, we register it in our main javascript file, referencing the dedicated worklet file.

/* main.js */

CSS.paintWorklet.addModule('myWorklet.js');

In our worklet file, we can create the custom image. The paint method works very similarly to the Canvas API. Here’s an example of a simple black-to-white gradient.

/* myWorklet.js */

registerPaint('myGradient', class {
  paint(ctx, size, properties) {
    var gradient = ctx.createLinearGradient(0, 0, 0, size.height / 3);

    gradient.addColorStop(0, "black");
    gradient.addColorStop(0.7, "rgb(210, 210, 210)");
    gradient.addColorStop(0.8, "rgb(230, 230, 230)");
    gradient.addColorStop(1, "white");

    ctx.fillStyle = gradient;
    ctx.fillRect(0, 0, size.width, size.height / 3);
  }
});

Finally, we can use this new worklet in our CSS, and the custom image we created will be applied like any other background image.

div {
    background-image: paint(myGradient);
}

In addition to the Paint Worklet, there are other worklets that hook into other stages of the rendering process. The Animation Worklet hooks into the Composite stage, and the Layout Worklet hooks in to the Layout stage.

Recap #

To recap, web workers, service workers, and worklets are all scripts that run on a separate thread to the browser’s main thread. Where they differ is in where they are used and what features they have to enable these use cases.

Worklets are hooks into the browser’s rendering pipeline, enabling us to have low-level access to the browser’s rendering processes such as styling and layout.

Service workers are a proxy between the browser and the network. By intercepting requests made by the document, service workers can redirect requests to a cache, enabling offline access.

Web workers are general-purpose scripts that enable us to offload processor-intensive work from the main thread.

You might not need a loop

2018-11-19T00:00:00Z

In JavaScript, like any other language, there are several ways to achieve the same result, some being more suited to certain situations than others. One of the first concepts I learned about when learning to code was loops, and it seemed like the answer to almost everything.

Although loops are great for a lot of use cases, the JavaScript language has provided a suite of methods that can be used to achieve similar results in a more targeted, and sometimes more performant, way.

In this article, I want to cover some examples of where Array methods can be used to replace for loops (and by extension the forEach() method).

Modifying data with `map()` #

If we want to perform an action on each item in an array and generate a new array with the resulting items, the map() is a great option.

The map() method is available on any Array and has three parameters - the current item in the array, the index (optional), and the original array (optional). Within the callback function, we can return whatever value we want to make up the new array that the map() function returns.

const newArray = myArray.map((current, index, array) => {
    // return item for newArray
})

Let’s take the example of the following array of articles, each with a title and rating property:

const articles = [
    { title: 'You might not need a loop', rating: 4 },
    ...
];

Let’s say we wanted to create a new array, but with each of the articles rated as 5 stars. We could do this using a basic for loop, which could look something like this:

const amazingArticles = [];

for (let i = 0; i < articles.length; i++) {
    const newArticle = Object.assign(articles[i], {rating: 5});
    amazingArticles.push(newArticle);
}

Although this yields the result we want, this logic could be better served by using the .map() method instead.

const amazingArticles = articles.map((article) => {
    return Object.assign(article, {rating: 5});
});

Filtering data with `filter()` #

Sometimes, we want to ascertain whether and which items within an array satisfy a particular condition. We can do this with the filter() method.

The filter() method, like map(), has three parameters - the current item in the array, the index (optional), and the original array (optional). Unlike map(), what is returned is a boolean which determines whether or not to keep the item in the new array the filter() method returns.

const newArray = myArray.filter((current, index, array) => {
    // return true or false
});

Let’s take the example of the array of articles from before. What if we wanted to get all the articles in the array that are rated 3 and above? Again, we could do this with a for loop, but the filter() method is more suitable.

const highlyRatedArticles = articles.filter((article) => {
    return article.rating >= 3;
});

Testing conditions with `every()` and `some()` #

With the filter() method, we can determine which items within an array satisfy a particular condition. But sometimes, we don’t need to know which items do or don’t satisfy the condition, we may just need to know if all or any of the items satisfy the condition. This is where the every() and some() methods come into play.

The every() and some() methods function very similarly to filter() method. They have the same parameters, and their callback function expects a boolean to be returned to determine whether the item meets the condition.

const every = myArray.every((current, index, array) => {
    // return true or false
});

const some = myArray.some((current, index, array) => {
    // return true or false
});

The key difference between these methods and filter() are in what the methods themselves return, i.e. in the above example what the values of the every and some variables would be.

Where the filter() method returns a new array of elements that meets the condition, the every() and some() methods return booleans.

The every() method will return true is every item within the array satisfies the condition. If only one item does not satisfy the condition, it will instead return false. The some() method, on the other hand, will return true if at least one item within the array satisfies the condition.

To loop or not to loop? #

As I mentioned earlier, loops are a great tool for a lot of cases, and the existence of these new methods doesn't mean that loops shouldn't be used at all.

I think these methods are great because they provide code that is in a way self-documenting. When we use the filter() method instead of a for loop, it is easier to understand at first glance what the purpose of the logic is.

However, these methods have very specific use cases and may be overkill if their full value isn't being used. An example of this is the map() method, which can technically be used to replace almost any arbitray loop. If in our first example, we only wanted to modify the original articles array and not create a new, modified, amazingArticles, using this method would be unnecessary. It's important to use the method that suits each scenario, to make sure that we aren't over- or under-performing.

Highlights from Chrome Dev Summit 2018

2018-11-16T00:00:00Z

Earlier this week, I was able to attend Chrome Dev Summit in San Francisco. This was my second time attending the event, the first being in 2016 (you can read about my highlights from that event too). This year's event was one of the best tech conferences I’ve been to in a while, jam-packed with well-thought out sessions and amazing people.

I learned a lot from the sessions and will likely write about some of the topics in more detail, but I wanted to share a few of the projects and topics I found the most interesting.

In 2016, Jake Archibald previewed a highly speculative API that could enable page transitions in the way native mobile applications do, with a new navigate event on the window. Although the specification as Jake presented it two years ago never came to fruition, the idea was continued and re-imaged.

Portals are the new proposal for seamless page transitions on the web. A <portal> element is similar to an <iframe>, but is always top-level and can be navigated into and out of. The proposal is still in its early stages and will likely change, but here’s how it could work.

First, we create a new portal element on the page. This can be created via the <portal> HTML element itself or via JavaScript.

<portal id="myPortal" src="https://bitsofco.de"></portal>

Next, we can respond to a users click (or any) event by animating the portal window in any way we like. It wasn’t clear from the presentation or the documentation exactly how the animations would work, so hopefully that is something that will be cleared up soon.

navigateButton.addEventListener(('click') => {
  // insert fancy animations here
});

Finally, we activate the new portal, replacing the current top-level browsing context with the portal.

navigateButton.addEventListener(('click') => {
  // ...

	myPortal.activate();
});

Like Jake's original proposal, Portals may not be the answer to our problem of navigating on the web, but I’m happy that there are some proposals being put forth to get us that much closer to the actual solution.

Squoosh - A 15kb JS-powered web application #

My favourite session of the conference was Jake and Mariko’s talk on how they built Squoosh, a web application for image compression. I would highly recommend you watch it yourself, as they go into great detail on all the steps they took and best practices they followed to ensure that the app was only 15kb on first load!

To do this, they leveraged on a number of tools, technologies, and best practices, including:

Preact as a lightweight, 3kb framework
Webpack for code splitting
Web Workers for parallel tasks
Dynamically importing Javascript modules

Unified performance analysis with PageSpeed and Lighthouse APIs #

Historically, measuring the performance of a website was split among various tools that could (and probably would) give differing results. Going forward, all of Google’s tooling for measuring performance across all the various products will now be backed by the new PageSpeed API (version 5), which is essentially a Lighthouse API.

Although the various products could still be useful at different stages -PageSpeed Insights for Benchmarking, the Lighthouse CLI for development, the Search Console for SEO monitoring - they are now all powered by the same testing tool and will deliver the same reliable results.

Native lazyloading in Chrome #

Chrome will soon support a lazyload attribute on resources such as images! This attribute will tell the browser to only load the resource when it is needed, for example when it is scrolled into view.

<img lazyload src="path/to/image.png">

This is already available in Internet Explorer and Edge, but it’s great to see it come to more browsers. Right now, this feature can be enabled in Chrome behind a flag (chrome://flags/#enable-lazy-image-loading)

There were many more talks with many more bits of useful information I didn’t mention here. As always, you can re-watch all the sessions on the Chrome Developers YouTube Channel.

What is First Input Delay?

2018-11-15T00:00:00Z

There are a lot of metrics we can use to measure the performance of a website - FP, FMP, FCP, TTI, TTYL (JK :P). Although these metrics can be overwhelming at first, it isn’t necessary for every site to track every single one. Different metrics may be more important for different types of websites.

For a content-driven website such as this blog, First Contentful Paint & First Meaningful Paint are the primary metrics I track. FCP refers to the point at which the browser renders any information from the DOM. This could be an image, some text, anything. FMP, on the other hand, is about the point at which the first useful bit of content is rendered on the screen. This is usually the hero section of the page, for example on this blog it could be the title and first sentence or two of an article.

Other metrics could be more important for other types of sites. Take a form, for example, where the primary purpose of the site is for a user to fill out some information. A metric such as Time to Interactive would be crucial. TTI refers to the point at which a user can reliably interact with the content on the website, such as clicking links or entering text into input fields.

First Input Delay #

FID is a metric that tracks the delay between the time a user can attempt to interact with a part of the site, and the time that the interface is able to respond to that interaction. We have all experienced situations where a web page has visibly loaded and we try to click around on buttons or any Javascript-powered interactive elements, but nothing responds. This delay is what the FID metric tracks.

The FID metric is in someways an intersection of the First Contentful Paint and Time to Interactive metrics. It lies in the middle of those two points, measuring the time between the FCP (and therefore when a first input can be made) and when the browser’s main thread is able to respond to any interactions.

Paul Irish at Chrome Dev Summit 2018

What causes a slow First Input Delay? #

A slow(er) FID can be caused when the browser’s main thread is busy parsing and executing a significant amount of Javascript after the page content has already loaded. The key point here is that there is visible content on the page that the user may try to interact with, but the browser is not able to respond yet.

If we think of classic client-rendered single page applications, they typically wouldn’t suffer from this issue because nothing meaningful shows on the page until the entire application Javascript is loaded.

In these cases, they have a poor First Meaning Paint, but a low or inexistent First Input Delay. Server-rendered single page applications, on the other hand, have the opposite problem. Because they are rendered by the server, they typically have a comparatively fast First Meaningful Paint. However, because they need the application Javascript to be loaded before the user can properly interact with the site, they are a prime candidate for slow First Input Delay.

Tracking First Input Delay #

FID can be measured using Google’s tracking library. This library exposes the perfMetrics object, which tracks FID with the onFirstInputDelay() method.

perfMetrics.onFirstInputDelay(function(delay, evt) {
	console.log(delay);
});

With the delay response, you can track it by sending it to tools like Google Analytics or whatever else you use.

Learning to write again

2018-11-14T00:00:00Z

Last weekend, I attended the Google Developers Experts Summit in Sunnyvale, California. During the summit, some GDEs delivered quick, 5-minute lightning talks on interesting projects or experiences they had over the course of their career.

As you would expect, there were a lot of interesting people doing a lot of interesting things, but the talk that stood out to me the most was Uri Shaked’s talk on his one-blog-a-day challenge. For 30 days, he challenged himself to write a blog post on just about anything.

This challenge really spoke to me because, as I have mentioned a few times on social media, I’ve found it increasingly difficult to write as much as I would like and as much as I used to. There are two main reasons for this:

The first is that I felt like I couldn’t write shorter, less deeply technical articles. Since my blog grew and gained more readership, I felt like my readers would want the more long-form and very technical articles. I recently came across an article Sara Soueidan wrote, in which she very aptly explained this feeling:

With time, people got used to my writing style, and my lengthy, detailed deep dives that sort of became a distinguishing quality of my articles. So as the years went by, I started judging the quality of my articles by whether or not they match my previous style, and hence whether or not people would like them. And this is where I felt like I started losing my direction.

When I first started this blog, the aim was to share little “bits of code” (get it?) that I was learning. It was meant to be a resource for myself, as writing is a great way to consolidate knowledge, but also as a resource for other developers who were learning like me. Although writing the longer articles isn’t a negative progression, I started being afraid of doing the what I started out with. And this became a hinderance to me writing anything at all.

The second reason is that I felt like I needed to stay in the “HTML, CSS, & JavaScript” box. Although these are still my primary technologies, a large amount of my day job and hobbies include venturing outside these foundational languages. At BuyCoins, I work with the Ionic framework (and as a result Angular) and there are so many things I have learned from working with these technologies that I could share, but chose not to because I felt like my blog should maintain it’s topic. Even outside frontend development, I would like to explore other topics in technology, and experiences learning them.

30 articles in 30 days (sort of) #

In order to get out of this rut and force myself to just write again, I want to try Uri’s one-blog-a-day challenge. I’m going to challenge myself to write 5 articles every week for the next 30 days. Most of the articles will be short, the aim is less than 500 words each day. Some of the articles will be on topics I haven’t covered before.

If you want to join in with me, leave a comment below with your blog URL, I’d love to check out what you’re writing too!

I'm counting this article as the first of 30, so I'll see you here again tomorrow :)

Understanding the difference between grid-template and grid-auto

2018-10-09T00:00:00Z

With all the new properties related to CSS Grid Layout, one of the distinctions that always confused me was the difference between the grid-template-* and grid-auto-* properties. Specifically the difference between grid-template-rows/columns and grid-auto-rows/columns. Although I knew they were to do with the explicit and implicit grid systems, at face value they seemed to be doing almost the same thing. In actual fact, they have little in common and are used to achieve different things.

What are explicit and implicit grids? #

To understand the difference between the grid-template-* and grid-auto-* properties we first need to understand the difference between the explicit and implicit grids.

The definitions of explicit and implicit grids can be a bit circular. The explicit grid, for example, is defined by the property used to create the explicit grid - the grid-template-* properties. According to the W3C Candidate Recommendation:

The three properties grid-template-rows, grid-template-columns, and grid-template-areas together define the explicit grid.

The implicit grid, on the other hand, is essentially defined as "everything else" -

When grid items are positioned outside of [the explicit grid], the grid container generates implicit grid tracks by adding implicit grid lines to the grid. These lines together with the explicit grid form the implicit grid.

Although these definitions may be a bit difficult to conceptualise at first, it can be helpful to rephrase it.

Within a grid container, there are grid cells. Any cell positioned and sized using the grid-template-* properties forms part of the explicit grid. Any grid cell that is not positioned/sized using this property forms part of the implicit grid instead.

How do the grid-template and grid-auto properties differ? #

Because the structure and syntax of the grid-template-* and grid-auto-* property names have some similarities, it can be easy to think the values they accept and therefore what they achieve, are similar as well. On the contrary, these properties are doing very different things.

While the grid-template-* properties are used to define both the position and size of grid cells, the grid-auto-* properties are used only to define the size of grid cells.

This difference becomes apparent when you consider what these properties are for. The grid-template-* properties are used to create an explicit grid, whereas th grid-auto-* properties are used to size an implicit grid (which is automatically created).

How grid-template works #

There are four grid-template-* properties - grid-template-rows, grid-template-columns, grid-template-areas, and grid-template - the last being a shorthand for the first three. For the purpose of this article, I'm going to focus on the first two.

Let's take grid-template-rows. If we want to create a grid with one row of 100px height, we would use the following CSS -

.grid {
	display: grid;
	grid-template-rows: 100px;
}

If we want to add another row, we simply add another length value, space-separated to the first.

.grid {
	display: grid;
	grid-template-rows: 100px 100px;
}

We can do the same for columns using the grid-template-columns property.

Although there are several ways to define the height/width of each row/column using the grid-template-* properties, there is always a one-to-one match between a value and a track. As I showed in the example above, each space-separated length value represents a single row. This is how the grid-template-* properties are used to, not only define sizing, but position and layout of the grid cells.

How grid-auto works #

There are three grid-auto-* properties - grid-auto-rows, grid-auto-columns, and grid-auto-flow. For the purpose of this article, I'm going to focus on the first two.

The grid-auto-rows and grid-auto-columns properties accept a single length value, which is used to define the size of any implicit grid cells. For example, we can define that any implicit grid rows should have a height of 100px -

.grid {
	display: grid;
	grid-auto-rows: 100px;
}

Unlike the grid-template-* properties, the grid-auto-* properties only accept a single length value.

Working with explicit and implicit grids #

To better understand the difference between the grid-template-* and grid-auto-* properties, and therefore explicit & implicit grids, let's take the following HTML -

<div class="grid">
  <div class="cell">Cell 1</div>
  <div class="cell">Cell 2</div>
  <div class="cell">Cell 3</div>
  <div class="cell">Cell 4</div>
  <div class="cell">Cell 5</div>
  <div class="cell">Cell 6</div>
  <div class="cell">Cell 7</div>
  <div class="cell">Cell 8</div>
</div>

And the following CSS -

.grid {
	display: grid;
	grid-gap: 10px; /* add spacing for better visibility */
}

Currently, our grid looks like this -

Although it may seem like nothing has happened, an implicit grid has actually been created. This grid has a single column and as many rows as there are grid cells. We can see this if we use the grid inspector in Firefox.

Sizing the implicit grid with `grid-auto` #

If we wanted to specify the size of the height of these rows, we can use the grid-auto-rows property.

.grid {
	display: grid;
	grid-gap: 10px; /* add spacing for better visibility */
	grid-auto-rows: 30px;
}

Note that all we have done is given a single height value, and this style is applied to all rows within the grid.

Creating an explicit grid with `grid-template` #

Now let's define an explicit grid. We can create an explicit grid that has two rows, each with a height of 100px -

.grid {
  display: grid;
  grid-gap: 10px; /* add spacing for better visibility */
  grid-auto-rows: 30px;
  grid-template-rows: 100px 100px;
}

What we can see is that only the first two rows have the height of 100px, and the rest have the height defined by the grid-auto-rows property. We can more clearly see the distinction between the explicit and implicit grids in the image below -

Summary #

To summarize, the grid-template-* properties are used to create, place, and size cells for the explicit grid. Any cell that exists in the grid that is not explicitly created by this property forms part of the implicit grid, which can be sized by the grid-auto-* properties.

[Smashing Magazine] Creating The Feature Queries Manager DevTools Extension

2018-05-23T00:00:00Z

While working with feature queries, I requently find myself in the messy situation of trying to test my fallbacks layout. This lead me to create the Feature Queries Manager, a developer tools extension that lets you easily toggle styles behind feature queries.

I recently wrote an article for Smashing Magazine about why and how I created this extension. Read the article on Smashing Magazine.

How display: contents; Works

2018-03-27T00:00:00Z

As I frequently mention, every element in the document tree is a rectangular box. Broadly speaking, this "rectangular box" consists of two sections. First we have the actual box, which consists of the border, padding, and margin areas. Second, we have the contents of the box; the content area.

With the CSS display property, we can control different things about how this box and its children are drawn on the page. We can have the box be placed within its siblings like text with inline. We can even trick the box into behaving like a table with table.

There are only two values for the display property which control whether an element defined in the markup will generate a box at all. The none value will result in neither the box or its contents being drawn on the page. The newly specced contents value, on the other hand, will result in the contents of the box being drawn as normal, but the surrounding box being omitted entirely.

What happens when you use `display: contents`? #

The easiest way to understand what happens when display: contents is used is to imagine the element’s opening and closing tags being omitted from the markup. In the specification, it states -

For the purposes of box generation and layout, the element must be treated as if it had been replaced in the element tree by its contents

Let's take, for example, the following markup -

<div class="outer">
  I’m some content
  <div class="inner">I’m some inner content</div>
</div>

And the following styles -

.outer {
  border: 2px solid lightcoral;
  background-color: lightpink;
  padding: 20px;
}

.inner {
  background-color: #ffdb3a;
  padding: 20px;
}

Typically, this is how we would expect the elements to be drawn on the page -

However, if we add display: contents to the .outer element, this is how it is displayed -

Visually speaking, the above result is exactly the same as what we would expect if the markup was written without the opening and closing tags of the outer element.

I’m some content
<div class="inner">I’m some inner content</div>

What about…? #

This CSS rule, although seemingly straightforward, has quite a few edge cases and specific behaviours to take note of. We have to remember that the display: contents rule only affects the box being visually drawn on the page; it does not affect the markup within the document.

What about the element’s attributes? #

If the element is effectively replaced by its contents, what does that mean for any attributes applied to it? Since this replacement is, for the most part, visual only, we can actually still select, target, and interact with the element using its attributes.

We can still target the element by its ID by, for example, making a reference to it using aria-labelledby.

<div id="label" style="display: contents;">Label here!</div>
<button aria-labelledby="label"><button>

However, the one thing I have found that doesn't work properly is that we can no longer navigate to the element using a fragment identifier.

<div id="target" style="display: contents;">Target Content</div>

<script>
  window.location.hash = "target";
  // => Nothing happens
</script>

What about JavaScript events? #

As we have just covered, we can still target an element with display: contents applied to it. In fact, we can target an element with display: none applied, but the event will never trigger because we cannot interact with the element. However, since the contents of an element with display: contents are still visible, we can interact with the element through its contents.

If we set an event listener for a click on the element, for example, and log the value of this, we will still get the outer element because it still exists in the document.

<div class="outer">I’m some content</div>

<script>
  document.querySelector(".outer").addEventListener("click", function(event) {
    console.log(this);
    // => <div class="outer"></div>
  });
</script>

What about pseudo-elements? #

The pseudo-elements of an element with display: contents are considered to be part of its children, so are displayed as normal.

<style>
  .outer { display: contents; }
  .outer::before { content: "Before" }
  .outer::after { content: "After" }
</style>

<div class="outer">I’m some content</div>

The above markup will generate the following result -

What about form elements, images and other replaced elements? #

Replaced elements and some form elements have a different behaviour when display: contents is applied to them.

Replaced elements #

Replaced elements are elements, such as images, whose appearance and "boxes" are controlled by an external resource. Attempting to remove the box for elements like this doesn't really make sense because it isn't entirely clear what the "box" is. For these elements, display: contents functions exactly like display: none. The entire box and contents of the element are not drawn on the page at all.

Form elements #

For many form elements, they are not composed of a single "box". They look like that from the perspective of us, the web page authors. But under the hood, they are made up of several smaller elements. Similarly to the replaced elements, it doesn't make sense to remove the box, because there isn't one box. And so, for form elements like <select>, <input>, and <textarea>, display: contents functions exactly like display: none.

(See the full list of elements that display: contents works differenly for)

What about buttons and links? #

Both the <button> and <a> elements do not have any special behaviour when it comes to display: contents. However, it is useful to know how this rule affects them because it may not be immediately obvious.

Buttons #

Buttons are not one of the form elements which are composed of other boxes. Therefore, display: contents will just remove the surrounding box, leaving the content of the button displayed. If used within a form, clicking the button will still attempt to submit the form and, as we have covered, any event listeners on the button will function normally.

Links #

For links, the same applies in that the surrounding box is visually removed, leaving the contents of the link behind. Since attributes aren't generally affected by this CSS rule, the link will still function properly and can be used to navigate as normal.

Why is `display: contents` useful? #

In the past, we have had to lay out our HTML in a way that works both semantically, and for the purposes of styling with CSS. This has led to cases where we either have too many unnecessary elements for wrapping purposes, or too few elements to enable direct sibling styling. The latter has become particularly pertinent with the introduction of CSS Grid Layout which, for now at least, needs to work with direct sibling elements.

Let's take, for example, this layout -

We have two "cards" placed next to each other, each with a heading, a pargraph, and a footer. What we want is for each of the sections within each card to be the same height, regardless of the content of each section (e.g. the first card has only a 1-line whereas the third card has a 3-line heading, but the first card heading section height should match the third).

We could achieve this layout using CSS Grid, but we would need all the elements within each "card" to be direct siblings of each other. So, we may have to layout our HTML like this -

<div class="grid">
  <h2>This is a heading</h2>
  <p>...</p>
  <p>Footer stuff</p>

  <h2>This is a really really really super duper loooong heading</h2>
  <p>...</p>
  <p>Footer stuff</p>
</div>

And we could apply the following styles -

.grid {
  display: grid;
  grid-auto-flow: column;
  grid-template-rows: auto 1fr auto;
  grid-template-columns: repeat(2, 1fr);
  grid-column-gap: 20px;
}

Although this is not exactly an incorrect way to structure this document, it probably makes more sense to group each "card" within an <article> element. This is where display: contents comes in. We can have the best of both worlds here - by laying out our markup in a way that makes sense semantically, but having our CSS act in a way that makes sense layout-wise.

<div class="grid">
  <article style="display: contents;">
    <h2>This is a heading</h2>
    <p>...</p>
    <p>Footer stuff</p>
  </article>
  <article style="display: contents;">
    <h2>This is a really really really super duper loooong heading</h2>
    <p>...</p>
    <p>Footer stuff</p>
  </article>
</div>

With the same CSS as above, we can achieve the layout we want.

Using `display: contents` #

At the time of writing, display: contents is only supported in two major browsers, with support arriving soon in many others.

Because of this, this feature should still currently be considered a progressive enhancement, and an appropriate fallback should be used.

article {
  display: grid;
  grid-template-rows: 200px 1fr auto; /* e.g. Use a fixed height for the header */
}

@supports (display: contents) {
  article { display: contents; }
}

Recreating the GitHub Contribution Graph with CSS Grid Layout

2018-01-23T00:00:00Z

While learning CSS Grid Layout, I’ve found that the best way to internalise all the new concepts and terminology is by working on various layouts using them. Recently, I decided to try to recreate the GitHub Contribution graph using CSS Grid Layout, and found it was an interesting challenge.

As I always find while working with CSS Grid Layout, I end up with far less CSS than I would have using almost any other method. In this case, the layout-related part of my CSS ended up being less than 30 lines, with only 15 declarations!

To explain how I recreated this layout, let’s break it down into four stages:

The overall graph grid
The "days" column
The "months" row
The graph squares

The Overall Graph Grid #

The broad layout of the contribution graph is broken up into three main areas - the days column, the months row, and the individual squares.

Within the main .grid element, we have three elements:

<div class="grid">
	<ul class="months"></ul>
	<ul class="days"></ul>
	<ul class="squares"></ul>
</div>

I laid out the three areas within the main graph using the grid-template-areas property. This property allows us to, in a more explicit way, define where the different areas of a grid fall. To do this, we first name each area of the grid.

.months { grid-area: months; }
.days { grid-area: days; }
.squares { grid-area: squares; }

Then, using these names, we write out how we want the areas to be laid out. The grid-template-areas property accepts space-separated strings. Each string represents a row, and within each string we have columns.

.graph {
  display: inline-grid;
  grid-template-areas: "empty months"
                       "days squares";
}

I prefer to separate each string by a new line, so it is more visually apparent that each string represents a row, but a space is all that is needed. The above property could just as easily be written in the following way -

.graph {
  grid-template-areas: "empty months" "days squares";
}

You'll notice I added an unnammed grid area, empty to the grid-template-areas value. This is because we want the months area to start from the second column and the days area to start from the second row. If we use a grid area name that doesn't correspond to an actual grid area, we can essentially create a "phantom" element. We can act as if there is an element there without having anything obstructing our actual markup. Cool, right?!

In addition to laying out these grid areas, there are two more styles that need to be applied to graph. First, we want to add some spacing between each element, which we add with the grid-gap property.

.graph {
  grid-gap: 10px;
}

Finally, we want the the first column to only take up as much space as it needed by the content within it, but the second column to fill up the rest of the available space. We can achieve the latter using the fr unit, which represents the remaining available space within a grid.

.graph {
  grid-template-columns: auto 1fr;
}

And that’s all the styles we need to apply to the containing graph element.

The "Days" Column #

The list of days on the left side of the contribution graph is a simple one-column grid with exactly 7 rows.

This layout is achieved with exactly 2 lines of CSS -

:root {
  --square-size: 15px;
}

.days {
  display: grid;
  grid-template-rows: repeat(7, var(--square-size));
}

We use the repeat() function here, passing in the following options:

For how many rows we want the sizing (see the next item) to apply for. In this case, we chose 7 because there are 7 days in the week.
The size we want each row to be. In this case, we used the same size the individual squares are going to be, using the --square-size variable declared earlier in the stylesheet

Lastly, we want some spacing between each of the rows. As with the spacing between the areas in the .graph element, we use the grid-gap property, passing in the amount of spacing we want.

:root {
  --square-size: 15px;
  --square-gap: 5px;
}

.days {
  grid-gap: var(--square-gap);
}

The "Months" Row #

The list of months at the top of the contribution graph is a one-row grid.

However, unlike the list of days, the amount of space (i.e. columns) taken up by each items is not so straightforward. Ideally, we would want each month to take up the equivalent of 4 columns to represent four weeks. We could achieve this using a similar method to how we laid out the weeks.

:root {
  --square-size: 15px;
  --square-gap: 5px;
  --week-width: calc(var(--square-size) + var(--square-gap));
}

.months {
  display: grid;
  grid-template-columns: repeat(12, calc(var(--week-width) * 4));
}

However, each month doesn’t span across exactly 4 even weeks. There is some overlap, with some months spanning across less or more. Because of this, I opted to manually set the column width for each month.

.months {
  display: grid;
  grid-template-columns: calc(var(--week-width) * 4) /* Jan */
						 calc(var(--week-width) * 4) /* Feb */
						 calc(var(--week-width) * 4) /* Mar */
						 calc(var(--week-width) * 5) /* Apr */
						 calc(var(--week-width) * 4) /* May */
						 calc(var(--week-width) * 4) /* Jun */
						 calc(var(--week-width) * 5) /* Jul */
						 calc(var(--week-width) * 4) /* Aug */
						 calc(var(--week-width) * 4) /* Sep */
						 calc(var(--week-width) * 5) /* Oct */
						 calc(var(--week-width) * 4) /* Nov */
						 calc(var(--week-width) * 5) /* Dec */;
}

Since I wasn’t relying on real data, I just copied what I saw on my actual GitHub graph at the time. Ideally, we would have a way to specify the widths of each column more programatically, but this is the way I decided to implement for the demonstrative purpose.

The Individual Squares #

The styles for the individual squares are mostly shared with the .days column, since the spacing and number of rows are meant to be identical.

.days,
.squares {
  display: grid;
  grid-gap: var(--square-gap);
  grid-template-rows: repeat(7, var(--square-size));
}

In addition to those shared styles, the individual squares are different in a number of ways.

The first is the direction in which the squares are laid out. By default, items within a grid are laid out in the direction of the English language, i.e. left-to-right then top-to-bottom. However, the squares in the GitHub contribution graph are laid out differently, top-to-bottom then left-to-right.

To lay our squares out in this way, we use the grid-auto-flow property.

.squares {
  grid-auto-flow: column;
}

Lastly, we want each column/square to be a set width (var(--square-size)). However, unlike the rows, we do not know or want to specify the exact amount of columns we have. So, instead of using the grid-template-columns property, we can use the grid-auto-columns property, setting it to the width we want each column to be, and letting the grid figure out how many columns are eventually drawn.

.squares {
  grid-auto-columns: var(--square-size);
}

The Finished Product #

You can see how everything works together in the CodePen below.

See the Pen GitHub Contribution Graph in CSS Grid Layout by Ire Aderinokun (@ire) on CodePen.

What’s New in HTML 5.2?

2018-01-08T00:00:00Z

Less than a month ago, HTML 5.2 became an official W3C Recommendation (REC). When a specification reaches the REC stage, this means that it has received the official endorsement of W3C Members and the Director, and that the W3C officially recommends it’s deployment by user agents, and it’s implementation by web page authors.

By the REC stage, anything new should have had at least 2 independent implementations. This makes it a great time for us, as web page developers, to begin implementation of any new feature.

In HTML 5.2, there were a number of additions and removals, all of which can be seen on the official HTML 5.2 Changes page. In this article, I’ll go over some of the changes I think will impact my development the most.

New Features #

A native `<dialog>` element #

Of all the changes in HTML 5.2, I’m the most excited about the introduction of the <dialog> element, a native dialog box. Dialogs are incredibly prevalent on the web, yet every implementation is different in some way. Dialogs are also really difficult to do in a way that is accessible, resulting in most dialogs on the web being practically unusable for users who don’t navigate the web visually.

The new <dialog> element aims to change this, providing a simple way to include a modal dialog without having to worry about many of the pitfalls. I will write a separate, detailed article about how this element works, but here are the basics.

The dialog is created using a <dialog> element:

<dialog>
  <h2>Dialog Title</h2>
  <p>Dialog content and other stuff will go here</p>
</dialog>

By default, the dialog is hidden from view (and from DOM access) unless the open attribute is applied.

<dialog open>

The open attribute can be toggled by calling the show() and close() methods, which is available to any HTMLDialogElement.

<button id="open">Open Dialog</button>
<button id="close">Close Dialog</button>

<dialog id="dialog">
  <h2>Dialog Title</h2>
  <p>Dialog content and other stuff will go here</p>
</dialog>

<script>
const dialog = document.getElementById("dialog");

document.getElementById("open").addEventListener("click", () => {
  dialog.show();
});

document.getElementById("close").addEventListener("click", () => {
  dialog.close();
});
</script>

The <dialog> element already has support in Chrome, and is behind a flag in Firefox.

Using the Payment Request API from iFrames #

The Payment Request API is a native alternative to checkout forms. It aims to provide a standardised and consistent method of making payments on the web for users, by moving the handling of retrieving payment information to the browser, instead of individual checkout forms on each website.

Before HTML 5.2, these payment requests couldn’t be made from iframes embedded in a document. This made it essentially impossible for third-party embedded payment solutions (e.g. Stripe, Paystack), to take advantage of this API, since their payment interface is typically handled within an iframe.

HTML 5.2 introduced the allowpaymentrequest attribute which, when applied to an iframe, will allow it to use the Payment Request API while the user is on the hosting web page.

<iframe allowpaymentrequest>

Sizes for Apple Icons #

To define web page icons, we use the <link rel="icon"> element in the head of our document. To define different sizes of icons, we use the sizes attribute.

<link rel="icon" sizes="16x16" href="path/to/icon16.png">
<link rel="icon" sizes="32x32" href="path/to/icon32.png">

This attribute, although purely advisory, allows user agents to decide which size of icon to use if multiple sizes are available, particularly since most devices have their own different "optimal" icon size.

Before HTML 5.2, the sizes attribute was only valid if the link relationship was icon. However, Apple’s iOS devices do not support the sizes attribute. To get around this, Apple introduced a device-specific relationship, appple-touch-icon , which could be used to define the icon used on their devices.

In HTML 5.2, the specification now allows the sizes attribute to be used if the relationship is apple-touch-icon, no longer only icon. This will allow us to provide different sizes of icons for different apple devices. Although, as far as I currently know, Apple devices still do not support the sizes attribute, this change will be useful for the future when they eventually do.

Newly Valid Practices #

In addition to new features, HTML 5.2 has validated some practices in writing HTML that were previously invalid.

Multiple `<main>` elements #

The <main> element represents the main content of a web page. While content that is repeated across multiple pages can be placed in headers, sections, or any other element, the <main> element is reserved for the content that is specific and unique to the particular page. Consequently, before HTML 5.2, the <main> element had to be unique within the DOM for the page to be valid.

With the prevalence of Single Page Applications, however, sticking to this rule could be difficult. There may be cases in which there are multiple <main> elements in the DOM, but only one being shown to the user at any given time.

With HTML 5.2, we can now have multiple <main> elements in our markup, as long as only one is visible to the user at any given time. Any extra elements must be hidden using the hidden attribute.

<main>...</main>
<main hidden>...</main>
<main hidden>...</main>

As we know, there are several ways to hide an element with CSS. However, any extra <main> elements must be hidden using the hidden attribute. Any other method for hiding the element, e.g. display: none; or visibility: hidden; will not be valid.

Styles in the `<body>` #

Typically, inline CSS defined using the <style> element is placed within the <head> of the HTML document. With the increase in component-ized development, developers have seen the benefit in writing and placing styles along with the html element they are relevant for.

In HTML 5.2, defining an inline <style> block anywhere within the <body> of an HTML document is now valid. This means that we can have styles closer to where they are used.

<body>
    <p>I’m cornflowerblue!</p>
    <style>
        p { color: cornflowerblue; }
    </style>
    <p>I’m cornflowerblue!</p>
</body>

However, it is still noted that styles should preferably be placed in the <head>, for performance reasons. According the the specification,

A style element should preferably be used in the head of the document. The use of style in the body of the document may cause restyling, trigger layout and/or cause repainting, and hence, should be used with care.

It should also be noted that, as shown in the example, the styles are not scoped. An inline style defined later in the HTML document will still apply to elements defined before it, which is why it may trigger repainting.

Headings in a `<legend>` #

In forms, the <legend> element represents a caption for the form fields within a <fieldset>. Before HTML 5.2, the content of a legend had to be plain text. Now, we can include heading elements.

<fieldset>
    <legend><h2>Basic Information</h2></legend>
    <!-- Form fields for basic information -->
</fieldset>
<fieldset>
    <legend><h2>Contact Information</h2></legend>
    <!-- Form fields for contact information -->
</fieldset>

This is really useful for when we want to use the fieldset element to group different sections of a form. In cases like this, it makes perfect sense to use headings, which would make these form sections more easily navigable for users relying on a document outline.

Removed Features #

In HTML 5.2, a few elements were removed, namely:

keygen: Used to help generating public keys for forms
menu and menuitem: Used to create navigation or context menus

Newly Invalid Practices #

Finally, some development practices have been made invalid.

No inline, floated, or blocked children of `<p>` #

In HTML 5.2, the only valid children of a <p> element should be phrasing content. This means that the following types of elements should no longer be nested within a paragraph:

Inline blocks
Inline tables
Floated and positioned positioned blocks

No Strict Doctypes #

Finally, we can say goodbye to the following strict document types:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "https://www.w3.org/TR/html4/strict.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Localisation and Translation on the Web

2017-11-23T00:00:00Z

Coming from the English-speaking world, it can be easy to maintain the bubble that is the English-speaking World Wide Web. But in fact, more than half of web pages are written in languages other than English.

Since starting work at eyeo, I’ve had to think a lot more about localisation and translations because most of our websites are translated into several languages, something I previously didn’t have to really consider before. Once you decide to translate a web page, there are many things to take into account, and a lot of them I've found are useful even if your website is written in only one language.

What Language is the Website? #

One of the first things we need to think about is what language the HTML document (or elements within) are written in. Using the lang attribute, we can let browsers know what language the web page is written in.

Typically, we would add this attribute to the root element of the document, which is in most cases the HTML element.

<html lang="en">

Adding this attribute to the root element is really important, particularly for users who’s main language used with their machine is not the same as the web page’s language. For example, a French-speaking user who visits this blog.

In the absence of the lang attribute, the browser will assume the web page is written in the user’s default language, which can lead to some strange results. Here’s an example of a screen reader reading an English web page in a French accent due to a missing lang attribute -

The lang attribute is one of the global HTML attributes which allows it to be applied to any HTML element. This means that we can specify different sections of our web page as being written in different languages. This can be really useful, for example, if you are writing an article that references a text in a different language, comme ça, par exemple.

<html lang="en">
<body>
  <h1>Localisation and Translation on the Web</h1>
  <p>
    This can be really useful, for example, if you are writing an article that references a text in a different language, <strong lang="fr">comme ça, par exemple</strong>
  </p>
</body>

Specifying Language for External Pages #

When using the lang attribute, we can tell user agents what language the content on the current webpage is, but what about if we need to link to an external page/resource?

We can specify the language of an externally linked resource using the hreflang attribute. As it’s name implies, it sets the language of a resource linked to via the href attribute, and can thus only be applied to elements that have this attribute, i.e. the <a>, <link>, and <area> elements.

<a href="https://adblockplus.org/ar/" hreflang="ar">adblockplus.org (Arabic)</a>

Controlling Translations #

In some cases, we may want a section of the web page to always be displayed in a certain language, never translated. This is the idea behind the new HTML5.1 translate attribute.

The translate attribute can accept one of two values:

yes: The element’s contents should be translated
no: The element’s contents should not be translated

<html lang="de">
  <p>Übersetze mich!</p> <!-- Translate me! -->
  <p translate="no">Übersetze mich nicht</p> <!-- Do not translate me -->
</html>

Not currently supported

Unfortunately, this attribute is not currently supported by any browser. However, it's effect can be simulated by using the .notranslate class, which is respected by Google’s Web Page Translator. Take, for example, the following two paragraphs:

<html lang="de">
  <p>Übersetze mich!</p> <!-- Translate me! -->
  <p class="notranslate">Übersetze mich nicht</p> <!-- Do not translate me -->
</html>

If this page is translated to another language, only the first paragraph will be translated.

Text Direction #

In many languages, the direction in which text is written is not left-to-right like it is in English. In languages such as Arabic, text is written (and read) from right-to-left.

To change the direction in which text is written, we can use the dir attribute, which accepts one of three values:

ltr: Left to Right
rtl: Right to Left
auto: Allow the user agent to decide which direction based on the text content

<html lang="ar" dir="rtl">

Based on this root direction, most browsers will apply the corresponding CSS styles to switch the direction in which text is displayed, using the direction property.

The CSS direction property accepts one of two values - ltr or rtl.

html[dir="rtl"] {
  direction: rtl;
}

This property works in the same way as the text-align property. It doesn’t re-order the words in any way, it just aligns the text in the appropriate direction.

Other relevant CSS properties for controlling text direction include:

writing-mode: This determines if text is laid out horizontally or vertically and the direction (See MDN)
text-orientation: This determines the orientation of each character (See MDN)

Alternates #

For most sites that are translated into different languages, there are separate pages for each language. For example, there might be several versions of the homepage -

https://adblockplus.org/en/ for the English version
https://adblockplus.org/ar/ for the Arabic version
...

In order for user agents to know of all these separate pages and classify them correctly as the same page, just translated into different languages, we can use the <link> element, with the alternate relationship type. In the document <head> we can write out all the alternate versions for the page -

<html lang="en">
<head>
  <link rel="alternate" href="https://adblockplus.org/ar" hreflang="ar">
  ...
</head>
</html>

Note that we use the hreflang attribute in combination with the alternate type to set the language each alternate page is in.

When a link to a web page is shared, it’s language is typically determined from the og:locale meta tag.

<meta name="og:locale" content="en_US">

If there are multiple available locales, we can specify this using the og:locale:alternate meta tag.

<meta property="og:locale:alternate" content="ar_AR">

Left, Right, Start, End #

Because most of the web was originally written with only English in mind, a lot of CSS was written with the mindset that the start of a line is the left, and the end of the line is the right. But as the web becomes more internationally aware, things are changing.

For example, with Flexbox, the default “left” side of the box is called the “start”, because this can be on any of the four sides of the box itself. A lot of new CSS properties are starting to work this way, for example the new margin-inline-start property.

The margin-inline-start property corresponds to the inline “start” margin of an element, and can be equal to any of the four sides of the element depending on the direction of the document. For example, if the direction on an element is right-to-left, then the start margin will be equivalent to the right margin.

span {
  direction: rtl;
  margin-inline-start: 20px; /* Equivalent to margin-right */
}

Similarly, if the writing-mode of an element is set as vertical and left-to-right, then the start margin will be equivalent to the top margin.

span {
  writing-mode: vertical-lr;
  margin-inline-start: 20px; /* Equivalent to margin-top */
}

There are other properties that work in this way, for example the corresponding margin-inline-end, which works similarly to margin-inline-start, but applies to the end of the element. Taking the first example from above, if the direction on an element in right-to-left, then the end margin will be equivalent to the left margin.

span {
  direction: rtl;
  margin-inline-end: 20px; /* Equivalent to margin-left */
}

There are so many more considerations that are involved when creating a localised website, particularly one that accepts user input. Feel free to share any tips you have come across in the comments below.

Web Push Notifications with Firebase (Video Series)

2017-09-18T00:00:00Z

When I attended Google Developers Days Europe a couple of weeks ago, I was introduced to Firebase’s new Cloud Functions feature. Firebase Cloud Functions allow us to write server-side code without the need to create and manage our own backend, and the functions we create can be as simple or complex as we need them to be.

One particular use case I was interested in was how to use Firebase to set up Web Push Notifications feature from client-side to server-side. There is a really great Codelab that demonstrates this, but I decided to create a small project myself to highlight just this feature.

Simply Notify #

Simply Notify is a simple application that just does one thing - it sends a push notification with a message to everyone subscribed.

To demonstrate how I built it, I created a short video series. You can watch the videos below:

Part 1 - Introduction & Firebase Setup #

Part 2 - Authentication #

Part 3 - Subscribing to Notifications #

Part 4 - Creating & Saving Messages #

Part 5 - Sending Web Notifications #

Part 6 - Database Security & Optimisations #

Accessibility Testing with pa11y

2017-08-15T00:00:00Z

Knowing where to start with accessibility testing can be difficult and overwhelming. In my article on Tools for Developing Accessible Websites, I mentioned 5 tools you can use to get started developing more accessible websites. More recently, I have discovered an incredibly powerful tool - pa11y

Introducing pa11y #

pa11y, pronounced pally, is a set of free and open source tools that aims to make designing and developing accessibility easier. They have a number of different projects to help with this, for example a web dashboard interface, but I will be focusing on 2 of their projects: pa11y and pa11y-ci.

Getting Started with pa11y #

As a beginner, the easiest way to get started with accessibility testing is by installing the core package, pa11y.

npm install -g pa11y

This gives us access to the command pa11y, which we can use to run a simple accessibility audit on a particular url. Let's take this blog's homepage as an example.

pa11y https://bitsofco.de

Running the above command, however, will likely send you into spiral of doom because every single error, warning, or notice will be outputted into your terminal. But don't fret, because there are a few simple options you can pass to ease you into the process.

Only display critical errors #

When first starting out, you will likely just want to see the crucial errors that you need to fix, and not just every single accessibility-related message related to the page. pa11y divides their messages into three types:

A notice is general message about an element's accessibility. It isn't necessarily something that is wrong with your implementation, but rather a notice to be aware of concerning a particular element. For example, a notice can be "Notice: Check that the title element describes the document."
A warning is something that pa11y considers may be an issue, so you should take a look at it. For example, a warning you may receive on an <img> element with a null alt attribute is "Warning: Img element is marked so that it is ignored by Assistive Technology.". Using a null alt attribute isn't necessarily an error, as null attributes can be intentional (see Alternative Text and Images), but it is something that you should look at to make sure
An error is a critical issue that should be fixed. For example, an error you may receive on an unlabelled for input is "Error: This text input element does not have a name available to an accessibility API."

For your first audit, you probably want to exclude notices and warnings, so you only see the crucial errors on your page. This can be done by using the --ignore flag -

pa11y https://bitsofco.de --ignore "warning;notice"

Set thresholds for failure #

Once you've set your option to only see critical error messages, you can specify the amount of those errors that should be permitted in order for the page to "pass" the accessibility test. This is done using the --threshold flag -

pa11y https://bitsofco.de --threshold 10

The command above, for example, will allow up to 10 errors on the page before the page will be deemed to have failed the test.

Hide elements #

Finally, another great option for beginners is to hide certain elements from testing. This can be useful if, for example, you have third party widgets such as ads on your page that you can't control. Or, you can use it to hide elements that are visual or screen-reader only.

pa11y <url> --hide-elements "#ads .sr-only [aria-role='presentation']"

Using this blog as an example, I want to hide the errors related to Carbon Ads widget (#cardbonads) -

pa11y https://bitsofco.de --hide-elements "#carbonads"

Putting it together #

Putting all of these together, you should get a useful, non overwhelming audit of your page, with actionable errors to fix.

pa11y https://bitsofco.de --ignore "warning;notice" --threshold 10 --hide-elements "#carbonads"

Doing more with pa11y #

Using pa11y in the way described above can be great when you're getting started, but pa11y can be used for much, much more than that.

The basic pa11y command starts to fall a bit short when you need to test multiple pages, each with different options. Although the core package can be configured in a more advanced way by creating a dedicated node script, I think the pa11y-ci package does a better job at handling the more complex audits.

npm install -g pa11y-ci

This will give you access to the pa11y-ci command. It can be used in a similar way to pa11y, but most of the configuration options are stored in a .pa11yci JSON file.

Here's an example of the same basic configuration mentioned above, but in a .pa11yci file:

{
  "defaults": {
    "hideElements": "#carbonads",
    "ignore": [ "notice", "warning" ]
  },
  "urls": [ "https://bitsofco.de" ]
}

The only option that is still specified as a command line option, is threshold. So, we can execute all our options using the following command:

pa11y-ci --threshold 10

(Note that pa11y-ci expects your .pa11yci file to be in the root directory.)

Once we've got the default configurations down, we can move on to some more advanced customisations.

Testing multiple URLS #

The first thing you might notice about the .pa11yci configuration, is that there is an array of URLs we can pass. This allows us to test multiple URLs in one go. Using this blog example, I may want to test the home page, the newsletter signup page, and a single article page.

{
  "urls": [
    "https://bitsofco.de" ,
    "https://bitsofco.de/subscribe",
    "https://bitsofco.de/collapsible-margins"
  ]
}

What's even greater, is that we can specify custom configurations for each page. We do this by passing an object into the urls, instead of a simple string. In addition to the url, we pass any of the pa11y configurations we want to override for that particular page.

For example, I want the #carbonads element to be hidden globally because it shows up on all pages. On an article page, I also want to hide the comments (#disqus_thread), so I can set a custom hideElements configuration only for that page.

{
  "defaults": {
    "hideElements": "#carbonads"
  }
  "urls": [
    "https://bitsofco.de",
    "https://bitsofco.de/subscribe",
    {
      "url": "https://bitsofco.de/collapsible-margins",
      "hideElements": "#carbonads, #disqus_thread",
    }
  ]
}

Customise accessibility standards and rules #

A useful configuration option is the standard option. The default accessibility standard used by pa11y to test a page is the WCAG2AA. However, we can change it to any of the following options - Section508, WCAG2A, WCAG2AA, or WCAG2AAA.

{
  "defaults": {
    "standard": "WCAG2AAA"
  }
}

Additionally, we can specify a set of specific WCAG 2.0 guidelines to include. For example, you may want to follow the WCAG2A standard in general, but include a couple of specific guidelines that would normally apply to a stricter standard.

{
  "defaults": {
    "standard": "WCAG2A",
    "rules": [ 'Principle1.Guideline1_4.1_4_6_AAA' ]
  }
}

The above requires that the specific guideline 1.4.6, "Contrast (Enhanced)" must be followed.

Besides a basic audit of your markup, pa11y can be used to test actions that a user might take on your page. Using their custom set of keywords, you can demo a flow of actions.

For example, on the subscribe page of this blog, I may want to test that a user can actually fill out the form to subscribe.

"urls": [
  {
    "url": "https://bitsofco.de/subscribe",
    "actions": [
      "set field #mce-EMAIL to pa11y@testing.com",
      "set field #mce-FNAME to Tester",
      "click element #mc-embedded-subscribe",
      "wait for url to not be https://bitsofco.de/subscribe"
    ],
    "timeout": 60000
  }
]

When testing actions, it's important to set a long timeout to allow pa11y to go through all the steps.

Device-specific testing #

pa11y allows us to specify the viewport dimensions to test a page with, allowing for device-specific testing.

{
  "defaults": {
    "page": {
      "viewport": { "width": 320, "height": 480 }
    }
  }
}

Doing even more with pa11y #

pa11y has what seems like an endless list of features and configuration options so we can test our sites in any number of ways. I haven't gone over every feature or option available, such as implementing continuous integration which the the pa11y-ci package is actually built for. If you want to find out more, check out the repositories for pa11y and pa11y-ci. If there are any particular features you would like me to cover in more detail, leave a comment below.

You can see a full example of how I use pa11y to test this blog on my repository, ireade/bitsofcode-pa11y.

What's the Deal with Collapsible Margins?

2017-07-04T00:00:00Z

Last week, I ran a twitter poll asking the following question - What would be the amount of space between two sibling divs, where the 1st has a margin-bottom of 10px and 2nd a margin-top of 30px?

The result of this poll was that 39% of the 754 people who voted got the correct answer, which was 30px.

[CSS Quiz] What would be the amount of space between two sibling divs, where the 1st has a margin-bottom of 10px and 2nd margin-top 30px? — Ire Aderinokun (@ireaderinokun) June 27, 2017

The reason the resulting margin would be 30px was because of a feature of CSS called “Collapsing margins”.

A Refresh on the CSS Box Model #

Before we get into how collapsing margins work, we need to revisit the box model. As I mentioned in my more in-depth article on Controlling the Box Model, every element in the document tree is a rectangular box made up of four areas - the content area, padding area, border area, and margin area.

The margin area is the space outside an element’s border. Let’s take this .box element, for example -

.box {
  width: 300px;
  height: 300px;
  padding: 50px;
  border: 50px solid grey;
  margin: 50px; /* margin area */
}

The margin area of this box is shown striped below:

The margin area is different to the other three areas of the box model because it is not technically part of the element itself. Even if we specify a set margin for an element in our CSS, the actual margin painted on the document can be affected by the other elements within the document, as we will see in the case of collapsing margins.

What is a Collapsed Margin? #

A collapsed margin is what occurs when two block-level elements with meeting vertical margins combine. When this happens, the larger of the two margins (or any if they are equal) is assumed as the single collapsed margin.

Let’s take the example from my Twitter poll. We have two elements; Element A has a bottom margin of 10px, and element B has a top margin of 30px. Here are the two elements shown separately -

If we place these two, block-level, elements one after the other in our markup, this is the result we get -

The margin between the two elements is combined and the resulting “collapsed” margin with a height of 30px is what is left.

When do Margins Collapse? #

As a general rule, adjoining vertical margins between in-flow, block-level, boxes will always collapse. There are four scenarios in which this takes place:

Case 1: The top margins of a parent and it’s first child #

If a top margin is applied to a parent element as well as it’s first in-flow child, those margins may be collapsed together.

.parent {
  margin-top: 30px;
  height: 150px;
  background-color: rgb(200,200,200); /* Grey */
}

.child {
  margin-top: 30px;
  width: 100px;
  height: 100px;
  background-color: rgb(250, 219, 92); /* Yellow */
}

Case 2: The bottom margins of a parent and it’s last child #

Similarly to the first example, margins may be collapsed if both a parent and last in-flow child have a bottom margin. However, unlike the top margins, bottom margins will only collapse if the parent has a computed height of auto.

.parent {
  margin-bottom: 30px;
  height: auto;
  background-color: rgb(200,200,200);
}

.child {
  margin-bottom: 30px;
  width: 100px;
  height: 100px;
  background-color: rgb(250, 219, 92);
}

Case 3: The bottom and top margins of siblings #

This is the scenario I mentioned in my poll. If we have two elements, where one has a bottom margin and the second in-flow sibling has a top margin, those margins may be collapsed.

.sibling-one {
  margin-bottom: 10px;
  width: 100px;
  height: 100px;
  background-color: rgb(250, 219, 92);
}

.sibling-two {
  margin-top: 30px;
  width: 100px;
  height: 100px;
  background-color: rgb(200,200,200);
}

Case 4: Empty elements #

Finally, both the top and bottom margins on a single element may collapse if the element has a computed height of 0, i.e. if it is an empty element.

<p>This paragraph is before the empty element</p>
<div class="empty"><!-- Empty element --></div>
<p>This paragraph is after the empty element</p>

.empty {
  margin-bottom: 30px;
  margin-top: 30px;
}

Exceptions #

As with everything, there are a few exceptions to take note of for when margins will not collapse.

Flexbox, Grid, and other non-block-level elements #

Collapsible margins only apply to block-level elements. These are elements that have either of the following values for the display property: block, list-item, or table. Therefore, flex items, grid items, absolutely positioned items, and other non-block-level elements do not apply.

The root element #

The margins of the root element’s box will never collapse.

Lines boxes, clearance, paddings, and borders #

In the example cases mentioned above, collapsing will not happen if there are line boxes, clearance, paddings, or borders, that stand between the two elements.

Let’s take the first example I mentioned, where the top margin of the parent is collapsed with the top margin of it's first child. If we add a border around the parent element, the margins no longer collapse.

This happens because the margin of the parent is no longer in direct contact with the margin of the child.

Dealing with Collapsed Margins #

Collapsible margins can be a pain if you don't properly understand when they occur. The first step to dealing with or avoiding them is understand exactly which case of collapsible margins we are dealing with.

Collapsed margins that occur because of empty elements or parent/child relationships can't really be avoided. The only way to counteract collapsible margins that occur this way is by inserting something between the elements, for example a border. Otherwise, changing the element's display status to something that is not block-level would be an option.

Collapsed margins that occur because of adjoining sibling elements, on the other hand, can be avoided with a change in CSS writing style. Personally, I prefer to follow Harry Roberts' rule of Single-direction margin declarations, which has other benefits besides helping to avoid collapsible margins.

How the minmax() Function Works

2017-06-06T00:00:00Z

One incredibly useful new feature introduced with the CSS Grid Layout Specification is the minmax() function. This function opens the door to us being able to write much more powerful and succinct CSS by allowing us to set, as a value for a grid track, a function including both a minimum and maximum value.

The `minmax()` Function #

The minmax() function accepts two parameters, a minimum value and a maximum value.

minmax(min, max)

If the maximum value defined is actually less than the minimum, it is ignored, and the function is treated as purely presenting a minimum value.

The minmax() function accepts 6 types of value:

Length
Percentage
Flexible Length
max-content
min-content
auto

Let’s consider examples of each.

Length #

Perhaps the most simple value we can use with the minmax() function is a basic length. Take, for example, this simple grid, which has three columns and a single row.

Using the minmax() function, we can specify that the yellow grid cell remain between 100px and 200px. As the viewport is resized, the absolute value will change, but always within these two limits.

.grid {
    display: grid;
    grid-template-columns: minmax(100px, 200px) 1fr 1fr;
}

The second and third columns shrink and expand to fill the remaining available space equally, but the first column always remains between 100px and 200px wide.

Percentage #

Besides the basic length units, we can also use percentage units with the minmax() function. Say, for example, that we want the yellow grid cell to take up a maximum of 50% of the grid, but not get any smaller than 200px.

.grid {
    display: grid;
    grid-template-columns: minmax(200px, 50%) 1fr 1fr;
}

No matter how small we shrink the viewport, the yellow cell never gets smaller than 200px. But, when it has the room to, is grows to a maximum of half the grid width.

Flexible Length #

The Flexible Length is a new unit which, like the minmax() function, was also introduced with the CSS Grid Layout Specification. This length, which uses the fr unit, represents a fraction of the free space in the grid container. For example, let’s say we have a 100px-wide grid, with 2 columns. One column has a fixed width of 20px and the other column has a width of 1fr. The second column will effectively have a width of 80px, as it takes up the remaining available space within the grid.

Currently, the fr unit can only be used as the maximum value in the minmax() function (although it is noted in the spec that, in the future, it may be applicable to the minimum value as well). Going back to our example, we can specify that we want the yellow grid cell to be a minimum of 200px. If the viewport is resized larger than that, we want the cell to be 1fr, the same size as the other two columns.

.grid {
    display: grid;
    grid-template-columns: minmax(200px, 1fr) 1fr 1fr;
}

Since all columns are 1fr at larger viewport sizes, they share an equal amount of space within the grid.

`max-content` #

The max-content keyword is a special value that represents the cell’s "ideal size". This is the smallest possible size the cell can be, while still fitting around it’s contents unobtrusively. For example, if the contents of the cell is a sentence, the ideal width for the cell will be to take up the entire length of the sentence, regardless of the length and no line breaks.

Taking our previous example, let’s specify that the yellow grid cell be both a minimum and maximum of max-content.

.grid {
    display: grid;
    grid-template-columns: minmax(max-content, max-content) 1fr 1fr;
}

As we can see, the size of the column expands to fit the entire length of the string. Since both the minimum and maximum values are set to max-content, the width of the column remains the same.

`min-content` #

The min-content keyword, like max-content, is a special value. It represents the smallest possible size the cell can be that does not lead to an overflow, unless that overflow is unavoidable.

To illustrate the difference between min-content and max-content, we can use the same content as in the previous example, but set both values of the minmax() function to min-content.

.grid {
    display: grid;
    grid-template-columns: minmax(min-content, min-content) 1fr 1fr;
}

We can see that the content within the cell is shifted in order to take up the least amount of horizontal space possible, without causing any overflow.

`auto` #

Finally, we have auto. This has different meanings depending on if it is used as the maximum or minimum value in the minmax() function.

If used as a maximum, the auto value is equivalent to the max-content value. If used as a minimum, the auto value represents the largest minimum size the cell can be. This "largest minimum size" is different from the min-content value, and specified by min-width/min-height.

To illustrate this, here's what happens when the yellow grid cell in our example is set to an auto minimum and maximum.

.grid {
    display: grid;
    grid-template-columns: minmax(auto, auto) 1fr 1fr;
}

Using the `minmax()` Function: Responsive Design without Media Queries #

As we have seen, there are several cases where using the minmax() function is suitable, and we can use it in several ways. But perhaps the most popular and useful case for the minmax() function it's ability to enable us create responsive designs without the use of any media queries.

Let's take this example grid:

Each column in the grid has a minimum width of 200px. As the viewport is resized, the number of columns changes to fit their ideal width. With CSS Grid and the minmax() function, this can be created in as little as 2 lines of CSS -

.grid {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
}

Besides the minmax() function, there are two other key parts to this:

repeat(): This function allows us to specify the same value for multiple columns in the grid. It accepts two values: the number of times to repeat, and the value to be repeated.
auto-fit: This keyword can be used with the repeat() function instead a number of times to repeat. This will flexibly change the number of columns that are used based on the width each column can be.

One, in my opinion quite major, limitation of this technique, however, is that it only works when each column is of equal width. We have to use the repeat() function with the auto-fit keyword, as this is what allows the number of columns to be flexible. Nonetheless, this can still an extremely useful technique in the right circumstances.

CSS Animations vs the Web Animations API: A Case Study

2017-05-03T00:00:00Z

Last week, I wrote about how I created the bitsofcode logo animation with CSS. After that, it was suggested that I attempt a comparison between a CSS animation and the Web Animations API, so here it is!

Introduction to the Web Animations API #

As with last week, I'll start this off with an introduction to the Web Animations API. The Web Animations API provides a way for developers to directly manipulate the browser's animation engine using JavaScript.

Creating an Animation #

To create an animation using the Web Animations API, we use the Element.animate() function, which takes two arguments; keyframes and options.

element.animate(keyframes, options);

`keyframes` #

The keyframes object represents the timeline of events in the animation. There are two ways to write this object. To illustrate them, let's use this grow animation, which will scale an element to twice it's size. Here is the animation using CSS @keyframes:

@keyframes grow {
    0% {
        transform: none;
    }
    100% {
        transform: scale(2);
    }
}

The first way to write the keyframes is to pass a single object. Each key in the object represents the CSS property we want to animate. The value for each key is an array of CSS values we want to animate through. Each value in the array represents a point in the animation timeline.

const growKeyframes = {
    transform: ['none', 'scale(2)']
}

The second way to write the keyframes is to write it as an array. Each item in the array represents a point in the timeline, in which we specify each CSS property and value to be applied for that point.

const growKeyframes = [
    { transform: 'none' },
    { transform: 'scale(2)' }
]

By default, each point on the timeline is equally spaced. For example, if we had 5 points on the timeline, the animation transition between each point will be equally 20% of the animation duration.

If we want to alter timing, we can use the offset property with the second format of writing the keyframes. This property accepts a number between 0 and 1, representing the point at which that animation should be. Take, for example, this CSS animation -

@keyframes alteredGrow {
    0% { transform: none; }
    10% { transform: scale(1.5) }
    30% { transform: scale(1.9) }
    100% { transform: scale(2) }
}

To account for the uneven spacing in the timeline, we could write it the following way -

const alteredGrowKeyframes = [
    { transform: 'none' },
    { transform: 'scale(1.5)', offset: 0.1 }
    { transform: 'scale(1.9)', offset: 0.3 }
    { transform: 'scale(2)' }
]

`options` #

The second argument we pass to the animate() function is an object with some options. This object allows us to specify all the properties we would apply to the CSS property being animated if we were using CSS animations. There are 9 options we can specify:

Option	Description
`id`	A unique reference for the animation
`delay`	Specifies a delay before the animation begins. Corresponds to the `animation-delay` CSS property
`duration`	Specifies the amount of time it should take for one cycle. Corresponds to the `animation-duration` CSS property
`iterations`	Specifies how many times to run a cycle of the animation. Corresponds to the `animation-iteration-count` CSS property
`direction`	Specifies in which direction to run through the animation timeline. Corresponds to the `animation-direction` CSS property
`easing`	Specifies how the animation transitions between steps. Corresponds to the `animation-timing-function` CSS property
`fill`	Specifies the values applied to the element and the start and end of the animation. Corresponds to the `animation-fill-mode` CSS property
`endDelay`	Specifies an amount of time to delay after the end of the animation
`iterationStart`	Specifies the point n the iteration the animation should start

For example, let's take the alteredGrow animation. With CSS animations, we can apply the animation for 3 seconds, on an infinite loop, alternating directions, after a delay of 2 seconds, with these declarations -

.animated-element {
    animation-name: alteredGrow;
    animation-duration: 3s;
    animation-iteration-count: infinite;
    animation-direction: alternate;
    animation-delay: 2s;
}

Using the Web Animations API, we can do the same with the following options -

const alteredGrowOptions = {
    duration: 3000,
    iterations: Infinity,
    direction: 'alternate',
    delay: 2000
}

Using an Animation #

An animation is applied to an element by calling the animate() function on the element and passing the keyframes and options arguments.

const element = document.querySelector('.animated-element');
element.animate(alteredGrowKeyframes, alteredGrowOptions);

Once that function is called, the animation automatically starts playing. However, we can start and stop it using the play() and pause() methods.

const element = document.querySelector('.animated-element');
const myAnimation = element.animate(alteredGrowKeyframes, alteredGrowOptions);

myAnimation.pause();
myAnimation.play();

Support #

Can I Use web-animation? Data on support for the web-animation feature across the major browsers from caniuse.com.

Animating the bitsofcode Logo #

As with my CSS animation, I recreated a short section of the full animation that was created. Here's a comparison between all three versions -

Creating a Timeline #

To recap, here are the animation steps for the left section of the logo (the letters "bitso", with the opening o).

Move left
Return to middle
Stay in middle (while waiting for the right section to move right)
Move left
Rotate
Slowly increase rotation
Return to unrotated position
Return to middle

Based on these steps, this is the timeline I mapped out for the same left section -

Based on this timeline, here is the keyframes object for the Web Animation, with the styling for each step in the timeline.

const logoSectionLeftKeyframes = [
  { transform: 'none' },
  { offset: 0.125, transform: 'translateX(-15px)' },
  { offset: 0.25, transform: 'none' },
  { offset: 0.5, transform: 'none' },
  { offset: 0.625, transform: 'translateX(-15px)' },
  { offset: 0.67, transform: 'translateX(-15px) rotate(-10deg)' },
  { offset: 0.72, transform: 'translateX(-15px) rotate(-10deg)' },
  { offset: 0.82, transform: 'translateX(-15px) rotate(-15deg)' },
  { offset: 0.875, transform: 'translateX(-15px)' },
  { transform: 'none' }
];

Since I needed to use the offset property, I decided to use the array format for the keyframes.

Setting the Options #

The options I set for each section were simple; each cycle of the animation should run for 3 secons, looping infinitely.

const logoSectionOptions = {
  duration: 3000,
  iterations: Infinity
};

Applying the Animation #

Applying the animation using the Web Animation API was a lot more fiddly than with CSS. This is because I only wanted the animation to run if the logo was being hovered over or in focus. As I mentioned, by default, web animations run as soon as they are created.

To work around this, I had to first create the animation, immediately pause it, then add eventListeners for when I wanted the animation to play or pause. Additionally, since I had to apply an individual animation to each letter, I had to work with several animations at once. Here is how I executed it -

// Array to store all animations
const animations = [];

function playLogoAnimation() {
  animations.map((animation) => animation.play())
}

function pauseLogoAnimation() {
  animations.map((animation) => {
      animation.pause();
      animation.currentTime = 0; // Reset animation to start state
  })
}

function createLogoAnimation() {
  const logoSectionLeftEls = Array.from( document.querySelectorAll('.logo-section-left') );
  logoSectionLeftEls.forEach((el) => animations.push(el.animate(logoSectionLeftKeyframes, logoSectionTiming)))

  // Animation for middle and right sections here …

  // Immediately pause animation once created
  pauseLogoAnimation();
}

createLogoAnimation();

// Event listeners to play or pause animation
const siteTitleLink = document.querySelector('.site__title a');
siteTitleLink.addEventListener('mouseover', playLogoAnimation);
siteTitleLink.addEventListener('mouseout', pauseLogoAnimation);
siteTitleLink.addEventListener('keyup', (e) => {
  if ( e.keyCode === 9 ) playLogoAnimation();
});
siteTitleLink.addEventListener('keydown', (e) => {
  if ( e.keyCode === 9 ) pauseLogoAnimation();
});

Here's the CodePen with the full animation:

See the Pen MmJOzR by Ire Aderinokun (@ire) on CodePen.

CSS Animations vs the Web Animation API #

As with everything, whether to use CSS or JavaScript animations, depends very much on the particulars of the animation. As a general rule, CSS animations should be used for small, UI-related animations such as showing a tooltip. The Web Animation API should be reserved for more advanced effects that need fine-tuned control. That said, here was my comparison between the two methods for this animation.

Performance #

The performance of CSS vs JavaScript animations can vary a lot depending on which properties we are animating. Generally, it is advised to only animate the transform and/or opacity properties, as these animations can be executed on a different thread from the browser's main thread.

Changing `transform` does not trigger any geometry changes or painting, which is very good. This means that the operation can likely be carried out by the compositor thread with the help of the GPU.

CSS Triggers

Since my animations only used the transform property, I was not able to see any significant difference in performance between the two methods. Using Firefox's DevTools, I measured the frame rate of both animations and got the exact same rate of 60 FPS, even with Off Main Thread Animation enabled.

I wasn't able to find more ways to measure the performance between the two versions. If you know of any better ways, do leave a comment below.

Developer Experience #

In this case, I personally found the CSS animation easier to work with than the Web Animation API, mainly because of the extra work it took to get the animation to be played/paused using the latter. If I were doing a more complex animation, for example for a game, the Web Animation API would definitely be the way to go. However, for this case, I think the CSS animation was simpler to implement.

How I Animated the bitsofcode Logo with CSS

2017-04-26T00:00:00Z

I’m pretty new to CSS animations. For the most part, I had only used them in limited cases and mostly using libraries created by others, such as the excellent Animate.css created by Daniel Eden.

As I mentioned in Redesigning bitsofcode, the graphic designer I worked with for the new bitsofcode logo created this animation to go with it.

I knew I had to use it somewhere, so I decided to attempt recreating a section of it as a pure CSS animation.

Introduction to CSS Animations #

Before getting into how I created the logo animation, it'll be helpful to give a bit of an introduction to how CSS animations work. CSS animations make it possible for us to apply custom, complex animations to elements without needing to use additional tools or languages like JavaScript. They have a lot of benefits, such as being simpler to use and having better performance than other methods.

Creating an Animation #

To create a CSS animation, we use the @keyframes rule, with which we can name our animation and specify the CSS styles to be applied to the animating element at each step of the animation. Take, for example, the following animation, named grow, which will scale an element to twice it’s size:

@keyframes grow {
    0% {
        transform: none;
    }
    100% {
        transform: scale(2);
    }
}

When creating a custom animation, the animation name is defined after the @keyframes keyword and the animation steps are defined within the block. The steps in an animation can be thought of as a timeline, from 0, marking the start of the animation, to 100, marking the end of the animation.

Besides those two points on the timeline, we can have as many steps in between as we like. For example, let’s adapt the grow animation from above to a pulse. Instead of simply enlarging the element, we also return it back to its original size.

@keyframes pulse {
    0% {
        transform: none;
    }
    50% {
        transform: scale(2);
    }
    100% {
        transform: none;
    }
}

We also don’t have to stick to one CSS style for each point on the timeline. We can apply as many styles as we want, like we apply styles to a selector.

@keyframes pulseAndChangeColour {
    0% {
        transform: none;
        background-color: red;
    }
    25% {
        background-color: blue;
    }
    50% {
        transform: scale(2);
        background-color: green;
    }
    75% {
        background-color: pink;
    }
    100% {
        transform: none;
        background-color: orange;
    }
}

Using an Animation #

Once we have created the animation, we can then apply it to any element using the animation properties. There are nine properties related to applying CSS animations.

Property	Description
`animation-name`	Specifies the name of the `@keyframes` rule to apply
`animation-delay`	Specifies a delay before the animation begins
`animation-duration`	Specifies the amount of time it should take for one cycle
`animation-iteration-count`	Specifies how many times to run a cycle of the animation
`animation-direction`	Specifies in which direction to run through the animation timeline
`animation-play-state`	Determines if the animation is playing or paused
`animation-timing-function`	Specifies how the animation transitions between steps
`animation-fill-mode`	Specifies the values applied to the element and the start and end of the animation
`animation`	Shorthand for all other properties

For example, we can apply our pulseAndChangeColour animation for 3 seconds, on an infinite loop, alternating directions, after a delay of 2 seconds, with these declarations -

.animated-element {
    animation-name: pulseAndChangeColour;
    animation-duration: 3s;
    animation-iteration-count: infinite;
    animation-direction: alternate;
    animation-delay: 2s;
}

Support #

Animating the bitsofcode Logo #

In my CSS animation, I decided to recreate just a section of the full animation that was created. Here's my recreation of that section -

Prepping the SVG Element #

The logo, as you would imagine, is an SVG element. Each letter (or, in the case of the letter "o", half of a letter), is its own <path>. This allowed me to target each letter individually or target specific groups of letters together.

Based on the animation, there are three discernible groups of letters, which I grouped together using three classes:

.logo-section—left: The letters "bitso" (with the opening o)
.logo-section—middle: The letters "ofco" (with the closing o and opening o)
.logo-section—right: The letters "ode" (with the closing o)

A separate @keyframes rule was created for each of those sections, as the animation is slightly different for each of them.

Creating a Timeline #

As I mentioned, each CSS animation has a timeline of events, from 0% to 100%. Since this was a bit more complex an animation than the pulse examples, I found it helpful to specifically write out the timeline before writing any CSS.

Let’s take the animation for the left section of the logo. These were the basic steps -

Move left
Return to middle
Stay in middle (while waiting for the right section to move right)
Move left
Rotate
Slowly increase rotation
Return to unrotated position
Return to middle

Next, I had to takes these steps and map them onto a timeline, from 0 to 100%, where each step should be.

This could then be translated into an actual CSS animation timeline.

@keyframes logoSectionLeft {
  0% {
    /* Initial Position */
  }

  12.5% {
    /* 1. Move Left */
  }

  25% {
    /* 2. Return to middle */
  }

  50% {
    /* 3. Stay in middle (while waiting for the right section to move right) */
  }

  62.5% {
    /* 4. Move left */
  }

  67%,
  72% {
    /* 5. Rotate */
  }

  82% {
    /* 6. Slowly increase rotation */
  }

  87.5% {
    /* 7. Return to unrotated position */
  }

  100% {
    /* 8. Return to middle */
  }
}

Styling each Step #

Once the timeline had been mapped out, I could then add the CSS styles for each step. For this animation, the only property I used was the transform property with translate() and rotate() functions.

Here’s the complete animation keyframes for the left section -

@keyframes logoSectionLeft {
  0% {
    /* Initial Position */
    transform: none;
  }

  12.5% {
    /* 1. Move Left */
    transform: translateX(-15px);
  }

  25%,
  50% {
    /* 2. Return to middle */
    /* 3. Stay in middle (while waiting for the right section to move right) */
    transform: none;
  }

  62.5% {
    /* 4. Move left */
    transform: translateX(-15px);
  }

  67%,
  72% {
    /* 5. Rotate */
    transform: translateX(-15px) rotate(-10deg);
  }

  82% {
    /* 6. Slowly increase rotation */
    transform: translateX(-15px) rotate(-15deg);
  }

  87.5% {
    /* 7. Return to unrotated position */
    transform: translateX(-15px);
  }

  100% {
    /* 7. Return to middle */
    transform: none;
  }
}

Applying the Animation #

Finally, I wanted to apply the animation only when the anchor element surrounding the logo was in focus or hovered above. I wanted a cycle of the animation to take 3 seconds, and for it to repeat indefinitely.

.site__title a:hover .logo-section-left,
.site__title a:focus .logo-section-left {
    animation-name: logoSectionLeft;
    animation-duration: 3s;
    animation-timing-function: ease-in-out;
    animation-iteration-count: infinite;
}

That’s it! I created a CodePen with the full animation if you want to take a look.

See the Pen bitsofcode by Ire Aderinokun (@ire) on CodePen.

Asynchronous Functions 101

2017-04-13T00:00:00Z

One of the major advantages of JavaScript is that everything is asynchronous. For the most part, different parts of your code don’t affect the execution of others.

doALongThing(() => console.log("I will be logged second!"));
console.log("I will be logged first!");

Unfortunately, this is also one of JavaScript's major disadvantages. Because everything is asynchronous by default, it makes it that much more difficult when you do want to execute code synchronously.

The first solution to this problem was callbacks. If a part of your code was dependent on the result of something else, we would have to nest our code -

doSomething((response) => {
   doSomethingElse(response,(secondResponse) => {
        doAThirdThing(secondResponse);
   });
})

Nesting callbacks on callbacks, as we know, became unmaintainable. So, the solution of promises was created. This allowed us to deal with synchronous code in a much cleaner, flatter, way.

doSomething()
.then((response) => doSomethingElse(response))
.then((secondResponse) => doAThirdThing(secondResponse));

// Even cleaner
doSomething().then(doSomethingElse).then(doAThirdThing);

As with everything, promises were not perfect either. So, as part of the ES2017 Specification, another method for dealing with synchronous code was defined; asynchronous functions. These allow us to write asynchronous code as if it were synchronous.

Creating an Asynchronous Function #

An asynchronous function is defined with the async function expression. A basic function looks like this -

async function foo() {
    const value = await somePromise();
    return value;
}

We define a function as an asynchronous function by preceding the function declaration with async. This keyword can be used with any function declaration syntax -

// Basic function
async function foo() {  … }

// Arrow function
const foo = async () => { … }

// Class methods
class Bar {
    async foo() { … }
}

Once we have defined a function as an asynchronous function, we are able to use the await keyword. This keyword is placed before the calling of a promise, which will pause the execution of the function until the promise is either fulfilled or rejected.

Handling Errors #

Error handling in asynchronous functions is done with the help of try and catch blocks. The first block, try, allows us to attempt an action. The second block, catch, is called if the action is failed. It accepts one paramter containing whatever error was thrown.

async function foo() {
    try {
        const value = await somePromise();
        return value;
    }
    catch (err) {
        console.log("Oops, there was an error :(");
    }
}

Using an Asynchronous Function #

Asynchronous functions aren't really a replacement for promises. The two work hand in hand. An asynchronous function will await the execution of a promise, and an asynchronous function will always return a promise.

The promise returned by an asynchronous function will resolve with whatever value is returned by the function.

async function foo() {
    await somePromise();
    return ‘success!’
}

foo().then((res) => console.log(res)) // ‘success!’

If an error is thrown, the Promise will be rejected with that error.

async function foo() {
    await somePromise();
    throw Error(‘oops!’)
}

foo()
.then((res) => console.log(res))
.catch((err) => console.log(err)) // ‘oops!’

Executing Asynchronous Functions in Parallel #

With promises, we can execute multiple promises in parallel using the Promise.all() method.

function pause500ms() {
    return new Promise((res) => setTimeout(res, 500));
}

const promise1 = pause500ms();
const promise2 = pause500ms();

Promise.all([promise1, promise2]).then(() => {
   console.log("I will be logged after 500ms");
});

With asynchronous functions, we have to work around a bit to get the same effect. If we just list each function to await in sequence, they will be executed in sequence since await will pause the execution of the rest of the function.

async function inSequence() {
    await pause500ms();
    await pause500ms();
    console.log("I will be logged after 1000ms");
}

This will take 1000ms to complete, because the second await is not even started until the first has been completed. To get around this, we need to reference the functions in this way -

async function inParallel() {
    const await1 = pause500ms();
    const await2 = pause500ms();
    await await1;
    await await2;
    console.log("I will be logged after 500ms");
}

This will take only 500ms to complete because both pause500ms() functions are being executed at the same time.

Promises or Asynchronous Function? #

As I mentioned, asynchronous functions aren't a replacement for promises, the two are used together. Asynchronous functions provide an alternative, and in some cases better, way of working with promise-based functions. But, they still use and produce promises.

Since a promise is returned, an asynchronous function can be called by another asynchronous function, or a promise. We can mix and match depending on which syntax is best suited for each case.

function baz() {
    return new Promise((res) => setTimeout(res, 1000));
}

async function foo() {
    await baz();
    return 'foo complete!';
}

async function bar() {
    const value = await foo();
    console.log(value);
    return 'bar complete!';
}

bar().then((value) => console.log(value));

The following will occur:

Wait 1000ms
Log "foo complete!"
Log "bar complete!"

Support #

At the time of writing, both asynchronous functions and promises are available in the current versions of all major browsers, with the exception of Internet Explorer and Opera Mini.

Redesigning bitsofcode

2017-03-27T00:00:00Z

Welcome to the new bitsofcode! Since launching this blog over 2 years ago, I’ve had two designs, this being the third.

You can check out the first and second designs using the WayBack Machine. The first one looks particularly embarrassing... Anyway, I thought I would share here my process in this redesign and rebuild.

A Logo (Finally) #

Over the past two years, I haven’t really had a solid visual identity for bitsofcode. Besides the yellow colour, there hasn’t been any other identifiable asset for the blog. This hasn't been for lack of trying, I had attempted to design a logo myself on several occasions, but never ended up with anything I actually liked. In the end, I just decided to hire someone, in this case the amazing designer Seyi Olusanya, and the bitsofcode logo was born.

I think Seyi did really well in embodying the personality of the blog. He also had the idea to create a fun animation with the logo, and came up with this -

I decided to implement a part of that video as a CSS animation. If you haven't already noticed, the animation is activated when users interact with the logo in the header. I plan on writing about how I created the CSS animation in more detail in a later article.

Design Decisions #

Despite the resultantly simple design, I spent a lot of time on the redesign. There were a couple decisions I particularly dwelled on.

How to use the theme colour? #

In my previous design, I had used the theme colour, #FFDB3C, a lot more, particularly on the home page. In this design, I wanted the yellow to be more of an accent, rather than a primary colour.

I played around with many different ways of having the yellow be an accent, before eventually settling with having a yellow border around the entire page, and using it for highlights in certain cases. I also created a custom code highlighting theme, in which I made use of the yellow as the primary colour.

To hamburger or not to hamburger? #

How to handle the navigation was a question I fought with for a while. I had used the hamburger menu in my last design, mainly because the navigation wasn't that important. The most important item on the menu was home, which could also be accessed through the logo.

I decided to use the hamburger menu again for a few reasons. First, like in the previous design, the contents of the menu don't seem that important. People access articles through the page content, not through the menu. Second, I felt like the other design decisions I had made left it the best choice. For example, I wanted the logo to be in the middle, which didn't leave much space for a full menu in the header as well.

So, although the hamburger menu definitely has it's shortcomings, I felt it was the best option for this particular case.

Performance Improvements #

A major reason I wanted to redesign (and, more importantly, rebuild) the site was because I felt I could make a lot of improvements performance-wise. Over the past year in particular, I've researched into and written a decent amount about performance, yet hadn't really implemented that knowledge on this site itself.

Overall, the changes I made have been a decent improvement. My score on PageSpeed Insights went from 77 to 97 on Desktop (70 to 96 on Mobile).

To achieve this, I made the following optimisations.

Use System Fonts #

In my last design, 33.8% of bytes downloaded were from fonts alone. This was clearly an area ripe for improvement. In this revamp, I cut that down to zero by using System Fonts instead. For the Sans-Serif font, which is used for the majority of the site, I used the same system font stack used by Wordpress -

p {
    font-family: -apple-system,
                 BlinkMacSystemFont,
                 "Segoe UI",
                 Roboto,
                 Oxygen-Sans,
                 Ubuntu,
                 Cantarell,
                 "Helvetica Neue",
                 sans-serif;
}

For the Monospace font used in code samples, I put together my own stack based on fonts I liked -

code {
    font-family: "Inconsolata",
                 Consolas,
                 Monaco,
                 "Andale Mono",
                 "Ubuntu Mono",
                 monospace;
}

This is what a typical article looks like on Mac versus Windows -

Reduce Assets / Dependencies #

In addition to cutting out Google fonts, I was able to improve performance by cutting down on assets I didn’t really need to be using. In particular, I was able to cut the following:

Font Awesome Icon Fonts: Instead, I use SVG for all icons.
jQuery: I was barely even using jQuery in the previous design, so this was pretty easy to cut out and reimplement the logic in plain JavaScript.

On the flipside, I had to add some new dependencies due to the addition of Carbon ads on the site. However, there was still a net decrease in assets being loaded.

Optimize CSS Delivery #

A major improvement I made was to optimise the delivery of the main styles of the page. A pretty common “Should Fix” message many sites get on PageSpeed Insights is the following:

Eliminate render-blocking JavaScript and CSS in above-the-fold content. None of the above-the-fold content on your page could be rendered without waiting for the following resources to load. Try to defer or asynchronously load blocking resources, or inline the critical portions of those resources directly in the HTML

The way to fix this is by having some critical CSS directly in our document <head>. Then, once the page has been loaded and is rendering on the page, use JavaScript to fetch and insert the full CSS file. I used the loadCSS library to help do this. To generate the critical CSS, I used a postCSS plugin I created and am testing out (more on that later!).

The <head> of the document now looks something like this -

<head>
    <meta charset="utf-8">
    <title>bitsofcode</title>

    <!-- loadCSS library -->
    <script >
		// https://github.com/filamentgroup/loadCSS
		!function(e){"use strict";var n=function(n,t,o){function i(e){return a.body?e():void setTimeout(function(){i(e)})}function r(){l.addEventListener&&l.removeEventListener("load",r),l.media=o||"all"}var d,a=e.document,l=a.createElement("link");if(t)d=t;else{var s=(a.body||a.getElementsByTagName("head")[0]).childNodes;d=s[s.length-1]}var f=a.styleSheets;l.rel="stylesheet",l.href=n,l.media="only x",i(function(){d.parentNode.insertBefore(l,t?d:d.nextSibling)});var u=function(e){for(var n=l.href,t=f.length;t--;)if(f[t].href===n)return e();setTimeout(function(){u(e)})};return l.addEventListener&&l.addEventListener("load",r),l.onloadcssdefined=u,u(r),l};"undefined"!=typeof exports?exports.loadCSS=n:e.loadCSS=n}("undefined"!=typeof global?global:this);
    </script>

    <!-- Critical CSS -->
    <style id="inlineCSS">
		.site__nav ul{ display:flex;flex-wrap:wrap; }
		/* More critical CSS */
    </style>

    <!-- If JavaScript is not enabled, just include the full CSS file like normal -->
    <noscript><link rel="stylesheet" href="/assets/css/main.css"></noscript>

    <!-- Otherwise, call loadCSS function -->
    <script id="loadCSS">loadCSS("/assets/css/main.css");</script>
</head>

Unfortunately, since I’m hosting with Ghost, I don’t have complete control over what is in my document <head>. So, because Ghost inserts some more externally sourced CSS files in my document <head>, my PageSpeed Insights score isn’t as great as it could be.

shrugs

What's Next? #

Although this new design is an improvement on the previous one in a number of ways, there is definitely still room for more improvement. As I learn more, I will like to make incremental changes as I go.

I'd also appreciate any feedback, comments, or suggests I can get. I could only do so much testing myself, so if you are experiencing any issues on the site, do leave a comment.

✌🏾

Making Alix, a Chrome Extension for Linting HTML

2017-03-14T00:00:00Z

Last week, I wrote about how you can use CSS selectors to help lint your HTML. The general idea behind this concept was that we can use some of the more advanced CSS selectors, such as :not(), to select certain types of elements in the document. For example, we can select all images that don't have alternative text, and apply styling to highlight them on the page.

img:not([alt]) {
    border: 5px solid red;
}

/* Add an error message */
img:not([alt])::after {
   content: "Images must have an alt attribute";
}

Since writing that article, I discovered that quite a few other people have used this idea before. However, the most extensive one I have found was a11y.css, created by Gaël Poupard. So, instead of creating my own, I've decided to just help make that one better.

To make this much easier to use for anyone, I decided to make it into a browser extension (in this case, Chrome).

Get the Extension | View Source

The extension allows you easily apply the stylesheet to any page. Here's how I made it.

Declaring a Chrome Extension: The Manifest #

The first thing we need to do to create an extension for Chrome is to create a Manifest file. This works in a similar way to the manifest file we create for Progressive Web Apps. It includes various bits of information that Chrome needs to determine what the extension does, and what permissions it requires.

This is the manifest.json file for Alix -

{
  "manifest_version": 2,

  "name": "Alix for Chrome",
  "short_name": "Alix",
  "description": "Lorem ipsum",
  "version": "1.1",

  "permissions": [
      "activeTab"
  ],

  "browser_action": {
    "default_title": "Toggle Alix",
    "default_popup": "popup/index.html",
    "default_icon": {
      "19": "images/toolbar-chrome.png",
      "38": "images/toolbar-chrome@2x.png"
    }
  },

  "icons": {
      "128": "icon_128.png",
      "16": "icon_16.png",
      "48": "icon_48.png"
   },

  "web_accessible_resources": [
    "a11y.css/a11y-en_advice.css",
    "a11y.css/a11y-en_error.css",
    "a11y.css/a11y-en_obsolete.css",
    "a11y.css/a11y-en_warning.css",
    "a11y.css/a11y-fr_advice.css",
    "a11y.css/a11y-fr_error.css",
    "a11y.css/a11y-fr_obsolete.css",
    "a11y.css/a11y-fr_warning.css"
  ]
}

Here's what some of the options mean -

manifest_version: The version of the manifest file format that the extension requires. As of Chrome 18, version 2 is required.
permissions: The permissions your extension is requesting access to. Alix only requires access to whichever tab is currently active at the time.
browser_action: This puts an icon in the main Chrome toolbar, and allows us to specify an action to be taken when that icon is clicked.
- default_title: The default title for the toolbar icon.
- default_popup: The HTML page to load when the icon is clicked.
web_accessible_resources: An array of paths to resources that may be used on the web page.

The popup is just a simple HTML page, which we linked to in our manifest file under browser_action/default_popup. By defining the popup here, it is automatically triggered when the toolbar icon is clicked.

We can style this page any way we want like any regular HTML page.

Finally, what we want to do is apply the relevant a11y.css stylesheet to the current active tab. To do that, we have to run a script on the tab which will create a <link rel="stylsheet"> element on the page, linking to the a11y.css stylesheet.

To run a script on the current active tab, we can use the chrome.tabs.executeScript() method. This method accepts an object with some options. The relevant option for this purpose is code, to which we pass a string of the code we want to be executed.

function addStylesheet() {

    // Get file path based on language and level options from form
    const file = `/a11y.css/a11y-${options.language}_${options.level}.css`;

	const code = `
		var stylesheet = document.createElement("link");
		stylesheet.rel = "stylesheet";
		stylesheet.href = chrome.extension.getURL("${file}");
		stylesheet.id = "a11yCSS";
		document.getElementsByTagName("head")[0].appendChild(stylesheet);
	`;

	// Execute script on active tab
    chrome.tabs.executeScript({code: code});
}

If we inspect the page, we can see that the stylesheet has been added as the last element in the document head.

That's it! As always, you can view the source code or install the extension from Chrome Web Store.

Thanks to Gaël Poupard for creating a11y.css!

Linting HTML using CSS

2017-03-07T00:00:00Z

When HTML is written incorrectly, nothing much happens. Because of this, it's easy to have invalid, unsemantic, or unaccessible bits in markup without it being obvious.

There are many ways we can lint our HTML to discover and fix these issues, for example using the W3C Markup Validation Service. Another thing we can do, which can be more easily integrated into a development workflow, is to use some slightly advanced CSS selectors to highlight potential problem areas. Here are a few things we can use CSS selectors to help us catch out.

Inline Styles #

*[style] {
    border: 5px solid red; /* Style to make the elements noticeable */
}

This selector will target any element on the page that has inline styles applied to it. As a general rule, inline styles should be avoided as they are difficult to override due to their increased level of specificity. Although inline styles may be necessary in some cases, this selector will help highlight them so a decision can be made on a case-by-case basis.

With the problem elements selected, we can apply any style to make them more visibly obvious on the page, e.g. a big red border.

Faulty or Missing Link Targets #

a:not([href]),
a[href="#"],
a[href=""],
a[href*="javascript:void(0)"] { … }

These selectors will highlight any anchor elements that either do not have any href attribute at all, or have a meaningless one.

Unaccessible Images #

img:not([alt]) { ... }

As a blanket rule, all images should have an alt attribute. When this attribute is missing, most screenreaders will read out the value of the src attribute instead which, of course, is not useful to the user and can in fact be confusing.

It should be noted that the above selector will not select images with a null/empty alt attribute, i.e. images with alt="". This is because a null alt attribute can be an intentional way of having a screen reader skip over the image, which is useful if, for example, the image is purely decorative. It could, however, still be useful to have these highlighted, which we can do with the following selector -

img[alt=""] { ... }

Missing Document Language #

html:not([lang]),
html[lang=""] { ... }

An important attribute that should be present on all html elements is the language attribute. This attribute is a signal to screen readers what language the page is in, which can determine how the content of the page is read aloud.

Here's an example of what can happen when the lang attribute is missing -

Share @HTeuMeuLeu's video to show why setting a default language (eg. lang="en") is important. 😂 https://t.co/tjn8GvPVKM — overflow: heydon (@heydonworks) February 23, 2017

Incorrect Character Set #

meta[charset]:not([charset="UTF-8"]) { ... }

This selector targets any meta character set tag that is not set to UTF-8. This tag tells the browser to use the UTF-8 form of character encoding, which is presently the recommended form for HTML documents. Having this tag is therefore required for valid HTML.

Ideally, this tag should also be the first element after the opening <head> tag. We can check for this using the following selector -

meta[charset="UTF-8"]:not(:first-child) { ... }

Unaccessible Viewport Attributes #

meta[name="viewport"][content*="user-scalable=no"],
meta[name="viewport"][content*="maximum-scale"],
meta[name="viewport"][content*="minimum-scale"] { ... }

This selector can be used to highlight unaccessible viewport meta attributes. It is generally advised that we avoid restricting the user's ability to manipulate the viewport by shrinking and enlarging it. So, using user-scalable=no, maximum-scale, or minimum-scale should never be used.

Unlabelled Form Elements #

input:not([id]),
select:not([id]),
textarea:not([id]) { ... }

label:not([for]) { ... }

Form elements are perhaps the most important elements when it comes to labelling. Although there are several ways to label a form element, the most common way is by having an ID on the element that is referenced by a label element. The above selector checks for form elements that do not have an ID, and label elements that are not explicitly linked to a form element using the for attribute.

Another type of labelling that is important for form elements is via the name attribute. While the id attribute is used for labelling the element in the context of the HTML document, the name attribute is used to reference the the element when submitted with the form data.

input:not([name]),
select:not([name]),
textarea:not([name]) { ... }

Additionally, besides the form elements themselves, it is useful to give the form element itself a name and/or id.

form:not([name]):not([id]) { ... }

This selector will highlight any form element that is missing both name and id attributes.

Empty Interactive Elements #

button:empty,
a:empty { ... }

Interactive elements like links or buttons are typically labelled by their content. Although it is possible to label these elements using other methods, such as an aria-label attribute, having them be empty is likely a sign of something wrong. This selector will highlight any links of buttons that have no HTML content inside them.

Unnecessary or Deprecated Attributes #

script[type="text/javascript"],
link[rel="stylesheet"][type="text/css"] { ... }

Finally, we can use CSS selectors to highlight attributes in our HTML that are deprecated or no longer needed.

Edit (14/03/2017): To apply this concept, I made a Chrome Extension. I wrote about it in my followup post, Making Alix, a Chrome Extension for Linting HTML

Asynchronous vs Deferred JavaScript

2017-02-28T00:00:00Z

In my article on Understanding the Critical Rendering Path, I wrote about the effect JavaScript files have on the Critical Rendering Path.

JavaScript is considered a "parser blocking resource". This means that the parsing of the HTML document itself is blocked by JavaScript. When the parser reaches a <script> tag, whether that be internal or external, it stops to fetch (if it is external) and run it.

This behaviour can be problematic if we are loading several JavaScript files on a page, as this will interfere with the time to first paint even if the document is not actually dependent on those files.

Fortunately, the <script> element has two attributes, async and defer, that can give us more control over how and when external files are fetched and executed.

Normal Execution #

Before looking into the effect of the two attributes, we must first look at what occurs in their absence. By default, as mentioned above, JavaScript files will interrupt the parsing of the HTML document in order for them to be fetched (if not inline) and executed.

Take, for example, this script element located somewhere in the middle of the page -

<html>
<head> ... </head>
<body>
    ...
    <script src="script.js">
    ....
</body>
</html>

As the document parser goes through the page, this is what occurs -

The HTML parsing is paused for the script to be fetched and executed, thereby extending the amount of time it takes to get to first paint.

The `async` Attribute #

The async attribute is used to indicate to the browser that the script file can be executed asynchronously. The HTML parser does not need to pause at the point it reaches the script tag to fetch and execute, the execution can happen whenever the script becomes ready after being fetched in parallel with the document parsing.

<script async src="script.js">

This attribute is only available for externally located script files. When an external script has this attribute, the file can be downloaded while the HTML document is still parsing. Once it has been downloaded, the parsing is paused for the script to be executed.

The `defer` Attribute #

The defer attribute tells the browser to only execute the script file once the HTML document has been fully parsed.

<script defer src="script.js">

Like an asynchronously loaded script, the file can be downloaded while the HTML document is still parsing. However, even if the file is fully downloaded long before the document is finished parsing, the script is not executed until the parsing is complete.

Asynchronous, Deferred or Normal Execution? #

So, when should we use asynchronous, deferred, or normal JavaScript execution? As always, it depends on the situation, and there are a few questions to consider.

Where is the `<script>` element located? #

Asynchronous and deferred execution of scripts are more important when the <script> element is not located at the very end of the document. HTML documents are parsed in order, from the first opening <html> element to it's close. If an externally sourced JavaScript file is placed right before the closing </body> element, it becomes much less pertinent to use an async or defer attribute. Since the parser will have finished the vast majority of the document by that point, JavaScript files don't have much parsing left to block.

Is the script self-contained? #

For script files that are not dependent on other files and/or do not have any dependencies themselves, the async attribute is particularly useful. Since we do not care exactly at which point the file is executed, asynchronous loading is the most suitable option.

Does the script rely on a fully parsed DOM? #

In many cases, the script file contains functionality that requires interaction with the DOM. Or, it may have a dependency on another file included on the page. In these cases, the DOM must be fully parsed before the script should be executed. Typically, such a file will be placed at the bottom of the page to ensure everything before it has been parsed. However, in situation where, for whatever reason, the file in question needs to be placed elsewhere, the defer attribute can be used.

Is the script a (small) dependency? #

Finally, if the script is relatively small, and/or is depended on by other files, it may be more useful to have it defined inline. Although having it inline will block the parsing of the HTML document, it should not be a significant interference if it's a small size. Additionally, if it is depended on by other files, the minor blocking may be necessary.

Support and Modern Browser Engines #

The support for the async and defer attributes is very widespread -

It is worth noting that the behaviour of these attributes may be slightly different across different JavaScript engines. For example, in V8 (used in Chromium), an attempt is made to parse all scripts, regardless of their attributes, on a separate dedicated thread for script execution. This way, the "parser blocking" nature of JavaScript files should be minimised as a default.

"What's the typeof null?", and other confusing JavaScript Types

2017-02-21T00:00:00Z

The typeof operator in JavaScript evaluates and returns a string with the data type of an operand. For example, to find the type of 123, we would write -

typeof 123

This will return a string with the type of 123, which, in this case, will be "number". In addition to "number", the typeof operator can return one of 6 potential results -

typeof 123 // "number"
typeof "abc" // "string"
typeof true // "boolean"
typeof {a: 1} // "object"
typeof function foo() {} // "function"
typeof undefined // "undefined"
typeof Symbol('foo') // "symbol"

In the above examples, it's pretty straightforward what the type of the operands will be. However, there are a few cases where it is unclear or misunderstood what the type of the operand should be.

What's the `typeof typeof 123`? #

typeof typeof 123 // "string"

What is the type of a typeof expression? Well, the typeof operator always returns a string with the type of the operand passed to it. If the resultant type of the expression is, for example, a number, what will be returned is "number". This means that, regardless of resultant type, the type of a typeof [any operand], will always be a string.

What's the `typeof NaN`? #

typeof NaN // "number"

The type of NaN, which stands for Not a Number is, surprisingly, a number. The reason for this is, in computing, NaN is actually technically a numeric data type. However, it is a numeric data type whose value cannot be represented using actual numbers. So, the name "Not a Number", doesn't mean that the value is not numeric. It instead means that the value cannot be expressed with numbers.

This also explains why not all NaN values are equal. For example -

const NaN1 = 2 * "abc";
const NaN2 = 2 * "abc";

NaN1 === NaN2 // false

Those two NaN values are not equal because they are not necessarily the same unrepresentable number.

What's the `typeof [1,2,3]`? #

typeof [1,2,3] // "object"

The typeof an array is an object. In JavaScript, arrays are technically objects; just with special behaviours and abilities. For example, arrays have a Array.prototype.length property, which will return the number of elements in the array. Arrays also have special methods, e.g. Array.prototype.push() or Array.prototype.unshift() (See JavaScript Array Methods - Mutator Methods).

To differentiate an Array object from an Object object, we can use the Array.isArray() method.

Array.isArray( [1,2,3] ) // true
Array.isArray( { a: 1 } ) // false

What's the `typeof null`? #

typeof null // "object"

The null value is technically a primitive, the way "object" or "number" are primitives. This would typically mean that the type of null should also be "null". However, this is not the case because of a peculiarity with the way JavaScript was first defined.

In the first implementation of JavaScript, values were represented in two parts - a type tag and the actual value. There were 5 type tags that could be used, and the tag for referencing an object was 0. The null value, however, was represented as the NULL pointer, which was 0x00 for most platforms. As a result of this similarity, null has the 0 type tag, which corresponds to an object.

What's the `typeof class Foo {}`? #

typeof class Foo {} // "function"

Finally, we have Classes. Classes were introduced in ES2015 (ES6) as a better syntax for prototype-based inheritance. Before Classes, to make an inheritable object, we would have to use a function.

function Dog() { }
Dog.prototype.bark = function() {
    alert("woof!");
}

const snoopy = new Dog();
snoopy.bark() // alert("woof!")

With Classes, we can create the same object this way -

class Dog {
    bark() {
        alert("woof!");
    }
}

const snoopy = new Dog();
snoopy.bark() // alert("woof!")

However, Classes have always just been a syntactical wrapper around the function method. The same function is actually being created, but just with the author writing it in a different, cleaner way. This is why the typeof a Class, is still just a Function.

Optimising GIFs for the Web

2017-02-14T00:00:00Z

Like a lot of people, I like GIFs. I like to use them in my articles to illustrate functionality. For example, this GIF from my article on "Recreating the iTunes Library" -

However, a problem with this is that GIFs are heavy, the one above is a whopping 11.4 MB 😱 (NB: not exactly the image above, I couldn't actually load that on a page). Recently, I’ve found that some of my articles that are GIF-heavy tend to get incredibly slow. The reason for this is that each frame in a GIF is stored as a GIF image, which uses a lossless compression algorithm. This means that, during compression, no information is lost in the image at all, which of course results in a larger file size.

To solve the performance problem of GIFs on the web, there are a couple of things we can do.

Use HTML5 Video #

Surprisingly, the lossless compression algorithm used on GIFs is so unoptimised that video formats such as MP4 or WebM will provide a smaller file size than GIF images. Because of this, one solution to the GIF performance problem is to not use GIFs at all, and to replace them with autoplaying, looping, HTML5 Video.

By applying certain attributes to the <video> element, we can simulate the behaviour of a GIF, but with a much smaller file size. The attributes we need are -

autoplay: Immediately start playing the video without the user needing to press "play"
loop: Loop the video infinitely
muted: Although there is no audio track on the GIF, stating this attribute is needed for iOS Safari to autoplay the video
playsinline : For iOS Safari, to make sure that the video is not moved to fullscreen mode
poster: Specifies an image to be displayed while the video is downloading

To replace the GIF from the introduction to this article, we can use the following video element -

<video autoplay loop muted playsinline poster="original.jpg">
    <source type="video/webm" src="original.webm">
    <img src="original.gif">
</video>

This will give us a video that's much smaller in size, at only 1MB 😱😱!

To convert a GIF to WebM, we can use CloudConvert. Or, if you use Cloudinary, you can just change the file extension from .gif to .webm to get the video format.

Lossy Optimisation #

In some cases, because HTML5 Video doesn't work everywhere, we can't get around having to use an actual GIF. For example, when this blog post is delivered as an HTML email, an actual GIF has to be used. So, there are some optimisations we can make to the GIF itself to make it more performant.

As I mentioned, GIF compression algorithm is lossless. However, there are options for lossy compressions as well. Although this may sound like we will get visibly lower quality GIFs, lossy compression done well should not noticeably degrade the quality of the image.

There are a number of tools we can use for lossy GIF compression. One popular tool for optimising GIFs is gifsicle and giflossy. Gifsicle is a CLI for manipulating GIF image files, and giflossy is a fork of gifsicle which offers a lossy compression option (--lossy).

To use giflossy to apply a lossy compression to a GIF image, we can use the following command -

gifsicle -O3 --lossy=80 -o compressed.gif original.gif

The -03 option tells gifsicle to attempt several methods for optimisation to find the most suitable. The --lossy=80 option specifies how much to apply lossy compression. Depending on your needs, you can adjust this number. The -o compressed.gif option specifies what the output GIF should be called. Finally, we define the path to the original GIF.

Using this on the GIF example from before, we go from a 11.4MB GIF to a 6MB GIF, a 47% reduction in the size!

With these two methods combined, we can make use of GIFs in a way that doesn't degrade performance so drastically.

CSS Grid Layout Terminology, Explained

2017-02-07T00:00:00Z

In the CSS Grid Layout Specification, a grid is defined as the following -

The grid is an intersecting set of horizontal and vertical grid lines that divides the grid container’s space into grid areas, into which grid items (representing the grid container’s content) can be placed

Err… what? 🤔

CSS Grid Layout introduces a lot of new concepts; there are 17 new properties to learn, and many more new terms to understand. This can make getting started with CSS Grid Layout difficult, as new terms reference other terms and you can get into a spiral of confusion. So, here are the basic concepts and terminology of CSS Grid Layout, explained.

The Grid Container and Grid Items #

A Grid starts with the grid container. This, as it's name suggests, is the element that contains the elements of the grid. A grid container is created by setting the display property to any of the following values:

.grid-container {
    display: grid; /* Will create a block-level grid container */
    display: inline-grid; /* Will create an inline-level grid container */
    display: subgrid; /* Used on grid items that are also grid containers */
}

The grid container can be thought of like the flex container in the Flexible Box Layout Module (created with display: flex or display: inline-flex), or a basic Table (created with display: table or display: inline-table).

A grid container establishes a new grid formatting context for its child elements, which are now grid items. Special rules apply to grid items, for example -

The float and clear properties do not apply to grid items
The vertical-align property does not affect grid items
The ::first-line and ::first-letter pseudo-elements do not apply to the grid container

Grid Lines #

Grid lines are the horizontal and vertical lines which divide the grid. Each grid line has a referencing number, starting from the outer-most border of the grid container.

The grid line number is used when placing grid items within the container. We can specify that a grid item be placed at a specific grid line, or span one grid line to another.

.grid-container {
    display: grid;
    grid-template-columns: 100px 100px 100px;
    grid-template-rows: 100px 100px 100px;
}
.grid-item {
    grid-column: 2;
    grid-row-start: 1;
    grid-row-end: 3;
}

Grid lines can also be referenced by an author-given name. The example below will achieve the same result, but using named grid lines.

.grid-container {
    display: grid;
    grid-template-columns: 100px [grid-item-start] 100px [grid-item-end] 100px;
    grid-template-rows: [grid-item-start] 100px 100px [grid-item-end] 100px;
}
.grid-item {
    grid-column: grid-item-start / grid-item-end;
    grid-row-start: grid-item-start;
    grid-row-end: grid-item-end;
}

Grid Columns, Grid Rows, and Grid Tracks #

A grid column is the space between two adjacent vertical grid lines. The size of a grid column is determined by the grid-template-columns property. On the other hand, a grid row is the space between two adjacent horizontal grid lines. It's size is determined by the grid-template-rows property.

.grid-container {
    display: grid;
    grid-template-columns: 65px 1fr 65px;
    grid-template-rows: 100px 100px 100px;
}

A grid track is a just generic term for either a grid column or a grid row.

Grid Cells #

A grid cell is the intersection between a grid column and a grid row. It is a space bound by exactly four grid lines, which makes it the smallest available space within the grid.

Grid Areas #

A Grid area is any area of space within the grid container that is bound by four grid lines. It must consist of at least one, but potentially more, adjacent grid cells. This means that all grid cells are also grid areas.

We can make an element a grid area by using the grid-area property, and assign that area to a space in the grid using the grid-template-areas property (or longhand grid-template-columns or grid-template-rows properties).

For example to assign the element, .outlined, to the space outlined in purple above, we can do this -

.outlined {
	grid-area: outlined;
	border: 2px solid purple;
}

.grid-container {
    display: grid;
    grid-template-areas: "outlined outlined ."
                         "outlined outlined ."
                         ". . .";
    grid-template-columns: 100px 100px 100px;
    grid-template-rows: 100px 100px 100px;
}

The Grid #

The grid itself is the sum of all these parts. Revisiting the definition from the start,

The grid is an intersecting set of horizontal and vertical grid lines that divides the grid container’s space into grid areas, into which grid items (representing the grid container’s content) can be placed

Hopefully, this definition is a little more clear!

How calc() Works

2017-01-31T00:00:00Z

The CSS3 calc() function allows us to perform mathematical operations on property values. Instead of declaring, for example, static pixel values for an element's width, we can use calc() to specify that the width be the result of the addition of two or more numeric values.

.foo {
    width: calc(100px + 50px);
}

Why `calc()`? #

If you have used CSS pre-processors like SASS, the above example is something you may have come across.

.foo {
    width: 100px + 50px;
}

// Or using SASS variables
$width-one: 100px;
$width-two: 50px;
.bar {
    width: $width-one + $width-two;
}

However, the calc() function provides a better solution for two reasons. First, we can combine different units. Specifically, we can mix relative units such as percentages and viewport units, with absolute units such as pixels. For example, we can create an expression that will subtract a pixel value from a percentage value.

.foo {
    width: calc(100% - 50px);
}

In this example, the .foo element will always have a width that is 50px less than 100% of it's parent width.

Second, with calc(), the computed value is the expression itself, not the resulting value of the expression. When doing mathematical expressions with CSS pre-processors, the value given to the browser is the resulting value of the expression.

// Value specified in SCSS
.foo {
    width: 100px + 50px;
}

// Compiled CSS and computed value in browser
.foo {
    width: 150px;
}

However, with calc() the value parsed by the browser is the actual calc() expression.

// Value specified in CSS
.foo {
    width: calc(100% - 50px);
}

// Computed value in browser
.foo {
    width: calc(100% - 50px);
}

What this means is that the values in the browser can be more dynamic, and adapt as the viewport changes. We can have an element with a height of the viewport minus an absolute value, and it will adapt as the viewport changes.

Using `calc()` #

The calc() function can be used to perform addition, subtraction, multiplication, and division calculations with numeric property values. Specifically, it can be used with <length>, <frequency>, <angle>, <time>, <number>, or <integer> data types.

Here are a few examples -

.foo {
    width: calc(50vmax + 3rem);
    padding: calc(1vw + 1em);
    transform: rotate( calc(1turn + 28deg) );
    background: hsl(100, calc(3 * 20%), 40%);
    font-size: calc(50vw / 3);
}

Nesting `calc()`s #

calc() functions can be nested. Inner functions, however, will be treated as simple parenthesised expressions. Take, for example, the following nested expression -

.foo {
    width: calc( 100% / calc(100px * 2) );
}

The computed value of this function will be as follows -

.foo {
    width: calc( 100% / (100px * 2) );
}

Providing a Fallback #

The support for calc() is relatively widespread.

For browsers that don't support calc() as a value, the entire property-value expression is ignored. This means that we can easily provide a fallback static value that will be used by non-supporting browsers.

.foo {
	width: 90%; /* Fallback for older browsers */
    width: calc(100% - 50px);
}

When can we use `calc()`? #

The calc() function can be useful in a variety of situations.

Example 1 - Centering Elements #

Using calc() provides us yet another solution to the age-old problem of centering elements horizontally and vertically within a container. If we know the dimensions of the child element, a typical solution is to use negative margins to shift the element by half it's height and width, like this -

// Assuming .foo is 300px height and 300px width
.foo {
    position: absolute
    top: 50%;
    left: 50%;
    marging-top: -150px;
    margin-left: -150px;
}

Using the calc() function, we can achieve all of this using only on the top and left properties.

.foo {
    position: absolute
    top: calc(50% - 150px);
    left: calc(50% - 150px);
}

With the introduction of Flexbox, methods like this are less likely to be needed. However, in cases where Flexbox can't be used, e.g. if the element needs to be positioned absolutely or fixed, this method can be useful.

Example 2 - Creating a Root Grid Size #

The calc() function can be used to create a viewport-based grid out of the rem unit. We can do this by setting the root element's font-size to be a fraction of the full viewport width.

html {
	font-size: calc(100vw / 30);
}

Now, 1rem will correlate to 1/30 of the viewport width. For any text on our page, this means that it will be automatically scaled based on the viewport. Further, given the same dimension of viewport, the same amount of text will always be on the screen no matter the actual size of the viewport.

If we size other non-textual elements on the page using rem units, they will also follow this behaviour. An element with a width of 1rem will always by 1/30 of the viewport width.

Example 3 - Clarity #

Finally, calc() can be useful for making any calculations being done more obvious. For example, if you want a group of items to be 1/6th the width of their parent container, you could write it like this -

.foo {
	width: 16.666666667%;
}

However, it would be much more clear to people reading the CSS to write -

.foo {
	width: calc(100% / 6);
}

There are many more things we can do with calc(), such as creating a Grid System. It's definitely one of the most useful newer features in CSS.

Rules for Using ARIA in HTML

2017-01-24T00:00:00Z

The Web Accessibility Initiative's Accessible Rich Internet Applications Suite (WAI-ARIA, or just ARIA) is a set of tools and guidelines for making web content and applications more accessible. Most notably, it includes a suite of attributes we can add to HTML elements to embed in them more semantic information that can be read by assistive technologies.

Although ARIA can be incredibly useful, we have to be careful of when and how we use it. Thus, there are 5 rules to take into account when using ARIA in HTML.

1. Use Semantic HTML5 in Favour of ARIA #

If you can use a native HTML element or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

The number one rule for using ARIA in HTML, is to try not to use ARIA in HTML (if it’s not needed). HTML5 semantic elements provide us a wide range of elements that come with implicit meaning to them, similar to the explicit meaning we can define using ARIA.

So, wherever possible, we should use a semantic HTML element in place of an ARIA attribute.

Instead of creating a button using a <div> and ARIA role like this -

<div role="button">Click Me</div>

Incorrect method

We should just use an actual <button> element, like this -

<button>Click Me</button>

2. Don’t Alter the Meaning of Semantic Elements with ARIA Roles #

Do not change native semantics, unless you really have to.

As I mentioned, many HTML semantic elements have implicit meaning to them. When we use a <button>, for example, it is implied to user agents that this is an interactive element (interacted with through the cursor click, enter key, or space bar) that will trigger some interaction on the page. On the other hand, if we use a <a> element, it is implied to user agents that interacting with this element (through a cursor click or enter key) will navigate the user away from the page, or to a different location on the same page.

Because of the implicit meaning that many of these elements have, it is advised that we do not change them with ARIA roles.

<h1 role="button">Heading Button</h1>

Incorrect method

Instead of repurposing semantic elements, we should either use the appropriate element.

<h1><button>Heading Button</button></h1>

Preferred method

Or, as a last resort, we can apply the ARIA role to an element that doesn't carry such meaning.

<h1><span role="button">Heading Button</span></h1>

3. Interactive ARIA Elements must be Accessible by all Mediums #

All interactive ARIA controls must be usable with the keyboard.

Using an ARIA role on an element is not enough to really change the role of an element. If we are trying to change, for example, a <div> to a <button>, we need to manually add the interaction capabilities appropriate for a <button>.

In the ARIA Guidelines, there is a list of capabilities each element should have. For example, a valid button must satisfy the following requirements -

Must be clickable with a cursor
Must be clickable with the enter key
Must be clickable with the space bar

When using ARIA roles, we need to be aware of these requirements. Making an element look like a button doesn't make it one. We need to take into account how users in all mediums interact with the element.

4. Use Appropriate Roles for Visible Focusable Elements #

Do not use role="presentation" or aria-hidden="true" on a visible focusable element .

The ARIA attribute, role="presentation" implies that the element is for visual purposes only, and is not interactive in any way. The attribute, aria-hidden="true" implies that the element should be not be visible.

When we use these attributes, we need to be aware of the elements they are being applied to and what their visibility and interactive states are. For example, both these buttons will result in some users focusing on an element that doesn't exist to them.

<button role="presentation">Click Me</button>
<button aria-hidden="true">Click Me</button>

Incorrect method

These attributes should only be applied to elements who are non-interactive or not visible.

<button role="presentation" tabindex="-1">Don't Click Me</button>
<button aria-hidden="true" style="display: none;">Don't Click Me</button>

5. Interactive Elements must have an Accessible Name #

All interactive elements must have an accessible name.

Elements that can be interacted with, for example buttons and links, needs to have an "Accessible Name". The Accessible Name is determined when the Accessibility API accessible name property has a valid value.

The Accessible Name for an element can be specified depending on the type of element it is. Form inputs, for example, typically get their Accessible Name from a corresponding <label> element (see Labelling Form Elements).

<label>
  Username
  <input type="text">
</label>

<label for="password">Password</label>
<input type="password" id="password">

Other elements, for example buttons and links, can get their Accessible Name from their text content, or a label attribute (See HTML for Screen Readers).

Understanding the Critical Rendering Path

2017-01-17T00:00:00Z

When a browser receives the HTML response for a page from the server, there are a lot of steps to be taken before pixels are drawn on the screen. This sequence the browsers needs to run through for the initial paint of the page is called the "Critical Rendering Path".

Knowledge of the CRP is incredibly useful for understanding how a site's performance can be improved. There are 6 stages to the CRP -

Constructing the DOM Tree
Constructing the CSSOM Tree
Running JavaScript
Creating the Render Tree
Generating the Layout
Painting

1. Constructing the DOM Tree #

The DOM (Document Object Model) Tree is an Object representation of the fully parsed HTML page. Starting with the root element, <html>, nodes are created for each element/text on the page. Elements nested within other elements are represented as child nodes and each node contains the full attributes for that element. For example, an <a> element will have the href attribute associated with it’s node.

Take, for example, this sample document -

<html>
<head>
  <title>Understanding the Critical Rendering Path</title>
  <link rel="stylesheet" href="style.css">
</head>
<body>
  <header>
      <h1>Understanding the Critical Rendering Path</h1>
  </header>
  <main>
      <h2>Introduction</h2>
      <p>Lorem ipsum dolor sit amet</p>
  </main>
  <footer>
      <small>Copyright 2017</small>
  </footer>
</body>
</html>

This will create the following DOM Tree -

A good thing about HTML is that it can be executed in parts. The full document doesn't have to be loaded for content to start appearing on the page. However, other resources, CSS and JavaScript, can block the render of the page.

2. Constructing the CSSOM Tree #

The CSSOM (CSS Object Model) is an Object representation of the styles associated with the DOM. It is represented in a similar way to the DOM, but with the associated styles for each node, whether they explicitly declared or implicitly inherited, included.

In the style.css file from the document mentioned above, we have the folowing styles -

body { font-size: 18px; }

header { color: plum; }
h1 { font-size: 28px; }

main { color: firebrick; }
h2 { font-size: 20px; }

footer { display: none; }

This will create the following CSSOM Tree -

CSS is considered a "render blocking resource". This means that the Render Tree (see below) cannot be constructed without first fully parsing the resource. Unlike HTML, CSS cannot be used in parts because of its inherit cascading nature. Styles defined later in the document can override and change styles that were previously defined. So, if we start using CSS styles defined earlier in the stylesheet before the entirety of the stylesheet has been parsed, we may get a situation where the wrong CSS is being applied. This means that CSS must be fully parsed before we can move on to the next stage.

CSS files are only considered render blocking if they apply to the current device. The <link rel="stylesheet"> tag can accept a media attribute, in which we can specify any media query which the styles within apply to. If, for example, we have a stylesheet with a media attribute of orientation:landscape, and we are viewing the page in portrait mode, that resource will not be considered render blocking.

CSS can also be "script blocking". This is because JavaScript files must wait until the CSSOM has been constructed before it can run.

3. Running JavaScript #

JavaScript is considered a "parser blocking resource". This means that the parsing of the HTML document itself is blocked by JavaScript.

When the parser reaches a <script> tag, whether that be internal or external, it stops to fetch (if it is external) and run it. This why, if we have a JavaScript file that references elements within the document, it must be placed after the appearance of that document.

To avoid JavaScript being parser blocking, it can be loaded asynchronously be applying the async attribute.

<script async src="script.js">

4. Creating the Render Tree #

The Render Tree is a combination of both the DOM and CSSOM. It is a Tree that represents what will be eventually rendered on the page. This means that it only captures the visible content and will not include, for example, elements that have been hidden with CSS using display: none.

Using the example DOM and CSSOM above, the following Render Tree will be created -

5. Generating the Layout #

The Layout is what determines what the size of the viewport is, which provides context for CSS styles that are dependent on it, e.g. percentage or viewport units. The viewport size is determined by the meta viewport tag provided in the document head or, if no tag is provided, the default viewport width of 980px is used.

For example, the most common meta viewport value is to set the viewport size to correspond to the device width -

<meta name="viewport" content="width=device-width,initial-scale=1">

If the user visits the webpage on a device with a width of, for example, 1000px, then sizes will be based on that unit. Half the viewport will be 500px, 10vw will be 100px, and so on.

6. Painting #

Finally, in the Painting step, the visible content of the page can be converted to pixels to be displayed on the screen.

How much time the paint step takes depends on the size of the DOM, as well as what styles are applied. Some styles require more work to execute than others. For example, a complicated gradient background-image will require more time than a simple solid background colour.

Putting it All Together #

To see the Critical Rendering Path in process, we can inspect it in DevTools. In Chrome, it is under the Timeline tab (in Canary, and soon to be Chrome stable, it's renamed Performance).

Take for example, our sample HTML from above (with an added <script> tag) -

<html>
<head>
  <title>Understanding the Critical Rendering Path</title>
  <link rel="stylesheet" href="style.css">
</head>
<body>
  <header>
      <h1>Understanding the Critical Rendering Path</h1>
  </header>
  <main>
      <h2>Introduction</h2>
      <p>Lorem ipsum dolor sit amet</p>
  </main>
  <footer>
      <small>Copyright 2017</small>
  </footer>
  <script src="main.js"></script>
</body>
</html>

If we look at the Event Log for the page load, this is what we get -

Send Request - GET request sent for index.html
Parse HTML and Send Request - Begin parsing of HTML and DOM construction. Send GET request for style.css and main.js
Parse Stylesheet - CSSOM created for style.css
Evaluate Script - Evaluate main.js
Layout - Generate Layout based on meta viewport tag in HTML
Paint - Paint pixels on document

Based on this information, we can make decisions on how to optimize the Critical Rendering Path. I will go into some of these techniques in later articles.

3 New CSS Features to Learn in 2017

2017-01-10T00:00:00Z

Happy new year! 🎊

With the new year, we have a whole new set of things to learn. Although there are many new features, these are 3 new CSS features I'm most excited about adopting this year.

1. Feature Queries #

A while ago, I wrote about Feature Queries being the one CSS feature I really want. Well, now its basically here! It is now supported in every major browser (Opera Mini included) besides Internet Explorer.

Feature Queries, using the @supports rule, allow us to wrap CSS in a conditional block that will only be applied if the current user agent supports a particular CSS property-value pair. A simple example of this is to only apply Flexbox styles to browsers that support display: flex -

@supports ( display: flex ) {
  .foo { display: flex; }
}

Additionally, using operators like and and not, we can create even more complicated feature queries. For example, we can detect if a browser only supports the old Flexbox syntax -

@supports ( display: flexbox )
          and
          ( not ( display: flex ) ) {
  .foo { display: flexbox; }
}

Support #

2. Grid Layout #

The CSS Grid Layout Module defines a system for creating grid-based layouts. It has similarities with the Flexbible Box Layout Module, but is more specifically designed for page layouts, and thus has a number of different features.

Explicit Item Placement #

A grid is made up of the Grid Container (created with display: grid), and Grid Items (it's children). In our CSS, we can easily and explicitly orgnise the placement and order of the grid items, independent of their placement in the markup.

For example, in my article on The Holy Grail Layout with CSS Grid, I showed how we can use this module to create the infamous "holy grail layout".

The underlying CSS was only 31 lines -

.hg__header { grid-area: header; }
.hg__footer { grid-area: footer; }
.hg__main { grid-area: main; }
.hg__left { grid-area: navigation; }
.hg__right { grid-area: ads; }

.hg {
	display: grid;
	grid-template-areas: "header header header"
	                     "navigation main ads"
	                     "footer footer footer";
	grid-template-columns: 150px 1fr 150px;
	grid-template-rows: 100px
						1fr
						30px;
	min-height: 100vh;
}

@media screen and (max-width: 600px) {
	.hg {
		grid-template-areas: "header"
		                     "navigation"
		                     "main"
		                     "ads"
		                     "footer";
		grid-template-columns: 100%;
		grid-template-rows: 100px
							50px
							1fr
							50px
							30px;
	}
}

Flexible Lengths #

The CSS Grid Module introduces a new length unit, the fr unit, which represents a fraction of the free space left in the grid container.

This allows us to apportion heights and widths of grid items depending on the available space in the grid container. For example, in the Holy Grail Layout, I wanted the main section to take up all the remaining space after the two sidebars. To do that, I simply wrote -

.hg {
	grid-template-columns: 150px 1fr 150px;
}

Gutters #

We can specifically define gutters for our grid layout using the grid-row-gap, grid-column-gap, and grid-gap properties. These properties accept a <length-percentage> data type as value, with the percentage corresponding to the dimension of the content area.

For example, to have a 5% gutter, we would write -

.hg {
	display: grid;
	grid-column-gap: 5%;
}

Support #

The CSS Grid Module will be available in browsers as early as March this year.

3. Native Variables #

Lastly, native CSS Variables (Custom Properties for Cascading Variables Module). This module introduces a method for creating author-defined variables, which can be assigned as values to CSS properties.

For example, if we have a theme colour we are using in several places in our stylesheet, we can abstract this out into a variable and reference that variable, instead of writing out the actual value multiple times.

:root {
  --theme-colour: cornflowerblue;
}

h1 { color: var(--theme-colour); }
a { color: var(--theme-colour); }
strong { color: var(--theme-colour); }

This is something we have been able to do with the help of CSS pre-processors like SASS, but CSS Variables have the advantage of living in the browser. This means that their values can be updated live. To change the --theme-colour property above, for example, all we have to do is the following -

const rootEl = document.documentElement;
rootEl.style.setProperty('--theme-colour', 'plum');

Support #

What about Support? #

As you can see, none of these features are fully supported in every browser yet, so how do we comfortably usem the in production? Well, Progressive Enhancement! Last year I gave a talk about how to apply Progressive Enhancement in relation to CSS at Fronteers Conference. You can watch the talk below -

What CSS features are you excited about to learn in 2017?

Making a Polymer Element for CanIUse Embed

2016-12-20T00:00:00Z

About a year ago, I made an embed for caniuse.com., which pulls up-to-date data from the site into an embeddable widget, like this -

You can read about how I built it in my article, Creating an Embed for CanIUse. Lately, I have been interested in Polymer and Custom Elements, so I decided to make a Polymer element version of the embed.

How it Works #

Before getting into how the Polymer element is used, we need to revisit how the embed itself works. The embed is an iframe that loads a particular document. This document is hosted at -

https://caniuse.bitsofco.de/embed/index.html

This url accepts 2 parameters -

feat - the ID of the feature on caniuse
periods - The browser versions to display, e.g. current,past_1, future_1 etc.

For example, for the "CSS 2D Transforms" feature, the embed is hosted at -

https://caniuse.bitsofco.de/embed/index.html?feat=transforms2d&periods=future_1,current,past_1,past_2

To use the plain JavaScript embed, you have to include a placeholder element in your document that contains three pieces of data -

The feature slug
The number of future browser versions to display
The number of past browser version to display

For example, this is a placeholder for the "CSS 2D Transforms" feature -

<p class="ciu_embed" data-feature="transforms2d" data-periods="future_1,current,past_1,past_2">
  <!-- Placeholder/fallback content here -->
</p>

Finally, you have to include a script in your document that will load the actual iframe into the placeholder element.

<script src="//cdn.jsdelivr.net/caniuse-embed/1.0.1/caniuse-embed.min.js"></script>

How the Polymer Element Works #

The Polymer element replaces the plain script a user would typically include, that loads the iframe onto the page. Instead, to use the Polymer element, a user would import it onto their page and use it in the following way -

<caniuse-embed feature="transforms2d" future-versions="1" past-versions="2"></caniuse-embed>

The Polymer element then loads the iframe the same way the plain script does.

Creating the Polymer Element #

The entirety of a custom Polymer element exists in a single HTML file, within a <dom-module> element. Inside this <dom-module>, we have the HTML template, styles, and scripts associated with the custom element.

The most basic version of the <caniuse-embed> element, which will just display "Hello, World", looks like this -

<!-- Import the Polymer library first -->
<link rel="import" href="path/to/polymer/polymer.html">

<dom-module id="caniuse-embed">
	<template>
		<style>/* Custom styles here*/</style>

		<!-- HTML Template -->
		Hello, world!
	</template>
	<script>
		// Initialise Polymer element
		Polymer({
    		is: 'caniuse-embed'
    	});
	</script>
</dom-module>

To use this element in a page, we just need to import it into the document, then use the element like any other HTML element.

<html>
<head>
	<link rel="import" href="path/to/caniuse-embed.html">
</head>
<body>
	<caniuse-embed></caniuse-embed>
</body>
</html>

This will display the template, defined in the caniuse-embed.html -

Hello, world!

Adding Properties #

Now that we have created the element, we can start adding properties to it. To add properties to an element, we add them to properties in the Polymer object, specifying any details for the property.

For the <caniuse-embed>, there are three properties - feature, futureVersions, and pastVersions.

Polymer({
	is: 'caniuse-embed',
	properties: {
      feature: String,
      futureVersions: String,
      pastVersions: String
    }
})

When using the property, users can add values to them by adding them as attributes to the element. Note that properties that are written in camelCase are converted to kebab-case when being used as properties.

<caniuse-embed feature="viewport-units" future-versions="1" past-versions="2"></caniuse-embed>

We can access the values of properties in our template by wrapping it in [[ propertyName ]], which signifies data binding.

<template>
Feature: [[feature]]
Future Versions: [[futureVersions]]
Past Versions: [[pastVersions]]
</template>

We can also access the values of properties in the script, using this.propertyName -

<script>
console.log(this.feature)
console.log(this.futureVersions)
console.log(this.pastVersions)
</script>

Styling the Element #

We add styling to our custom element in the <style> block within the template. To style the actual element created, in this case <caniuse-embed>, we use the :host selector.

For the caniuse embed, I was just loading an iframe, so I didn't need to add much styling, besides setting the <caniuse-embed> to full-width.

<template>
	<style>
		:host {
			display: block;
			width: 100%;
		}
	</style>
</template>

Loading the Embed #

Finally, I need to actually load the iframe into the template with the appropriate url. There are two ways I could do this

Have the iframe already in the template, and use data binding to add the properties to the particular parts of the url
Create the iframe using javascript and insert it into the template

For this embed, I chose to use the latter method. This is because, the way in which the properties are used to build the url, is not the same way in which they are passed to the template. This means that, for the pastVersions and futureVersions properties in particular, I needed to convert that information into the way in which the embed expects in the url.

To do this, I used the ready() method, which executes a function when the element is ready.

Polymer({
    is: 'caniuse-embed',
    properties: { ... },
    ready: function() {

      // Custom function to convert the two properties into the url-ready string
      const periods = calculatePeriods(this.futureVersions, this.pastVersions);

      this.innerHTML = `
      <iframe src="//caniuse.bitsofco.de/embed/index.html?feat=${this.feature}&periods=${periods}"
              frameborder="0"
              width="100%"
              height="400px"></iframe>
      `;

    }
})

Putting it all Together #

As I mentioned, the entirety of the custom element is defined in one HTML file, caniuse-embed.html. This is what that file looks like -

<link rel="import" href="../polymer/polymer.html">

<dom-module id="caniuse-embed">

  <template>
    <style>
      :host {
        display: block;
        width: 100%;
      }
    </style>

    <!-- HTML added in ready() -->

  </template>

  <script>
  Polymer({
    is: 'caniuse-embed',
    properties: {
      feature: String,
      futureVersions: String,
      pastVersions: String
    },
    ready: function() {

      if ( !this.feature ) this.textContent = `A feature was not included. Go to <a href='https://caniuse.bitsofco.de/#polymer'>https://caniuse.bitsofco.de/#polymer</a> to get help.`;

      const periods = calculatePeriods(this.futureVersions, this.pastVersions);

      this.innerHTML = `
      <iframe src="//caniuse.bitsofco.de/embed/index.html?feat=${this.feature}&periods=${periods}"
              frameborder="0"
              width="100%"
              height="400px"></iframe>
      `;

    }
  });


  function calculatePeriods(futureVersions, pastVersions) { ... }

  // Logic to handle re-sizing of iFrame here

  </script>

</dom-module>

If you would like to see the full source for the element, you can see it on my GitHub repository, ireade/caniuse-embed-polymer. There, you can also find details on how to use it in your website or application.

An Overview of Client-Side Storage

2016-12-13T00:00:00Z

Storing data directly within the browser has a lot of benefits, the main one being quick and network-independent access to a "database". There are currently four active methods (plus one deprecated), for storing data on the client side -

Cookies
Local Storage
Session Storage
IndexedDB
WebSQL (deprecated)

Cookies #

Cookies are the classic way of storing simple string data within a document. Typically, cookies are sent from the server to the client, which can then store it, and send it back to the server on subsequent requests. This can be used for things like managing account sessions and tracking user information.

Additionally, cookies can be used for storing data purely on the client-side. Because of this, they have also been used for storing general data, such as user preferences.

Basic CRUD with Cookies #

We can create, read, update, and delete cookies using the following syntax -

// Create
document.cookie = "user_name=Ire Aderinokun";
document.cookie = "user_age=25;max-age=31536000;secure";

// Read (All)
console.log( document.cookie );

// Update
document.cookie = "user_age=24;max-age=31536000;secure";

// Delete
document.cookie = "user_name=Ire Aderinokun;expires=Thu, 01 Jan 1970 00:00:01 GMT";

Advantages of Cookies #

They can be used for communication with the server
We can set when we want the cookie to expire automatically, instead of having to manually delete

Disadvantages of Cookies #

They add to the page load of the document
They can only store a small amount of data
They can only store Strings
Potential security issues
It is not the recommended method for client-side storage anymore since the introduction of the Web Storage API (Local and Session Storage)

Support #

Cookies have basic support in all major browsers.

Local Storage #

Local Storage is one type of the Web Storage API, which is an API for storing key-value pairs of data within the browser. It arose as a solution to the issues with Cookies, by offering a more intuitive and secure API for storing simple data within the browser.

Although technically we can only store strings in Local Storage, this can be worked around by storing stringified JSON. This allows us to store a bit more complex data in Local Storage than we can with Cookies.

Basic CRUD with Local Storage #

We can create, read, update, and delete data to Local Storage using the following syntax -

// Create
const user = { name: 'Ire Aderinokun', age: 25 }
localStorage.setItem('user', JSON.stringify(user));

// Read (Single)
console.log( JSON.parse(localStorage.getItem('user')) )

// Update
const updatedUser = { name: 'Ire Aderinokun', age: 24 }
localStorage.setItem('user', JSON.stringify(updatedUser));

// Delete
localStorage.removeItem('user');

Advantages of Local Storage #

Offers a more simple intuitive interface to storing data (than Cookies)
More secure for client-side storage (than Cookies)
Allows for the storage of more data (than Cookies)

Disadvantages of Local Storage #

Only allows the storage of Strings

Support #

Session Storage #

Session Storage is the second type of the Web Storage API. It is exactly the same as Local Storage, except that the data is only stored for the browser tab session. Once the user closes that browser tab, the data is cleared.

Basic CRUD with Session Storage #

We can create, read, update, and delete data to Session Storage using the following syntax -

// Create
const user = { name: 'Ire Aderinokun', age: 25 }
sessionStorage.setItem('user', JSON.stringify(user));

// Read (Single)
console.log( JSON.parse(sessionStorage.getItem('user')) )

// Update
const updatedUser = { name: 'Ire Aderinokun', age: 24 }
sessionStorage.setItem('user', JSON.stringify(updatedUser));

// Delete
sessionStorage.removeItem('user');

Advantages, Disadvantages, and Support for Session Storage #

Same as for Local Storage.

IndexedDB #

IndexedDB is a much more complex and well-rounded solution for storing data in the browser. It is a "low-level API for client-side storage of significant amounts of structured data" (Mozilla). It is a JavaScript-based, object-oriented, database that allows us to easily store and retrieve data that has been indexed with a key.

In my article on Building a Progressive Web Application, I went over in more detail how you can use IndexedDB to create an offline-first application.

Basic CRUD with IndexedDB #

Note: In all my examples, I uses Jake Archibald’s [IndexedDB Promised library](https://github.com/jakearchibald/idb) which offers a Promise-ified version of the IndexedDB methods.

Using IndexedDB is more complicated than the other browser storage methods. Before we can create/read/update/delete any data, we need to first open up the database, creating any stores (which are like tables in a database) we need.

function OpenIDB() {
	return idb.open('SampleDB', 1, function(upgradeDb) {
        const users = upgradeDb.createObjectStore('users', {
            keyPath: 'name'
        });
    });
}

To create (or update) data within a store, we need to go through the following steps -

// 1. Open up the database
OpenIDB().then((db) => {
    const dbStore = 'users';

    // 2. Open a new read/write transaction with the store within the database
    const transaction = db.transaction(dbStore, 'readwrite');
    const store = transaction.objectStore(dbStore);

    // 3. Add the data to the store
    store.put({
    	name: 'Ire Aderinokun',
    	age: 25
    });

    // 4. Complete the transaction
    return transaction.complete;
});

To retrieve data, we need to go through the following -

// 1. Open up the database
OpenIDB().then((db) => {
    const dbStore = 'users';

    // 2. Open a new read-only transaction with the store within the database
    const transaction = db.transaction(dbStore);
    const store = transaction.objectStore(dbStore);

    // 3. Return the data
    return store.get('Ire Aderinokun');
}).then((item) => {
	console.log(item);
})

Finally, to delete data, we need to do the following -

// 1. Open up the database
OpenIDB().then((db) => {
    const dbStore = 'users';

    // 2. Open a new read/write transaction with the store within the database
    const transaction = db.transaction(dbStore, 'readwrite');
    const store = transaction.objectStore(dbStore);

    // 3. Delete the data corresponding to the passed key
    store.delete('Ire Aderinokun');

    // 4. Complete the transaction
    return transaction.complete;
})

If you're interested in learning more about how to use IndexedDB, you can read my article showing how I used it in a Progressive Web Application.

Advantages of IndexedDB #

Can handle more complex, structured, data
Can have multiple "databases" and "tables" within each "database"
More allowance for storage
More control over how we interact with it

Disadvantages of IndexedDB #

More complex to use than the Web Storage API

Support #

WebSQL #

WebSQL is an API for a relational database on the client, similar to SQLite. Since 2010, the W3C Web Applications Working Group has ceased working on the specification. It is no longer a part of HTML specification, and should not be used.

A Comparison #

Feature	Cookies	Local Storage	Session Storage	IndexedDB
Storage Limit	~4KB	~5MB	~5MB	Up to half of hard drive
Persistent Data?	Yes	Yes	No	Yes
Data Value Type	String	String	String	Any structured data
Indexable?	No	No	No	Yes

Document Outlines in HTML 5.1

2016-12-06T00:00:00Z

In one of my previous articles, Using Heading Elements to Create a Document Outline, I explained the importance of having valid outlines in an HTML page.

The outline for an HTML document shows the structure of the content on the page. This is useful for user agents, who can use the outline to create, for example, a table of contents for the document. This can then be used by screen readers to help people better navigate the page.

Last week, HTML 5.1 was officially released. There were a number of interesting changes made, two of which relate to how we create a valid document outline.

Removed: The use of nested <section> elements each with an <h1> to create an outline
Changed: <header> and <footer> elements can be nested, if each level is within a sectioning element

Creating Document Outlines with Nested `<section>` Elements #

In HTML 5.0, a new way of creating a document outline was introduced. It involved using only the <h1> heading rank, and instead nesting <section> elements to define nested sections within the document.

Take, for example, this markup -

<section>
<h1>Heading Level One</h1>

    <section>
        <h1>Heading Level Two</h1>
    </section>

    <section>
        <h1>Heading Level Two</h1>

        <section>
            <h1>Heading Level Three</h1>
        </section>
    </section>

<section>

Deprecated method

Using that markup, it should have created the following document outline -

1. Heading Level One
    1. Heading Level Two
    2. Heading Level Two
        1. Heading Level Three

In my previous article, I mentioned that this method was not currently recognised by user agents and should not be used yet. In HTML 5.1, this method has been removed from the specification completely.

Now, the advised method for creating a document outline is to still make use of nested <section> elements, but in combination with the appropriate heading rank for each section. For example, to create the document outline above, we should use the following markup -

<section>
<h1>Heading Level One</h1>

    <section>
        <h2>Heading Level Two</h2>
    </section>

    <section>
        <h2>Heading Level Two</h2>

        <section>
            <h3>Heading Level Three</h3>
        </section>
    </section>

<section>

Nesting `<header>` and `<footer>` elements #

In HTML 5.0, <header> elements couldn’t be nested within <header> elements, and <footer> elements couldn’t be nested within <footer> elements.

In HTML 5.1, this has been changed. Now, we can have nested <header> and <footer> elements, but only if they are within a new sectioning context, which is created by nesting them within a sectioning element. These are one of the following -

<article>
<section>
<aside>
<nav>

This way, the <header> or <footer> element is always related to a unique sectioning element, such as <section>, and not just the <header> or <footer> element itself. For example, an <article> element can have a <header>, which has various <sections>, detailing different information about the article.

<article>
  <header>
    <h1>Creating a Document Outline in HTML 5.1</h1>
    <section>
      <header>
        <h2>The Author</h2>
      </header>
      <p>Ire Aderinokun</p>
      <address>Lorem ipsum dolor sit amet</address>
    </section>
    <section>
      <header>
        <h2>The Publication</h2>
      </header>
      <p>bitsofcode</p>
      <address>Lorem ipsum dolor sit amet</address>
    </section>
  </header>
  <h2>Introduction</h2>
  <p>Lorem ipsum dolor sit amet</p>
</article>

This markup will produce the following outline -

1. Creating a Document Outline in HTML 5.1
    1. The Author
    2. The Publication
    3. Introduction

Making "Blue Beanie Me"

2016-11-29T00:00:00Z

Blue Beanie Day (November 30th) is a day where web developers show support of web standards and accessibility by posting a selfie of themselves wearing a blue beanie. It was first instigated by Jeffrey Zeldman in 2006, who wrote a book about web standards and famously wears a blue beanie. Tomorrow is the 10th anniversary and I don’t own a blue beanie myself, so I decided to create a web app that will allow you to add a blue beanie to any selfie you upload.

bluebeanieme.bitsofco.de

There are many parts to how I made this application. Here, I want to focus on the most important part - how I added the blue beanie to the user's photo and created a picture they could download themselves. I did this using the Canvas API.

Canvas API 101 #

The Canvas API is a Web API for interacting with the HTML <canvas> element, enabling us to draw graphics onto it using JavaScript. In order to start drawing, we first need a <canvas> element in our document -

<canvas id="canvas" height="400" width="400"></canvas>

Next, we need to create a rendering context, for example "2d", from the element.

const canvas = document.getElementById('canvas');
const ctx = canvas.getContext('2d');

Now we can start drawing on the canvas. There are many shapes and media elements we can draw onto a canvas, but for Blue Beanie Me I only made use of two - rectangles and images.

Drawing Rectangles #

To draw a rectangle with a solid colour background, we use the fillRect() method. This method accepts four arguments, which are all required -

The x-coordinate of the upper-left corner of the rectangle
The y-coordinate of the upper-left corner of the rectangle
The width of the rectangle, in pixels
The height of the rectangle, in pixels

For example, to draw a 50x50px rectangle in the top left corner of the canvas, we would write the following -

ctx.fillRect(0, 0, 50, 50);

Drawing Images #

To draw an image onto a canvas, we use the drawImage() method. This method takes up to nine arguments -

The image, canvas, or video element we want to draw on the canvas (required)
The x coordinate where to start clipping
The y coordinate where to start clipping
The width of the clipped image
The height of the clipped image
The x coordinate where to place the image on the canvas (required)
The y coordinate where to place the image on the canvas (required)
The width of the image to use (stretch or reduce the image)
The height of the image to use (stretch or reduce the image)

For example, to draw an image element, resized to 50x50px, to the top left corner of the canvas, we would write the following -

const imageElement = document.getElementById('image');
ctx.drawImage(imageElement, 0, 0, 50, 50);

Making “Blue Beanie Me” #

If you would like to see the full source code for the application, it is available on my github. Here, I will go over how I added the beanie to the user's selfie, allowed them to reposition it, then export the image.

Calculating the Size of the Beanie #

The first thing I had to do was to calculate the size that the beanie should be. I achieved this by asking the user to select two points on the image - their upper left forehead and upper right forehead (See a demo). Based on this, I was able to draw a beanie that will fit between those two points.

function drawBeanie() {

	// Draw the user uploaded image
	drawImage();

	const beanieWidth = coordinates.right.x - coordinates.left.x + 40;
	ctx.drawImage(beanie, coordinates.left.x, coordinates.left.y - beanieWidth, beanieWidth, beanieWidth);

	// Note - The beanie image is a square, which is why height is the same as width
}

function onCanvasClick(e) {

	// Determine if the user has added coords
	numberOfTimesClicked++;
	if (numberOfTimesClicked === 3) numberOfTimesClicked = 1;

	const coords = {
		x: e.offsetX,
		y: e.offsetY
	}

	// Set rectangle so user sees feedback
	addRect(coords);

	switch (numberOfTimesClicked) {
		case 1:
			setLeftCoord(coords)
			break;
		case 2:
			setRightCoord(coords)
			drawBeanie();
			break;
		default:
			break;
	}
}

Repositioning the Beanie #

To allow the user to reposition the beanie, I created a set of buttons with custom data attributes to determine direction.

<button data-direction="up" aria-label="Move Beanie Up">&#8593;</button>
<button data-direction="left" aria-label="Move Beanie Left">&#8592;</button>
<button data-direction="down" aria-label="Move Beanie Down">&#8595;</button>
<button data-direction="right" aria-label="Move Beanie Right">&#8594;</button>

When a user clicks on one of these buttons, I shift the beanie's coordinates accordingly, and redraw the entire canvas.

function moveBeanie(e) {

	const direction = e.target.dataset.direction;

	switch(direction) {
		case 'left':
			coordinates.left.x --
			coordinates.right.x --
			break;
		case 'right':
			coordinates.left.x ++
			coordinates.right.x ++
			break;
		case 'down':
			coordinates.left.y ++
			coordinates.right.y ++
			break;
		case 'up':
			coordinates.left.y --
			coordinates.right.y --
			break;
		default:
			break;
	}

	// Redraw beanie
	drawBeanie();
}

Exporting the Image #

Finally, to allow the user to export the image, we use the canvas.toDataURL() method. This method returns a Data URI representing the image in any format and resolution we specify. By default, the returned image is a PNG at a resolution of 96 dpi.

function exportImage() {
	const canvas = document.getElementById('canvas');
	const exportedImage = canvas.toDataURL();

    // Open the image in a new window
	window.open(exportedImage);
}

That's it! You can view the full source code for the app on my github. Otherwise, make sure to use the application and don't forget why Blue Beanie Day is important. If you're interested in reading about accessibility, you can check out all my articles related to accessibility.

Highlights from Chrome Dev Summit 2016

2016-11-22T00:00:00Z

A couple of weeks ago I was lucky enough to be able to attend the Chrome Dev Summit in San Francisco. It was a really great experience to be able to see, in person, a lot of the people working on the APIs I use everyday, as well as to see how other developers are creating complex modern web applications.

I would urge you to watch all the videos yourself (Chrome Dev Summit 2016 Playlist), but here are the top 5 things I found the most interesting/exciting.

Web Payments #

Zach Koch (Product Manager, Chrome) spoke on the first day about Web Payments, and how to use the new Payment Request API.

The Payment Request API is a new web API, still in working draft, that is intended to eliminate checkout forms. It aims to provide a standardised and consistent method of making payments on the web for users, by moving the handling of retrieving payment information to the browser, instead of individual checkout forms on each website.

Making a new payment request is as simple as writing the following -

new PaymentRequest(
  methodData, // required payment method data
  details,    // required information about transaction
  options     // optional parameter for things like shipping, etc.
);

This will trigger the browser UI for collecting payment information. If the user has used it before, they will have already filled information about their credit card and shipping address, so checking out can be as simple as one click. Then, the browser passes the response back to the site in a structured format. Here’s a demo of how it could work -

I find this new API really exciting because it's great for everyone. Users get a more seamless checkout process, and us as developers don't have to deal with creating tedious and complex checkout forms.

The Importance of Testing on Real Devices #

Alex Russell (Software Engineer, Chrome) gave a presentation on Progressive Performance, in which he spoke about the best practices for building truly performant websites today.

His talk was a real eye-opener about how mobile devices perform compared to desktops. An example he gave was the 2015 Google I/O site, which was a Progressive Web App built with Polymer. Using the mobile emulator on Chrome things were fast, with total JS time at less than 600ms and interactive content at about 4s. However, the same site on the same WiFi network loading on a Nexus 5 was significantly slower, with total JS time at about 4s and interactive content at about 7s!

“Your Laptop is a Filthy Liar”

The reason for this is that, no matter how much emulators may try to mimic real devices, they aren't running the same actual hardware, so they will never be actually accurate.

Alex's solution to this is to test your sites on real devices, particularly mid-range circa 2014 devices. This will give you a more realistic representation of what your website is actually performing like for a good portion of your users.

Using Progressive Web Apps with Accelerated Mobile Pages #

Paul Bakaus (Developer Advocate, Google) gave a talk titled, From AMP to PWA - The Best of Both Worlds. In this talk, he spoke about how to use Accelerated Mobile Pages with Progressive Web Apps to create the ultimate performance experience.

In the development environment today where there are so many different frameworks and platforms to choose from, it often seems like you have to make a choice and only use one. But different frameworks have their advantages and disadvantages. AMP, for example, is great for discovery and has a lightening-fast loading time, even on first visit. However, it only allows serving of static content, no user scripts allowed. PWA, on the other hand, have very advanced features and dynamic content, but may not be as easily embedded or have as great discovery in search.

AMP + PWA = PWAMP

In his talk, Paul showed how you can leverage both platforms by using AMP as a data format, a technique he called "AMP down". On first visit, users are served the super fast AMP page, and the Service Worker is installed in the background (Using <amp-install-serviceworker>). On subsequent pages, they are diverted to the PWA, which now loads as fast as if it would on a second visit!

Progressive Web Apps != Single Page Apps #

As is to be expected, Jake Archibald (Developer Advocate, Chrome) spoke about the Service Worker API in his talk, Future App Model: Advanced Service Worker.

In his talk, he challenged the notion that Progressive Web Apps need to be Single Page Apps. Although Single Page Apps been popular because of client-side frameworks and the advent of the App Shell Model, he demonstrated that we can get even faster page loads with server-side renderings by taking advantage of Streams.

Streaming is a behaviour that happens natively on the web. As you may have noticed with regular server-rendered sites, the page content loads progressively. This is because the browser doesn't wait for everything to be received before it starts acting on it. This is behaviour is that is soon coming to the Fetch API. With Streams, we will be able to read the response from a fetch request as it is coming in, and handle how we display the information progressively.

In Jake Archibald's talk, Future App Model: Advanced Service Worker, he spoke about a lot of speculative features that may be added to the Service Worker API.

My favourite (and the most speculative) was an API for handling navigation transitions. Currently, in order for us to have fancy transitions between pages the way native mobile applications do, we have to use the Single Page Application model. The goal of this API is to give us control over transitions between pages even when the page is server rendered. For example, we should be able to achieve this in the Progressive Web App -

Taken from Slides, "Future App Model"

The way the API would work will be by introducing a new event, navigate, that we can listen for in the window. For example, a simple cross-fade transition could be written like this -

// Listen for a new "navigate" event
window.addEventListener('navigate', event => {
  // Keep the current document alive until this Promise is resolved
  event.transitionUntil(

    // Get the new window
    event.newWindow.then(newWin => {
      if (!newWin) return;

      // assuming newWin.document.interactive means DOM ready
      return newWin.document.interactive.then(() => {
        return newWin.document.documentElement.animate([
          {opacity: 0}, {opacity: 1}
        ], 1000).finished;
      });
    })
  );
});

// Example from https://github.com/jakearchibald/navigation-transitions

There were lots more interesting content at the summit, for example the Lyft team sharing how they created a 40KB G-Zipped Progressive Web App 😱!If you're interested, you can watch the recordings here.

for..in versus for..of Loops

2016-11-15T00:00:00Z

The most basic type of iteration method in JavaScript is the for loop. It takes three expressions; a variable declaration, an expression to be evaluated before each iteration, and an expression to be evaluated at the end of each iteration. For example, this for loop will console.log each item in an array.

const array = ['a', 'b', 'c', 'd'];

for (let i = 0; i < array.length; i++) {
  console.log(array[i]);
}

// Result: a, b, c, d

In addition to this for loop, there are two other types of for iteration methods we can use: for..in and for..of.

The `for..in` Statement #

for..in is a method for iterating over "enumerable" properties of an object. It therefore applies to all objects (not only Object()s) that have these properties.

An enumerable property is defined as a property of an object that has an Enumerable value of true. Essentially, a property is "enumerable", if it is enumerable. We can check if a property is enumerable by calling property.enumerable, which will return true or false.

We use the for..in loop with the following syntax -

for (variable in enumerable) {
	// do stuff
}

For example, to loop through and console.log all the values in this Object, we can do the following -

const obj = {
	a: 1,
	b: 2,
	c: 3,
	d: 4
}

for (const key in obj) {
	console.log( obj[key] )
}

// Result: 1, 2, 3, 4

The for ... in loop will iterate over inherited properties as well, as long as they are enumerable properties. The for ... in iteration happens in an arbitrary order. Therefore, it should not be used if things need to happen in their defined sequence.

`for..in` and Objects #

The for..in method provides us the most straightforward way to loop over Object keys and values, since Objects do not have access to the forEach method that Arrays do.

`for..in` and Arrays #

The "key" for values in an Array are the numerical indexes. Therefore, these indexes are essentially just enumerable properties, like Object keys, except they are integers instead of strings.

This means that we can loop over all the values in an Array by retrieving their index using the for..in Array.

const array = ['a', 'b', 'c', 'd'];

for (const index in array) {
	console.log(array[index])
}

// Result: a, b, c, d

However, it is generally advised that for..in not be used with Arrays, particularly because it cannot be guaranteed that the iteration happens in sequence, which is usually important for Arrays.

`for..in` and Strings #

Each character in a string has an index. Therefore, similar to Arrays, the indexes are enumerable properties that just happen to be integers.

const string = 'Ire Aderinokun';

for (const index in string) {
    console.log(string[index])
}

// Result: I, r, e, , A, d, e, r, i, n, o, k, u, n

The `for..of` Statement #

for..of is a method, introduced in ES2015, for iterating over "iterable collections". These are objects that have a [Symbol.iterator] property.

The [Symbol.iterator] property allows us to manually iterate over the collection by calling the [Symbol.iterator]().next() method to retrieve the next item in the collection.

const array = ['a','b','c', 'd'];
const iterator = array[Symbol.iterator]();
console.log( iterator.next().value )
console.log( iterator.next().value )
console.log( iterator.next().value )
console.log( iterator.next().value )

// Result: a, b, c, d

The for..of syntax is essentially a wrapper around the [Symbol.iterator] to create loops. It uses the following syntax -

for (variable of iterable) {
	// do stuff
}

`for..of` and Objects #

The for..of loop doesn't work with Objects because they are not "iterable", and therefore don't have a [Symbol.iterator] property.

`for..of` and Arrays/Strings #

The for..of loop works well with Arrays and Strings, as they are iterable. This method is a more reliable way of looping through an Array in sequence.

const array = ['a', 'b', 'c', 'd'];
for (const item of array) {
	console.log(item)
}
// Result: a, b, c, d

const string = 'Ire Aderinokun';
for (const character of string) {
	console.log(character)
}
// Result: I, r, e, , A, d, e, r, i, n, o, k, u, n

`for..of` and NodeLists #

Finally, another really useful case for for..of is in iterating of NodeLists. When we query the document for a group of elements, what we get returned is a NodeList, not an Array. This means that we can't iterate over the list using Array methods like forEach.

To solve this, we can either convert it to an Array using Array.from(), or use the for..of loop, which is applicable to more than just Arrays.

const elements = document.querySelectorAll('.foo');

for (const element of elements) {
    element.addEventListener('click', doSomething);
}

A Comparison #

	`for..in`	`for..of`
Applies to	Enumerable Properties	Iterable Collections
Use with Objects?	Yes	No
Use with Arrays?	Yes, but not advised	Yes
Use with Strings?	Yes, but not advised	Yes

Challenge - Recreating the iTunes Library

2016-11-08T00:00:00Z

It's time for another UI challenge! In the first challenge, we recreated some interactions from the MacOS application, Clear. In this one, we are recreating the look of the old iTunes library gallery.

The Challenge #

Start the Challenge | Live Demo with My Solution

The key interactions we are trying to recreate -

The gallery of “albums”/“cards” should stacked horizontally.
When inactive, each card should be arranged “stacked” as shown above
When active, the card should be displayed in full view.
When the user hovers over a card, it should be slightly enlarged. When they click on the card, it should become active.
The user should be able to move through the cards by pressing the TAB or Arrow keys.

Extra credit 🤓 -

Mobile functionality. Users should be able to swipe right and left to move between cards
The active card should always be entered horizontally within the container
The library should be navigable without JavaScript enabled

My Solution #

Styling the Cards #

The first step was to style the cards so they looked like stacked items you could swipe through. This effect was achieved mainly though using a couple of transforms. First, I used the skewY() 2D transform, which skews the element along the Y-axis, giving it a distorted look. For example, this is an animation moving the value of the skew from 0 to 20deg -

I also used the rotateY() 3D transform, which rotates the element around it’s Y-axis, making it seem like it is folded towards the user. For example, this is an animation moving the value of the rotation from 0 to 50deg -

I also added a few other styles, notably -

Negative margins to have the appearance of the cards being stacked on top of each other
Scale transform to shrink the card when not active
Blur filter to create a blurred out effect

.card {

  z-index: 1;
  flex-shrink: 1;

  outline: none;
  height: 150px;
  width: 150px;
  margin-left: -40px;
  margin-right: -40px;

  transform: rotateY(60deg) skewY(-5deg) scale(0.8);
  box-shadow: 1px 1px 5px 1px rgba(0,0,0,0.3);
  filter: blur(2px);

  transition: transform 1s,
              margin-left 1s,
              margin-right 1s,
              box-shadow 1s,
              filter 1s,
              flex-shrink 1s;
}

Handling Focus, Active & Hover States #

In the markup, each "card" is simply a div, but it could be any element, interactive or non-interactive. However, I wanted to make sure the element would be focusable so the "active" card could be accessed using the keyboard tab or arrow keys. To ensure this, I used the tabindex attribute set to 0, to add each card to the natural tabbing order of the page.

<div class="card" tabindex="0">
	<!-- card content here -->
</div>

When the card is in focus or active, I apply the styles to make it pop out.

.card:active,
.card:focus,
.card.js-active {
    transform: none;
    margin-left: 40px;
    margin-right: 40px;
    box-shadow: 2px 2px 10px 1px rgba(0,0,0,0.3);
    filter: none;
    flex-shrink: 0;
    z-index: 2;
}

When a user hovers over a card with their pointing device, I wanted to make it obvious that the card can be clicked to fully expand.

.card:hover:not(:active):not(:focus):not(.js-active) {
    margin-left: -20px;
    margin-right: -20px;
    box-shadow: 2px 2px 10px 1px rgba(0,0,0,0.3);
    filter: none;
    cursor: pointer;
}

To avoid conflict with the other styles, I made sure to only apply these mouse hover styles if the card is not currently active or in focus.

Handling Swipes and Keyboard Events #

On mobile, I needed to make sure that users could use swiping gestures to move between individual cards. To do this, I used custom event listeners written by cocco on Stack Overflow -

// Source - https://stackoverflow.com/a/17567696
window.onload = function() {
(function(d){
 var
 ce=function(e,n){var a=document.createEvent("CustomEvent");a.initCustomEvent(n,true,true,e.target);e.target.dispatchEvent(a);a=null;return false},
 nm=true,sp={x:0,y:0},ep={x:0,y:0},
 touch={
  touchstart:function(e){sp={x:e.touches[0].pageX,y:e.touches[0].pageY}},
  touchmove:function(e){nm=false;ep={x:e.touches[0].pageX,y:e.touches[0].pageY}},
  touchend:function(e){if(nm){ce(e,'fc')}else{var x=ep.x-sp.x,xr=Math.abs(x),y=ep.y-sp.y,yr=Math.abs(y);if(Math.max(xr,yr)>20){ce(e,(xr>yr?(x<0?'swipeLeft':'swipeRight'):(y<0?'swipeUp':'swipeDown')))}};nm=true},
  touchcancel:function(e){nm=false}
 };
 for(var a in touch){d.addEventListener(a,touch[a],false);}
})(document);
};

With these event listeners, I could detect if a user was swiping right (swipeRight) or left (swipeLeft). Depending on which direction, I could then set the active card to be the previous or next card in the group.

function swipeCard(direction) {

	let focusedElement = document.querySelector('.card.js-active') ? activeCard : document.activeElement;
	if ( !focusedElement ) return;
	if ( !focusedElement.classList.contains('card') ) return;

	let focusedElementIndex = 0;
	for (let i = 0; i < cards.length; i++) {
		if (cards[i] === focusedElement) focusedElementIndex = i
	}

	switch(direction) {
		case 'right':
			setActiveCard( cards[focusedElementIndex - 1] );
			break;
		case 'left':
			setActiveCard( cards[focusedElementIndex + 1] );
			break;
		default:
			break;
	}

}

document.body.addEventListener('swipeRight', function() {
	swipeCard('right');
});

document.body.addEventListener('swipeLeft', function() {
	swipeCard('left');
});

Centering the Active Element #

Finally, I wanted to ensure that the active card will always be horizontally in the middle of the container element.

In Flexbox, there is a property to ensure that a flex item will always be vertically in the middle of the container element, which is align-self. In the future, there will be a similar property for horizontal alignment, justify-self ( See the prospective specification ). However, this is not yet available, so to do this, I had to use JavaScript.

In the markup, there are two container elements - .card-outer-container and .card-inner-container.

<div class="card-container-outer">
	<div class="card-container-inner">

		<div tabindex="0" class="card"> ... </div>
		<div tabindex="0" class="card"> ... </div>
		<div tabindex="0" class="card"> ... </div>
		<div tabindex="0" class="card"> ... </div>

	</div>
</div>

The outer container is what defines the height and width of the group. The inner contain has a larger width, and is what I shift left and right to make sure the active card is aligned to the centre of the outer container.

To get to the amount of pixels from the left I need to shift the inner container, I subtract the following values -

Half the width of the outer container
Half width width of the card element
The offset of the currently active card from the left

function alignActiveCard(card) {

	const halfOuterContainerWidth = outerContainer.clientWidth / 2;
	const halfCardContainerWidth = card.clientWidth / 2;
	const cardOffset = card.offsetLeft;

	const left = halfOuterContainerWidth - cardOffset - halfCardContainerWidth;
	innerContainer.style.transform = `translateX(${ left }px)`;
}

That's it! You can view a full demo of this on GitHub, and use it in a project yourself if you like.

Tools for Developing Accessible Websites

2016-11-01T00:00:00Z

Building websites that are accessible can be challenging for developers like myself that have never had to use any assistive technologies. Unlike visual issues such as layout which can be easily seen, accessibility issues can very easily go unnoticed if we don't have the correct tools to test for them.

Accessibility doesn't have to be perfect, it just needs to be a little bit better than yesterday.

Leonie Watson at FronteersConf

There are a few tools I use regularly for this purpose that greatly help, so I thought I would share them. Because I do the vast majority of my development in Chrome, this list is biased to tools for Chrome in particular.

Accessibility Developer Tools #

Accessibility Developer Tools is an extension for Google Chrome created by the Google Accessibility team. The extension adds an extra panel in the developer tools drawer called "Audits". In this panel, we can run Audits on the page related to Network Utilization, Web Page Performance, and of course Accessibility.

The Accessibility Audit will test the web page against a pre-defined list of accessibility checks. It will list, in order of importance, any critical issues that need to be fixed, as well as the tests that were passed by the page.

In addition to the Accessibility Audit, we can inspect any particular element’s accessibility properties in the element inspector. There is a new panel added to the element inspector called "Accessibility Properties", which will list any properties relevant to the particular element.

Accessibility Inspector #

As part of an internal Chrome experiment, an Accessibility Inspector has been available in the Chrome Developer Tools (hidden behind a flag).

The Accessibility Inspector is an extra panel in the element inspector, called "Accessibility". This allows us to inspect particular elements on the page and receive information on it's accessibility properties. Unlike the Accessibility Developer Tools extension, this tool is able to offer us much more in-depth information about an element's accessibility properties due to greater access to the Accessibility API.

Tenon #

Tenon is an extremely useful tool that can identify WCAG 2.0 and Section 508 issues in any environment, from local development to production. It is actually an API you pay to have access to, which can be integrated in your development workflow, giving in-depth accessibility analyses every step of the development.

Additionally, there is also a free online tool that will produce an accessibility report on any web page or even snippet of code.

Chrome Vox #

Ensuring a website works well on screen readers can be a bit of a guessing game for developers that don't already use screen readers. Chrome Vox is a simple and easy-to-use screen reader for Google Chrome that can be installed as an extension. Once enabled, it will allow you to navigate any web page through it.

Here's a demo of me using it to navigate the homepage of this blog -

Even though not all screen readers work in the same way, Chrome Vox is a simple one to get started and experience what it is like to use a screen reader.

High Contrast (Extension) #

High Contrast is an extension for Google Chrome that allows you to change the colour schemes of any page to a high contrast one. Viewing a website through one of these filters can be helpful when making colour choices.

Your Keyboard #

Finally, one of the simplest and most useful ways to test a website is to try navigating it with only a keyboard, no pointing device.

Push Notifications on the Web (Building a PWA, Part 3)

2016-10-25T00:00:00Z

Last week's article was Part 2 (of 3) in my series on how I built a Progressive Web Application for this blog.

Get the Application | View Source

In this final part, I will show how I implemented web push notifications. For users that subscribe, a notification is sent to their device once a week when a new article is released on the blog.

#ProgressiveWebApp works, rocks! Here is a notification I got from the bitsofcode #PWA by @ireaderinokun #devfest16

— Odili Charles Opute (@chaluwa) October 18, 2016

Web Applications can use the Push API, in combination with the Service Worker, to receive push notifications messages pushed to them from a server, whether or not the web app is in the foreground, or even currently loaded, on a user agent. It works in the following way -

The user subscribes to receive push notifications via the Service Worker's Push Manager
We receive and endpoint with the user's subscription ID, which we save securely in a database
We pass the user's subscription ID when we post messages from the server to our messaging service (in this case, Firebase Cloud Messaging)

So there are two parts to this. First, the client side, where we let the user subscribe to push notifications and display the notifications sent to them. Second, the server side, where we store the subscription IDs securely, and post the messages to the messaging service. This second part was done with the help of Timi Ajiboye, who created a simple Rails application for this purpose. If you're interested in seeing how he did that, you can read his article here. In this article I will cover the first part, the client side.

Setting up Firebase Cloud Messaging #

The first thing we need to do is setup a new project with Firebase and get our Firebase Cloud Messaging Sender ID and Server Key. These can be found under Settings > Cloud Messaging in the Firebase project.

The Sender ID goes in our application's manifest.json file, and is used to identify our client.

{
  "gcm_sender_id": "FIREBASE_CLOUD_MESSAGING_SENDER_ID_HERE",
  // more manifest.json stuff...
}

We use the Server Key when posting to Firebase Cloud Messaging via our server (see the tutorial for the rails application).

Subscribing to Push Notifications #

To use the Push API, we need to have a registered and active Service Worker, as the Push Manager service is only available within the Service Worker registration.

navigator.serviceWorker.register('./service-worker.js')
    .then(function(reg) {
        console.log(reg)
    });

To subscribe a user to push notifications, all we need to do is call the subscribe() method of the push manager. This will generate a popup in the browser, asking the user if they will allow push notifications from the domain. We pass the subscribe() method an object with userVisibleOnly: true to indicate that the push subscription will only be used for messages whose effect is made visible to the user.

function subscribe(serviceWorkerReg) {
	serviceWorkerReg.pushManager.subscribe({userVisibleOnly: true})
}

navigator.serviceWorker.register('./service-worker.js')
    .then(function(reg) { subscribe(reg) });

Although I've set it to automatically ask the user to subscribe once the Service Worker is registered in this example, this isn't the most user friendly method. Only prompt the user to subscribe to push notifications when it makes sense to do so.

Once the user has subscribed, we need to pass their subscription ID to our server so that it can be saved securely in the database. We do this using the API endpoint provided by the rails application.

function addSubscriptionIDToDB(subscription) {
    const uid = subscription.endpoint.split('gcm/send/')[1];
    const options = {
        method: 'POST',
        headers: new Headers({'Content-Type': 'application/json'}),
        body: JSON.stringify({ uid: uid })
    };
    fetch(apiUrl, options);
}

function subscribe(serviceWorkerReg) {
    serviceWorkerReg.pushManager.subscribe({userVisibleOnly: true})
        .then((subscription) => addSubscriptionIDToDB(subscription))
}

Now the database has all the information it needs to send the notifications.

Unsubscribing from Push Notifications #

We also need to give the user the ability to unsubscribe from receiving push notifications. Like when we subscribed, we need to do two things - unsubscribe from the Push Manager and delete the subscription ID from the database.

To unsubscribe from the push manager, we need to get the user's current subscription. We can do this using the getSubscription() method. Once we have the user's current subscription, we can unsubscribe them with the unsubscribe() method.

function unsubscribe(serviceWorkerReg) {
    serviceWorkerReg.pushManager.getSubscription()
        .then((subscription) => { subscription.unsubscribe() });
}

Next, we need to remove the user's subscription ID from our database. Again, we use the API endpoint provided by the rails application.

function deleteSubscriptionIDFromDB(subscription) {
    const uid = subscription.endpoint.split('gcm/send/')[1];
    const options = {
        method: 'DELETE',
        headers: new Headers({'Content-Type': 'application/json'})
    };
    fetch(apiUrl+uid, options);
}

function unsubscribe(serviceWorkerReg) {
    serviceWorkerReg.pushManager.getSubscription()
        .then((subscription) => {
            subscription.unsubscribe().then(() => deleteSubscriptionIDFromDB(subscription))
        })
}

Sending Notifications on a Weekly Schedule #

Finally, we want to trigger the sending of notifications. The rails application has an endpoint which we can POST to, to send a notification.

const options = {
    method: 'POST',
    headers: new Headers({'Content-Type': 'application/json'})
};
fetch(apiUrl, options);

I could run this script manually everytime I wanted to send a notification to all users, but that won't be very efficient. So, I decided to setup an IFTTT recipe to make this POST request every week at 10am BST (to coincide with the newsletter going out).

Support for Push API #

Can I Use push-api? Data on support for the push-api feature across the major browsers from caniuse.com.

"Instant Loading" with IndexedDB (Building a PWA, Part 2)

2016-10-18T00:00:00Z

Last week's article was Part 1 (of 3) in my series on how I built a Progressive Web Application for this blog.

Get the Application | View Source

As I mentioned, there are two parts to creating an "offline-first" application -

Cache the app shell so pages and assets are accessible offline
Load locally-saved data first, then fetch updated data later if the network permits

Last week, I showed how I achieved the first using Service Worker to cache the app shell and serve it to the user even when they are offline. In this article, I will show how I used IndexedDB to save the fetched data for offline use. In the final part of this series next week, I will demonstrate how I implemented push notifications.

What is IndexedDB? #

IndexedDB is a "low-level API for client-side storage of significant amounts of structured data" (Mozilla). It is a JavaScript-based, object-oriented, database that allows us to easily store and retrieve data that has been indexed with a key. IndexedDB can take some getting used to as it very low-level and works quite differently to other databases.

For the bitsofcode web app, I used IndexedDB to store the articles fetched from the blog RSS feed. This way, articles could be loaded instantly from the database first, before checking over the network for the more up-to-date data.

Creating a Database and Store #

For my own sanity (and because I love Promises), I use Jake Archibald’s IndexedDB Promised library which offers a Promise-ified version of the IndexedDB methods. All my examples will be using this library.

To start using IndexedDB, we need to create our database and the stores (which are like tables) within the database. To do that, we need to open up IndexedDB with the database name and version.

idb.open('DATABASE_NAME', VERSION, function(upgradeDb) {
	// Create stores
});

To create stores in our database, we use the createObjectStore method of upgradeDb. When creating a store, we pass two arguments -

The name of the store
An object with some optional settings. For example, the keyPath property, which allows us to specify what key in the object we want to be the primary key.

Here it is all together -

idb.open('DATABASE_NAME', VERSION, function(upgradeDb) {
	const store = upgradeDb.createObjectStore('STORE_NAME', {
    	keyPath: 'PRIMARY_KEY_NAME'
    });
});

We can also define indexes for the stores. Indexes provide us alternative ways of accessing the data. For example, in a store we may have data that has, amongst others, a timestamp and name key. If we ever want to retrieve the data by timestamp or name, we may want to have indexes for each of these keys.

idb.open('DATABASE_NAME', VERSION, function(upgradeDb) {
	const store = upgradeDb.createObjectStore('STORE_NAME', {
    	keyPath: 'PRIMARY_KEY_NAME'
    });
    store.createIndex('INDEX_NAME', 'KEY_PATH');
});

For the bitsofcode application, I created 3 stores - an ArticlesStore, a BookmarksStore and a SettingsStore. Here is how I created the first.

idb.open('bitsofcode', 1, function(upgradeDb) {
	const ArticlesStore = upgradeDb.createObjectStore('Articles', {
    	keyPath: 'guid'
    });
    ArticlesStore.createIndex('guid', 'guid')

    // Other stores..
});

This process of opening up IndexedDB and creating/updating the database itself returns the database, to which we can create/read/update/delete data. Because of this, it is best to wrap the creation of the database and stores in a function that can be reused.

const OpenIDB = function() {
	return idb.open('bitsofcode', 1, function(upgradeDb) {
	    const ArticlesStore = upgradeDb.createObjectStore('Articles', {
    	    keyPath: 'guid'
        });
        // etc etc
    });
};

Data CRUD #

Once the database and stores have been created, we can move on the the CRUD actions.

Create / Update #

IndexedDB is a transactional database system, which is a system where operations on the database can be rolled back if not completed properly. This means that whenever we want to interact with any of our data, we need to first open up a new transaction, perform our actions, then either commit or rollback the transaction depending on if things succeed. This may seem like a lot of tedious work to do, but this is critical for maintaining the integrity of data.

Therefore, to create (or update) data in our IndexedDB, we need to do the following things -

Open up the database
Open a new read/write transaction with the store within the database
Add the data to the store
Complete the transaction

These steps looks like this -

// 1. Open up the database
OpenIDB().then((db) => {
	const dbStore = 'ArticlesStore';

	// 2. Open a new read/write transaction with the store within the database
	const transaction = db.transaction(dbStore, 'readwrite');
	const store = transaction.objectStore(dbStore);

	// 3. Add the data to the store
	store.put(data);

	// 4. Complete the transaction
	return transaction.complete;
})

We are using the store.put() method here, which is also used for updating data in the database.

Read #

To retrieve data from IndexedDB, we need to do the following things -

Open up the database
Open a new read-only transaction with the store within the database
Return the data

These steps looks like this -

// 1. Open up the database
OpenIDB().then((db) => {
	const dbStore = 'ArticlesStore';

	// 2. Open a new read-only transaction with the store within the database
	const transaction = db.transaction(dbStore);
	const store = transaction.objectStore(dbStore);

	// 3. Return the data
	return store.getAll();
})

We can also get data by a specific index -

// 1. Open up the database
OpenIDB().then((db) => {
	const dbStore = 'ArticlesStore';

	// 2. Open a new read-only transaction with the store within the database
	const transaction = db.transaction(dbStore);
	const store = transaction.objectStore(dbStore);

    const index = store.index('INDEX_NAME');

	// 3. Return the data
	return index.getAll();
})

We can even get data by a value that correlates to the index -

// 1. Open up the database
OpenIDB().then((db) => {
	const dbStore = 'ArticlesStore';

	// 2. Open a new read-only transaction with the store within the database
	const transaction = db.transaction(dbStore);
	const store = transaction.objectStore(dbStore);

    const index = store.index('INDEX_NAME');

	// 3. Return the data
	return index.getAll('VALUE');
})

Delete #

Finally, to delete data from IndexedDB, we need to do the following things -

Open up the database
Open a new read/write transaction with the store within the database
Delete the data corresponding to the passed key
Complete the transaction

These steps looks like this -

// 1. Open up the database
OpenIDB().then((db) => {
	const dbStore = 'ArticlesStore';

	// 2. Open a new read/write transaction with the store within the database
	const transaction = db.transaction(dbStore, 'readwrite');
	const store = transaction.objectStore(dbStore);

	// 3. Delete the data corresponding to the passed key
	store.delete('DATA_KEY');

	// 4. Complete the transaction
	return transaction.complete;
})

Instant Loading Data with IndexedDB #

By saving the articles locally in IndexedDB, I was able to first serve those locally saved articles to users first, before going to the network to get the most up-to-date data. This is what the sequence of functions look like for the Latest Articles page.

Database.retrieve('Articles')
        .then((articlesFromDatabase) => {
            if (articlesFromDatabase.length == 0) return fetchArticles(true)
            didFetchArticlesFromDatabase = true;
            return Promise.resolve(articlesFromDatabase);
        })
        .then((articles) => {
            Articles = sortedArticles(articles);
            displayArticles(Articles);
            return Promise.resolve();
        })
        .then(() => { if (didFetchArticlesFromDatabase) updateArticlesInBackground() });

This creates an "Instant Loading" experience for users, with page load happening in 144ms!

Support for IndexedDB #

Can I Use indexeddb? Data on support for the indexeddb feature across the major browsers from caniuse.com.

“Offline First” with Service Worker (Building a PWA, Part 1)

2016-10-11T00:00:00Z

Over the past 5 months, I have been doing Udacity’s Senior Web Developer Nanodegree. For my final Capstone project (I've graduated now! 💃🏿), I had to create my very own web application that would function just as a native mobile application would, using all I learned throughout the Nanodegree. So, I decided to create a “Progressive Web Application” for this blog.

Get the Application | View Source

The Application #

The application I created allows users to read the latest articles from the blog (even when offline), bookmark interesting articles, and receive push notifications when a new article is released.

There are four pages available -

The Homepage is just an introduction to the application. Here is also the setting to enable/disable push notifications when a new article is released.
On Latest Articles page are the latest articles from the RSS feed. It displays excerpts from the latest 10-15 articles from the blog.
The Bookmarks page is the list of bookmarked articles. It displays the excerpts of all bookmarked articles.
Finally, the Single Article page displays the full article the user is reading.

The primary feature of the application is it's offline capabilities. There are two parts to creating an "offline-first" application -

Cache the app shell so pages and assets are accessible offline
Load locally-saved data first, then fetch updated data later if the network permits

In this article, I will go over how I achieve the first, using Service Worker. Next week, I will go over the second part. In the final part of this series, I will demonstrate how I implemented push notifications.

Libraries & Tools #

To make it as light as possible, I decided to build this application without the use of any front-end framework, just plain 'ol JavaScript. Here are some of the tools I used -

Gulp.js for build process
Handlebars.js for templating
SASS for awesome CSS
Babel for compiling ES2015
Firebase for hosting & SSL

The App Shell Model #

The App Shell Model is a way of architecting a progressive web application. The app shell is the "minimal HTML, CSS and JavaScript powering a user interface" (Google Developers). It is all the parts of the page that are static and can be cached, so that it only needs to be loaded once.

For example on the Latest Articles page, this is the shell (left) and when the articles are fetched, they are injected into the main part of the page (right).

On first visit over a 3G connection, the page will load at a relatively normal pace. This is when the app shell is cached. On repeated visits, the page shell loads almost instantly because there is no need to fetch it from a remote source.

Precaching the App Shell #

The cornerstone of a Progressive Web Application is the Service Worker. The Service Worker allows us an unprecedented control over the network by allowing us to intercept any and all fetch requests from the main document. Combined with the Cache Storage API, we can use the Service Worker to quickly serve content, even while completely offline.

In my Setting up a Basic Service Worker video tutorial, I showed how to handle precaching the app shell completely manually. In that method, we had to handle adding files to a versioned cache as well as checking for files from previous cache versions and clearing them out, like so -

var cacheName = 'v1';
var cacheFiles = [
	'./',
	'./index.html',
	'./js/app.js',
	'./css/reset.css',
	'./css/style.css'
];

self.addEventListener('install', function(e) {
    e.waitUntil(
    	// Open the cache
	    caches.open(cacheName).then(function(cache) {

	    	// Add all the default files to the cache
			console.log('[ServiceWorker] Caching cacheFiles');
			return cache.addAll(cacheFiles);
	    })
	);
});

self.addEventListener('activate', function(e) {
    e.waitUntil(
    	// Get all the cache keys (cacheName)
		caches.keys().then(function(cacheNames) {
			return Promise.all(cacheNames.map(function(thisCacheName) {

				// If a cached item is saved under a previous cacheName
				if (thisCacheName !== cacheName) {

					// Delete that cached file
					console.log('[ServiceWorker] Removing Cached Files from Cache - ', thisCacheName);
					return caches.delete(thisCacheName);
				}
			}));
		})
	);
});

However, there is now a much easier way to handle precache assets, with Google’s Service Worker Toolbox library*. Now, to add assets for precache, all we have to do is pass the toolbox an array of the files, and everything else will be handled for us.

// Import the Service Worker Toolbox file
importScripts('js/lib/sw-toolbox/sw-toolbox.js');

const precacheFiles = [
	'./',
	'./index.html',
	'./js/app.js',
	'./css/reset.css',
	'./css/style.css'
];

// Precache the files
toolbox.precache(precacheFiles)

We can check that the files have been cached in our developer tools. In Chrome, we can find the Cache Storage under Developer Tools > Application > Cache Storage. There should be a new store titled something like $$$toolbox-cache$$$SITE_URL_HERE$$$. For example, the storage for the bitsofcode app is called $$$toolbox-cache$$$https://app.bitsofco.de/$$$. When we click on the cache store, we can see the list of files we have cached. * Note - In a recent update, Google created a separate library, [Service Worker Preacache](https://github.com/GoogleChrome/sw-precache), which deals with precaching of assets alone. It works in a totally different way to the toolbox. It works with your build tool, e.g. Gulp, and generates the Service Worker file for you. Because of this major difference, I decided to stick with the toolbox as it is what I used when I did my Nanodegree. However, I might write about the new Precache library in a later article.

Serving the Precached Files #

Getting the files into the cache is only half the battle, we need to actually serve it to the user. In our Service Worker, we can listen for when there is a fetch request from the document using the fetch event listener.

self.addEventListener('fetch', (event) => { 
  // Do stuff 
});

Within this event, what we want to do it this -

Check the cache if a file matching that request is available
If it is, respond to the document with the file from the cache
If it isn’t, fetch the file from the network and respond to the document with the fetched file

Here is how we can execute that -

self.addEventListener('fetch', (event) => {
    // Respond to the document with what is returned from  
    event.respondWith(

		// 1. Check the cache if a file matching that request is available 
		caches.match(event.request).then((response) => {

			// 2. If it is, respond to the document with the file from the cache
        	if ( response ) return response

			/ 3. If it isn’t, fetch the file from the network and respond to the document with the fetched file
			return  fetch(event.request)

		})
     ); 
});

And because we are writing ES2015, we can shorten this into one glorious line -

self.addEventListener('fetch', (event) => { 
    event.respondWith( caches.match(event.request).then((response) => response || fetch(event.request)) );
});

Now, if we try to access any of the preached files while offline (or online), the page will load instantly with the cached files.

That's it! Next week I will go over the second part of the "Offline First" model, using IndexedDB to store the dynamic data (in this case the articles). You can try using the application yourself at app.bitsofco.de, or check out the source code on my GitHub repository.

Alternative Text and Images

2016-10-04T00:00:00Z

The most accessible format for any content on the web is plain text. Plain text is incredibly malleable, it can be altered in ways to cater to almost any disability. For users with no visual difficulties, they can simply read the text. If a user has visual impairments, the text can be converted to speech. Even if a user has both visual and auditory difficulties, plain text can be converted to braille.

However, most websites are not made up of pure text. We have other types of content that is not so malleable, like images. To make these alternative forms of content more accessible, we need to provide a text alternative of them.

For images, this is typically provided using the alt attribute. As a blanket rule, all images should have an alt attribute. This, however, does not mean that actual alternative text needs to be provided for every image. There are three states we can have for the alt attribute -

Defined - Where actual descriptive text is provided in the attribute, e.g. alt="A dog". In this case, a screen reader will read the text provided when the user comes across the image, and usually give the context that it is an image.
Null - Where the attribute is written but left empty, e.g. alt="". In this case, a screen reader will skip over the image entirely as if it never existed.
Invalid (bad practice) - Where the attribute is skipped entirely. In this case, a screenreader will read the value of the src attribute instead. Having this happen is never useful to the user, so it is advised that no images remain in this state.

In this article, we will go over when each of the first two states is suitable, and how different types of alternative text should be used.

Alternative Text for Different Image Types #

Broadly, there are 7 types of images. The way we handle alternative text is different for each.

1. Images of Text #

As a general rule, images of text should be avoided, the only exception to this being for logos. Due to the flexibility of CSS, we can now recreate pretty much any visual styling to plain text. So, using an image of text may only be needed in the rarest of circumstances.

In these rare cases, the best practice is to repeat the text of the image in the alt attribute. This will give screen reader users essentially the exact same experience as visual users.

<img src="example.jpg" alt="The quick brown fox jumped over the lazy dog">

2. Informative Images #

Informative images are images that, as you would guess, provide some information. This information can be anything from a label, to supplementary information, to just an impression.

For informative images, the alternative text should convey the same information that the image does. This might be as simple as one word saying what the image is. For example, in the image below, images are used to label each section.

<section>
  <h2><img src="location.png" alt="Location"></h2>
  <p>26 Eletu Ogabi...</p>
</section>

<section>
  <h2><img src="cutlery.png" alt="Cuisine"></h2>
  <p>Continental</p>
</section>

<section>
  <h2><img src="clock.png" alt="Opening Hours"></h2>
  <p>Monday 12:00 - 22:00 ...</p>
</section>

If the information that the image is conveying is more of an impression, then a physical description of the contents of the image may not be appropriate. Instead, we can provide the feeling that the image is trying to convey in the alternative text instead.

For example, on a website for dog sitters, the image below might be on the about page.

Image Source

The purpose of this image in that context is to show that the dogs have fun while they are there, so the alternative text should convey this feeling.

<img src="example.png" alt="Your dogs will have the best time!">

3. Functional Images #

Functional images are those that represent an action to be taken. Unlike informative images, which purely provide information for the user, functional images are used convey something actionable. These images are also typically tied to interactive elements such as links or buttons. For functional images, the alternative text should clearly communicate the action that is to be taken.

In the example below, the button used to filter the restaurants is represented by an image, so the alternative text displays the function of the button.

<img src="example.png" alt="Filter Restaurants">

4. Decorative Images #

Decorative images are images that don’t convey any actual/actionable information to the viewer. Their purpose is purely styling. For example, a background pattern on an element does not provide any informative value to the user.

In these cases, an empty alt attribute should be provided. This allows the image to be simply skipped by the screenreader since it is of no use to a user with visual impairments.

<img src="background.png" alt="">

5. Complex Images #

Complex images, a type of informative image, are those that contain a very detailed and substantial amount of information. For example bar charts or graphs. For these images, it is suggested that we provide both short and long descriptions.

The short description should be provided via the alt attribute. The long description can be defined in some other element, and simply referenced using the longdesc/ aria-labelledby attributes, or by using the <figure> and <figcaption> elements.

Here are the short and long descriptions for this image using the <figure> and <figcaption> elements -

<figure role="group">
  <img src="customers.png" alt="Line chart showing the number of customers over a period of 12 weeks">
  <figcaption>
    In the first week, there were 13,000 customers. This slowly rose over the next few weeks, then rose drastically in week 4 to 37,000 customers. This was maintained until week 7, where there were less than 10,00 customers. In week 8, the number of customers rose again to 35,000, but this dropped back down in week 9. Since then, the number of customers has risen, and in week 12 there were 50,000 customers.
  </figcaption>
</figure>

Alternatively, we can use the longdesc attribute.

<img src="customers.png"
     alt="Line chart showing the number of customers over a period of 12 weeks"
     longdesc="#customers-chart-desc">
<p id="customers-chart-desc">
    In the first week, there were 13,000 customers. This slowly rose over the next few weeks, then rose drastically in week 4 to 37,000 customers. This was maintained until week 7, where there were less than 10,00 customers. In week 8, the number of customers rose again to 35,000, but this dropped back down in week 9. Since then, the number of customers has risen, and in week 12 there were 50,000 customers.
</p>

We can also achieve the same thing using the aria-labelledby attribute in place of longdesc, which works in the same way.

6. Groups of Images #

There are cases where more than one image is used together to convey a single piece of information. For example, a 5-star rating can be represented by a group of individual star images.

In these cases, the information conveyed by the group of images together should be added to the alt text of just one of the images, and the rest should be left as null.

<img src="star.png" alt="4 out of 5 stars">
<img src="star.png" alt="">
<img src="star.png" alt="">
<img src="star.png" alt="">

7. Image Maps #

Finally, image maps are images that are divided into multiple sections each with their own interactive area. They are created by combining the <img> and <map> elements.

For these types of images, it is advised that a defined alt attribute be provided for the <img> element, as well as each individual <area>.

<img src="orgchart.png"
     alt="Board of directors and related staff: "
     usemap="#Map">
<map id="Map" name="Map">
 <area shape="rect"
	      coords="176,14,323,58"
	      href="[…]"
	      alt="Davy Jones: Chairman">
	[…]
	<area shape="rect"
	      coords="6,138,155,182"
	      href="[…]"
	      alt="Harry H Brown: Marketing Director (reports to chairman)">
	[
</map>

Example from W3C WAI Tutorials

When and How should you use `alt`? #

As with everything, when and what alt to use is also dependent on the context, not just the type of image. When deciding what to use, we should ask the following questions -

Is the image of text? If yes, repeat the same text in the image in the alt attribute. For example, alt="Same text as in image".
Is the image purely decorative or for styling purposes? If yes, set the alternative text to null, so it will be ignored by screen readers. For example, alt="".
Does the image represent an action the user can take? If yes, write out the action that will be taken when the user interacts with the element. For example, alt="Add to Cart".
Is the image purely informative? If yes, the alternative text should convey the same information as the image. For example, alt="Location".
Finally, does the image convey any information that is not also represented on the page as text? If yes, the alternative text should convey the same information as the image. If no, set the alternative text to null, so it will be ignored by screen readers.

Variable and Function Hoisting in ES2015

2016-09-27T00:00:00Z

Variable hoisting is a behaviour in JavaScript where variable declarations are moved to the top of the scope (function scope or global scope) that the variable is defined within. The typical JavaScript variable can be created in two stages - declaration and initialisation.

The declaration stage is where the variable reference is created, without any value. At this stage, if we try to access the variable value, we will get undefined. The second initialisation stage is where the actual value is assigned to the variable.

function exampleScope() {
  var foo; // Declaration
  foo = ‘Hello, world!’; // Initialisation

  var bar = ‘Hi there!’; // Declaration & Initialisation in one step
}

Hoisting is the behaviour of moving the declaration stage to the top of the scope, regardless of if the variable is declared and initialised in one step. This has always been a peculiar behaviour in JavaScript we just had to accept and work around. Fortunately, with the introduced of two new types of variables in ES2015, this behaviour is less of an issue.

Hoisting and `var` #

Prior to ES2015, var was the only form of variable we could use. The var variable is scoped to the function it sits within, or the global scope if it isn’t within a local function. Even with the introduction of let and const in ES2015, the old var still exists in its typical form.

When a variable is created using var, regardless of how, the declaration of the variable is “hoisted” to the top of the scope. For example, consider the following function -

function exampleScope() {
  // Other function stuff here
  var foo = ‘Hello, world!’;
}

The function above will actually be interpreted as the following -

function exampleScope() {
  var foo;
  // Other function stuff here
  foo = ‘Hello, world!’;
}

At first glance, this may not seem to have a real effect on anything. However, it can lead to a very peculiar behaviour where variables can be used before they are actually created in our code.

Hoisted variables can be accessed before they are initialised

Typically, if we try to use a variable that has not been defined, we get a ReferenceError, which stops the rest of the script for executing.

function exampleScope() {
  console.log(foo); // => ReferenceError: foo is not defined [Stop script execution]
  console.log(“This will never be logged”);
}

However, if we declare and initialise the variable after trying to use it, we simply get undefined, a non-blocking error.

function exampleScope() {
  console.log(foo); // => undefined
  var foo = “Hello, world!”;
  console.log(foo); // => “Hello, world!”
  console.log(“This sentence will be logged”); // => “This sentence will be logged”
}

Because of hoisting, the above code is actually equivalent to us having written the following -

function exampleScope() {
  var foo;
  console.log(foo); // => undefined
  foo = “Hello, world!”;
  console.log(foo); // => “Hello, world!”
  console.log(“This sentence will be logged”); // => “This sentence will be logged”
}

Hoisting and `let` #

The let variable is a new form of variable introduced in ES2015. Instead of being scoped to the nearest function, let is scoped to the nearest block. This means that let variables defined within non-function blocks like if will only be available within those blocks.

The let variable, like var, can be created in the two stages - declaration and initialisation. However, the hoisting behaviour does not apply. If we repeat the example above using let instead, we will get a ReferenceError because foo does not exist at the point it is trying to be used.

function exampleScope() {
  console.log(foo); // => ReferenceError: foo is not defined [Stop script execution]
  let foo = “Hello, world!”; 
  console.log(foo); 
  console.log(“This will never be logged”);
}

Hoisting and `const` #

The const variable is another new form of variable (technically, a constant) introduced in ES2015. Like let, it is scoped to the block, rather than the function. Unlike let and var, const must be declared and initialised in one step. Additionally, once this step is complete, the value cannot be modified.

Because of this, hoisting does not apply to const either.

function exampleScope() {
  console.log(foo); // => ReferenceError: foo is not defined [Stop script execution]
  const foo = “Hello, world!”; 
  console.log(foo); 
  console.log(“This will never be logged”);
}

Function Hoisting #

In addition to variables, hoisting applies to functions created using the function declaration syntax.

Function declarations, as with the const variable, are defined and initialised in one step. However, functions are hoisted by moving the entire function, not just the declaration, to the top of the scope. This means that functions can always be used before they are created, as long as the usage is within the same scope.

function exampleScope() {
  foo(); // => “Hello, world!”

  function foo() {
    console.log(“Hello, world!”)
  }
}

Functions referenced by variables, on the other hand, are subject to the hoisting rules for the variable used. For example, if we create a function and assign it to a var variable, the declaration will be hoisted to the top of the scope. However, because it is only declared and not initialised as a function, we will not be able to call the function before the initialisation stage.

function exampleScope() {
  console.log(foo); // => undefined
  
  foo(); // => TypeError: foo is not a function [Stop script execution]

  var foo = function() {
    console.log(“Hello, world!”)
  }
}

What does this mean for ES2015? #

When writing ES2015, the best practice is to always use const. If you need the variable to be updated, then use let. There should be almost no circumstance in which using var is the better option, and so hoisting should not be an issue.

Make let not var #javascript #es2015 #es6 pic.twitter.com/IoJrKej83I — Ire Aderinokun (@ireaderinokun) September 14, 2016

Nonetheless, function hoisting is still present, so this is a behaviour we should still be conscious of.

The New System Font Stack?

2016-09-20T00:00:00Z

A few months ago, I wrote about how you can use system fonts in the browser using the built-in keywords that work with the font shorthand property (see Using System Fonts in the Browser). These keywords can be useful, but they also have some drawbacks, the main one being that they only work with the shorthand font property. This means that we cannot use it in a list of font families with fallbacks or as a fallback itself.

Relatively recently, some websites and web applications have been adopting a new method for using system fonts in the browser. With this method, the fonts used by different systems are explicitly called themselves in the font-family property.

The Font Stack #

At the moment, there is not one universally-used sequence of fonts for this system font stack. However, the fonts used by different sites, although not exactly the same, overlap. These are the different fonts that have been used, and the devices (and browsers) they target -

Font	Device Targeted
`-apple-system` (San Francisco)	iOS Safari, macOS Safari, macOS Firefox
`BlinkMacSystemFont` (San Francisco)	macOS Chrome
`Segoe UI`	Windows
`Roboto`	Android, Chrome OS
`Oxygen` / `Oxygen-Sans`	KDE
`Fira Sans`	Firefox OS
`Droid Sans`	Older versions of Android
`Ubuntu`	Ubuntu
`Cantarell`	GNOME
`Helvetica Neue`	macOS versions < 10.11
`Arial`	Any
`sans-serif`	Any

The order in which the fonts are defined in the font-family property is very important. Because we are just passing font names to the property, the font that will be used is the first font available on the user's machine that matches that name. This means that we have to craft the stack in such a way that the first font available to the user is their system font, and not some font they have installed on their machine.

We do this by starting with the most specific fonts possible, and moving on to fonts that are less guaranteed to be tied to a specific device. For example, the first font defined is always -apple-system. This will certainly only be applied to users on an iOS or macOS device. Further down the line, we have Roboto. This is a font that very well could be installed on a Mac user's device, but since the font stack started with the more specific -apple-system, we don't have to worry about this conflict.

Examples #

Here is how this new system font stack is used across different websites. Starting with Wordpress 4.6 -

body {
   font-family: -apple-system,
                BlinkMacSystemFont,
                "Segoe UI",
                Roboto,
                Oxygen-Sans,
                Ubuntu,
                Cantarell,
                "Helvetica Neue",
                sans-serif;
}

Medium -

body {
  font-family: -apple-system,
               BlinkMacSystemFont,
               "Segoe UI",
               Roboto,
               Oxygen,
               Ubuntu,
               Cantarell,
               "Open Sans",
               "Helvetica Neue",
               sans-serif;
}

Ghost -

body {
  font-family: -apple-system,
               BlinkMacSystemFont,
               "Segoe UI",
               Roboto,
               Oxygen,
               Ubuntu,
               Cantarell,
               "Fira Sans",
               "Droid Sans",
               "Helvetica Neue",
               sans-serif;
}

Finally, GitHub -

body {
  font-family: -apple-system,
               BlinkMacSystemFont,
               "Segoe UI",
               Roboto,
               Helvetica,
               Arial,
               sans-serif,
               "Apple Color Emoji",  /* Emojis*/
               "Segoe UI Emoji", /* Emojis*/
               "Segoe UI Symbol"; /* Emojis*/
}

Here is a comparison between the font stacks used by these sites -

Wordpress	Medium	Ghost	Github
`-apple-system`	`-apple-system`	`-apple-system`	`-apple-system`
`BlinkMacSystemFont`	`BlinkMacSystemFont`	`BlinkMacSystemFont`	`BlinkMacSystemFont`
`“Segoe UI”`	`“Segoe UI”`	`“Segoe UI”`	`“Segoe UI”`
`Roboto`	`Roboto`	`Roboto`	`Roboto`
`Oxygen-Sans`	`Oxygen`	`Oxygen`	`Helvetica`
`Ubuntu`	`Ubuntu`	`Ubuntu`	`Arial`
`Cantarell`	`Cantarell`	`Cantarell`	`sans-serif`
`“Helvetica Neue”`	`“Open Sans”`	`“Fira Sans”`
`sans-serif`	`“Helvetica Neue”`	`“Droid Sans”`
	`sans-serif`	`“Helvetica Neue”`
		`sans-serif`

Why use this Font Stack? #

There are a number of benefits to using system fonts in general, and to this particular method of using them.

Performance #

The number one reason for using system fonts at all is performance. Fonts are typically one of the largest/heaviest resources loaded on a website. If we can use a font already available on the user’s machine, we can completely eliminate the need to fetch this resource, making load times noticeably faster.

The Native Feel #

Another benefit of using system fonts is that it creates a feeling of the website being in a native application. This makes this method particularly useful for web applications, such as Wordpress or GitHub, rather than websites, as the former may be trying to emulate native applications.

Greater Control #

In comparison to using the built-in keywords with the font shorthand property, this method offers us a lot more control when specifying our fonts. We can define which font families we want to favour. Additionally, the other typography-related properties are not affected since this method only applies to the font-family property.

Websites Don't Need to Look the Same Everywhere #

Although the fact that different fonts will be shown for different users may seem like a drawback, in actual fact this doesn't matter. As mrmrs aptly put it -

Public service announcement:

Your website doesn't need to look the same everywhere. It just needs to work everywhere. — murmurs (@mrmrs_) September 13, 2016

What are the Drawbacks? #

Using this method also has some drawbacks to consider.

Naming Conflicts #

Besides -apple-system and BlinkMacSystemFont, all we are doing is calling the actual name of fonts. This means that, if a user has a font by that same name installed on their machine that isn't their system font, that may be used instead. This is what happened to Medium when they first rolled out this method last year.

Maintenance #

This list of fonts will have to be maintained and updated as the system fonts used by the various operating systems change. Hopefully, more operating systems will move towards Apple's method of having a generic name that will target the latest device font. But until then, a list will need to be periodically iterated on.

Using this Font Stack Today #

If you would like to use this font stack today, which fonts you use will be dependent on your users. Personally, I think the Wordpress method is the most suitable for the largest amount of users, and has been extensively tested by their team.

body {
   font-family: -apple-system,
                BlinkMacSystemFont,
                "Segoe UI",
                Roboto,
                Oxygen-Sans,
                Ubuntu,
                Cantarell,
                "Helvetica Neue",
                sans-serif;
}

Whichever method you choose, make sure to test it across the different browsers (and versions) that are important to the particular site.

JavaScript Promises 102 - The 4 Promise Methods

2016-09-13T00:00:00Z

As I covered in JavaScript Promises 101, a promise in JavaScript is an object that represents the result of an operation that hasn't been completed yet, but will at some undetermined point in the future.

The Promise object itself (i.e. not an object on the prototype) has four methods available to it -

resolve()
reject()
all()
race()

Promise.resolve() #

Typically, when we create promises, we create them as functions that perform some asynchronous operation which will resolve when the operation is complete (or reject if it fails). The Promise.resolve() method, however, returns a Promise object that is immediately resolved. It accepts one argument, a value that can be passed to the .then() function.

Although this may seem counter to the purpose of promises, as there is no asynchronous operation being carried out, there are a few cases when this method is useful.

Example 1 - Returning Static Values as Promises #

One use case for the Promise.resolve() method is when we need to return a static value as a promise. To keep a chain of promises going, we need to return keep returning more promises. For example, in this sequence of fetch requests, we only move to the next .then() function when we return a promise that is resolved.

get(url)
.then((response) => {
    response = JSON.parse(response);
    const secondURL = response.data.url
    return get( secondURL ); /* Return another Promise */
})
.then((response) => {
    response = JSON.parse(response);
    const thirdURL = response.data.url
    return get( thirdURL ); /* Return another Promise */
})
.catch((err) => handleError(err) );

// Note: The get() function is a promise-ified XMLHTTPRequest
// (see https://bitsofco.de/javascript-promises-101/)

But what if, in the second step, we wanted to pass a value to the third step that was just static value, not a value received from a Promise? We can do that using Promise.resolve(), passing in the static value.

get(url)
.then((response) => {
    response = JSON.parse(response);
    const secondURL = response.data.url;
    return Promise.resolve( secondURL ); /* Return a manually created Promise */
})
.then((secondURL) => get( secondURL ) )
.catch((err) => handleError(err) );

This way, we can keep the chain of promises going, even when working with regular functions or static values.

Example 2 - Starting Chains & Building Sequences #

Another use case for the Promise.resolve() method is if we want to start a promise chain, but the initial value we need isn’t a promise. An example of this is if we want to dynamically create a promise sequence, and we need an initial promise to start it all off.

Let's say we have an array of JSON files we need to get. In each of the files, there is an image url we need to retrieve and display on the page. So, for each item in the array of JSON files, we want to do the following (in the order they are in in the array) -

get(url)
.then((response) => {
	response = JSON.parse(response);
	displayImage(response.image);
})

If we are sure of the number of files we need to work with, we could just write out each of these tasks ourselves. But that wouldn't be very efficient, and what if we didn't know the exact number of files?

To solve this problem, we can loop through each of the files, and create the above promise chain. But to make sure that we execute each of the files in sequence, we need to have an initial Promise to which we append the subsequent promise chains. This is what it looks like -

const dataFiles = ['one.json', 'two.json', 'three.json'];

const sequence = Promise.resolve(); // Initial Promise

dataFiles.forEach((dataFile) => {

  // Add to the initial promise sequence
  sequence = sequence.then(() => {
  	return get(url).then((response) => {
		response = JSON.parse(response);
		displayImage(response.image);
	});
  });

});

Because we are appending to an existing promise, we needed that first resolved promise to get the chain started.

Promise.reject() #

The Promise.reject() method works like Promise.resolve(), but instead returns a promise object that is immediately rejected. It accepts one argument, the error that can be passed to the .catch() function.

The primary use case for this method is similar to the first use case for Promise.resolve(). It can be used to throw errors based on static values. For example, in a promise chain, we may want to throw an error based on a simple check we make, which is not necessarily based on an asynchronous operation.

get(url)
.then((response) => {

	if ( response.data.length < 10 /* Can be any manual check */ ) {
	  return Promise.reject(new Error('Not enough data to continue'));
	}

    response = JSON.parse(response);
    const secondURL = response.data.url
    return get( secondURL );
})
.then((response) => {
    response = JSON.parse(response);
    const thirdURL = response.data.url
    return get( thirdURL );
})
.catch((err) => handleError(err) );

Promise.all() #

The Promise.all() method offers us a way of dealing with multiple promises together. The method accepts an iterable list of items as it’s only argument, executes any promises within them, and returns a promise.

If all the promises within the iterable list are successfully resolved, it will return an array of the values to be read by the .then() function.

const promise1 = Promise.resolve('foo');
const promise2 = new Promise(function(resolve, reject) {
  setTimeout(resolve, 100, 'bar');
});
const promise3 = 'baz'; // Doesn't actually have to be a promise

Promise.all([promise1, promise2, promise3]).then((arrayOfResponses) => {
  console.log(arrayOfResponses);
  // ['foo', 'bar', 'baz']
});

If, however, even one of the promises in the iterable list is rejected, the entire promise is rejected.

const promise1 = Promise.resolve('foo');
const promise2 = new Promise(function(resolve, reject) {
  setTimeout(resolve, 100, 'bar');
});
const promise3 = Promise.reject('Error');

Promise.all([promise1, promise2, promise3]).then((arrayOfResponses) => {
    console.log(arrayOfResponses);
}).catch((err) => {
    console.log(err);
    // 'Error'
});

This method is extremely useful when we have a group of asynchronous actions that are dependent on each other, so it becomes important that all be resolved together, or none at all.

Promise.race() #

Finally, the Promise.race() method offers an alternative way of dealing with multiple promises. Like Promise.all(), it accepts an iterable list of items as it’s only argument, executes any promises within them, and returns a promise.

However, this method will return as soon as any one of the promises in its list resolves or rejects, and passes the value or error message of that single promise to the .then() or .catch() function.

const promise1 = new Promise(function(resolve, reject) {
  setTimeout(resolve, 500, 'foo');
});
const promise2 = new Promise(function(resolve, reject) {
  setTimeout(resolve, 100, 'bar');
});
const promise3 = new Promise(function(resolve, reject) {
  setTimeout(resolve, 900, 'baz');
});

Promise.race([promise1, promise2, promise3]).then((response) => {
  console.log(response);
  // bar
});

The use case for this method is less obvious than the others. From what I can tell the only scenario in which it will be useful is if you're trying to fetch the same resource from different places, so in this case you can deal with the response from whichever is the quickest, and discard the rest.

nth-child vs nth-of-type

2016-09-06T00:00:00Z

The nth-child() and nth-of-type() selectors are “structural” pseudo-classes, which are classes that allow us to select elements based on information within the document tree that cannot typically be represented by other simple selectors.

In the case of nth-child() and nth-of-type(), the extra information is the element’s position in the document tree in relation to its parent and siblings. Although these two pseudo-classes are very similar, they work in fundamentally different ways.

How `nth-child()` Works #

The nth-child() pseudo-class is used to match an element based on a number, which represents the element’s position amongst it’s siblings. More specifically, the number represents the number of siblings that exist before the element in the document tree (minus 1).

This number is expressed as a function, an+b, where n is the index, and a and b are any integers we pass. For example, to select every element, we could write any of the following -

:nth-child(1n+0) { /* styles */ }
:nth-child(n+0) { /* styles */ }
:nth-child(1n) { /* styles */ }

In addition to using this function, we can pass a single integer, e.g. :nth-child(1) or use one of the set keywords, odd or even. These keywords are alternatives for writing out the functional notation for selecting every odd or even numbered element.

:nth-child(odd) { /* styles for odd elements */ }
:nth-child(2n+1) { /* styles for odd elements */ }

:nth-child(even) { /* styles for even elements */ }
:nth-child(2n+0) { /* styles for even elements */ }

When using :nth-child() on its own, it is simple enough to predict which element will be selected. For example, using this markup -

<div class="example">
	<p>This is a <em>paragraph</em>.</p>
	<p>This is a <em>paragraph</em>.</p>
	<p>This is a <em>paragraph</em>.</p>
	<div>This is a <em>divider</em>.</div>
	<div>This is a <em>divider</em>.</div> <!-- Element to select -->
	<p>This is a <em>paragraph</em>.</p>
	<p>This is a <em>paragraph</em>.</p>
	<div>This is a <em>divider</em>.</div>
	<p>This is a <em>paragraph</em>.</p>
	<div>This is a <em>divider</em>.</div>
</div>

If we wanted to select the fifth element, the div, we could simply write the following -

.example :nth-child(5) { background: #ffdb3a; }

However, unexpected results may occur when there are multiple types of elements, and we need to combine the :nth-child() pseudo-class with type or class selectors. For example, to select that same div element again, we may be tempted to write the following -

.example div:nth-child(2) { background: #ffdb3a; }

Note - Will not work

The reason this will not work is because the element that selector is targeting does not actually exist. Using the above selector, the user agent will go through the following steps -

Select all the child elements of .example
Find the second element in that list, irrespective of type
Check if that element is a type of div

Since the second element in the document tree is a paragraph, not a div, nothing is selected. If we wanted to select the second div element, we would have to use the nth-of-type() pseudo-class.

How `nth-of-type()` Works #

The nth-of-type() pseudo-class, like nth-child(), is used to match an element based on a number. This number, however, represents the element's position within only those of its siblings that are of the same element type.

This number can also be expressed as a function, or using the keywords even or odd. Using the example markup above, we can select all the odd paragraphs by writing -

.example p:nth-of-type(odd) { background: #ffdb3a; }

When we use this selector, the user agent goes through the following steps -

Select all the child elements of .example that are of the type p
Create a new list of only these elements
Select the odd numbers from that list

Because of this, we can now select the second div, the fifth child of .example -

.example div:nth-of-type(2) { /* styles */ }

Other "nth" Pseudo-Classes #

Besides nth-child() and nth-of-type(), there are a number of other structural pseudo-classes we can use to select elements based on their position within their siblings. Like nth-child() and nth-of-type(), they fall into two groups - the ones that are type-independent, like nth-child(), and the ones that are type-dependent, like nth-of-type().

Type-independent	Type-dependent
nth-child()	nth-of-type()
nth-last-child()	nth-last-of-type()
first-child()	first-of-type()
last-child()	last-of-type()
only-child()	only-of-type()

Counting From The End - `nth-last-child()` vs `nth-last-of-type()` #

These pseudo-classes work like nth-child() and nth-of-type(), but they begin counting from the last element in the group of siblings instead of the first.

.example :nth-last-child(1) { background: #a6cae7; } 
.example p:nth-last-of-type(1) { background: #ffdb3a; }

The First Element - `first-child()` vs `first-of-type()` #

The first-child() and first-of-type() pseudo-classes select the first element. They can be thought of as using the nth-child() and nth-of-type() pseudo-classes, but simply passing in a value of 1.

.example :first-child() { /* styles */ }
.example :nth-child(1) { /* styles */ } /* same as above */

.example :first-of-type() { /* styles */ }
.example :nth-of-type(1) { /* styles */ } /* same as above */

The Last Element - `last-child()` vs `last-of-type()` #

These are the opposite to the first-child() and first-of-type() pseudo-classes. They can be thought of as using the nth-last-child() and nth-last-of-type() pseudo-classes, but passing in a value of 1.

.example :last-child() { /* styles */ }
.example :nth-last-child(1) { /* styles */ } /* same as above */

.example :last-of-type() { /* styles */ }
.example :nth-last-of-type(1) { /* styles */ } /* same as above */

The Only Element - `only-child()` vs `only-of-type()` #

Finally, these pseudo-classes will select an element that is the only child. For only-child(), the element must be literally the only child of it’s parent, regardless of type. For only-of-type(), the element need only be the only child of its type.

.example :only-child() { /* styles */ }

.example p:only-of-type() { /* styles */ }

Toast.js, a Library for Toast messages

2016-08-23T00:00:00Z

Last week I created a small library for creating Toast messages. Here, I thought I would share my process in creating it and the code behind it.

The HTML #

The Toast is made up of two elements. The Toast message itself, .toastjs, and a container element, .toastjs-container.

<div class="toastjs-container" role="alert" aria-hidden="true">
    <div class="toastjs"><!-- Content here --></div>
</div>

Until a Toast is being displayed, the container is hidden using the aria-hidden attribute.

The CSS #

To create the sliding in/out animation of the Toast, a transform is applied to the Toast container element. By default, the .toastjs-container is positioned off-screen to the left.

.toastjs-container {
    transform: translateX(-150%);
	transition: transform 1s;

    /* Other styles */
	position: fixed;
	bottom: 30px;
	left: 30px;
    width: calc(100% - 60px);
	max-width: 400px;
}

When the Toast message is being displayed, as is determined by it's aria-hidden attribute, the element is positioned to a normal state.

.toastjs-container[aria-hidden="false"] {
	transform: translateX(0%);
}

The JavaScript #

The Toast is a custom Toast prototype. There are five main methods behind it.

Toast.prototype._createElements #

This function creates the Toast element and it's container, with all the appropriate attributes and classes. It also appends it to the body element.

Toast.prototype._createElements = function() {
    return new Promise((resolve, reject) => {

        this.toastContainerEl = document.createElement('div');
        this.toastContainerEl.classList.add('toastjs-container');
        this.toastContainerEl.setAttribute('role', 'alert');
        this.toastContainerEl.setAttribute('aria-hidden', true);

        this.toastEl = document.createElement('div');
        this.toastEl.classList.add('toastjs');

        this.toastContainerEl.appendChild(this.toastEl);
        document.body.appendChild(this.toastContainerEl);

        setTimeout(() => resolve(), 500);

    })
};

Toast.prototype._addEventListeners #

This function adds event listeners to the buttons within the toast. By default, there is at least a close button. Optionally, there are custom buttons with custom callback functions that should be applied.

Toast.prototype._addEventListeners = function() {

    document.querySelector('.toastjs-btn--close').addEventListener('click', () => {
        this._close();
    })

    if ( this.options.customButtons ) {
        const customButtonsElArray = Array.prototype.slice.call( document.querySelectorAll('.toastjs-btn--custom') );
        customButtonsElArray.map( (el, index) => {
            el.addEventListener('click', (event) => this.options.customButtons[index].onClick(event) );
        });
    }

};

Toast.prototype._close #

This is the function that is called when the Toast is closed. It first sets the correct aria-hidden attribute on the Toast container, then resets the main Toast element.

Toast.prototype._close = function() {
    return new Promise((resolve, reject) => {
        this.toastContainerEl.setAttribute('aria-hidden', true);
        setTimeout(() => {

            this.toastEl.innerHTML = '';
            this.toastEl.classList.remove('default', 'success', 'warning', 'danger');

            if ( this.focusedElBeforeOpen ) {
                this.focusedElBeforeOpen.focus();
            }

            resolve();

        }, 1000);
    });
};

Toast.prototype._open #

This is the function that is called when the Toast is opened. It does the following things -

Sets the correct aria-hidden attribute to the Toast container
Adds the correct class to the Toast element
Adds the correct message content to the Toast element
Creates any custom buttons if specified

Toast.prototype._open = function() {

    this.toastEl.classList.add(this.options.type);
    this.toastContainerEl.setAttribute('aria-hidden', false);

    let customButtons = '';
    if ( this.options.customButtons ) {
        customButtons = this.options.customButtons.map( (customButton, index) => {
            return `<button type="button" class="toastjs-btn toastjs-btn--custom">${customButton.text}</button>`
        } )
        customButtons = customButtons.join('');
    }

    this.toastEl.innerHTML = `
        <p>${this.options.message}</p>
        <button type="button" class="toastjs-btn toastjs-btn--close">Close</button>
        ${customButtons}
    `;

    this.focusedElBeforeOpen = document.activeElement;
    document.querySelector('.toastjs-btn--close').focus();
};

Toast.prototype._init #

Finally, this is the function that initialises the Toast. It calls all the other functions in their correct sequence.

Toast.prototype._init = function() {
    Promise.resolve()
    .then(() => {
        if ( this.toastContainerEl ) {
            return Promise.resolve();
        }
        return this._createElements();
    })
    .then(() => {
        if ( this.toastContainerEl.getAttribute('aria-hidden') == 'false'  ) {
            return this._close();
        }
        return Promise.resolve();
    })
    .then(() => {
        this._open();
        this._addEventListeners();
    })
};

You can view the full source for the library here, or view a demo.

Making botsofcode - An Introduction to Twitter Bots

2016-08-16T00:00:00Z

Another addition to my bot army! This time, I made a very simple twitter bot for this blog, @botsofcode (Source Code).

The Setup #

I created @botsofcode using Twit, a simple Twitter API Client for Node.js. To setup Twit, we need to first create a Twitter Application and get four private keys.

Consumer Key (API Key)
Consumer Secret (API Secret)
Access Token
Access Token Secret

Once the application is created, these keys can be found under the ‘Keys and Access Tokens’ section.

Once we have these keys, we can create a new Node.js project and initialise Twit.

const Twit = require('twit');
const T = new Twit({
	consumer_key: APPLICATION_CONSUMER_KEY_HERE,
	consumer_secret: APPLICATION_CONSUMER_SECRET_HERE,
	access_token: ACCESS_TOKEN_HERE,
	access_token_secret: ACCESS_TOKEN_SECRET_HERE
});

Listening for Events and Keywords #

Twitter's Streaming APIs gives us access to the global stream of tweets. There are two streams we can currently follow -

The Public Stream, which is the stream of all public tweets
The User Stream, which is a stream of tweets corresponding to a single user's view

@botsofcode uses the public stream, because it listens for tweets from any user that mention this blog.

We can create a stream of tweets based on a filter using the statuses/filter endpoint and passing an object with the filter parameters. We can pass parameters like language or location, but to filter by keyword, we use the track parameter. This accepts a string or array of keywords to watch for.

const stream = T.stream('statuses/filter', { track: ['bitsofco.de', 'bitsofcode'] });

Once the stream is created, we can listen for any tweets that fall within the stream.

stream.on('tweet', (tweet) => {
	// Do something with the tweet
});

Responding to Events #

Twitter's REST API allows us to take pretty much any action you could if you were using twitter directly. We can post tweets, retweet, reply to tweets, follow users, favourite/like, etc.

I built @botsofcode to be able to take four actions - retweet, like, reply, and add to a list.

Retweet #

If the tweet found from the stream was from myself (@ireaderinokun), @botsofcode should just retweet it. We can retweet by posting to the /statuses/retweet/:id endpoint.

const me = {
	id: 2714960622,
	screen_name: 'ireaderinokun'
};

const stream = T.stream('statuses/filter', { track: ['bitsofco.de', 'bitsofcode'] });
stream.on('tweet', (tweet) => {
	if ( tweet.user.id === me.id ) {
		T.post('statuses/retweet/:id', { id: tweet.id_str });
		return;
	}
});

Like #

If the tweet was from any other account, like it. We can like a tweet by posting to the /favorites/create endpoint, passing the id of the tweet we want to like.

stream.on('tweet', (tweet) => {

	if ( tweet.user.id === me.id ) { ... }

	T.post('favorites/create', { id: tweet.id_str });
});

Reply #

If the tweet was by any other user, send them a reply. We can reply to a tweet by posting to the /statuses/update endpoint and passing the id of the tweet we are replying to.

stream.on('tweet', (tweet) => {

	if ( tweet.user.id === me.id ) { ... }

	T.post('favorites/create', { id: tweet.id_str });

	T.post('statuses/update', {
		status: `@${tweet.user.screen_name} Thanks for sharing! ${emojis[Math.floor(Math.random() * emojis.length)]`,
		in_reply_to_status_id: tweet.id_str
	});

});

Add to List #

Finally, add the user to a twitter list. We can do this by posting to the lists/members/create endpoint and passing the list parameters.

stream.on('tweet', (tweet) => {

	if ( tweet.user.id === me.id ) { ... }

	T.post('favorites/create', { id: tweet.id_str });

	T.post('statuses/update', {
		status: `@${tweet.user.screen_name} Thanks for sharing! ${emojis[Math.floor(Math.random() * emojis.length)]`,
		in_reply_to_status_id: tweet.id_str
	});

    T.post('lists/members/create', {
		slug: 'bitsofcoders',
		owner_screen_name: botsofcode.screen_name,
		screen_name: tweet.user.screen_name
	});

});

Deployment #

I used Heroku to host @botsofcode. Deploying a Node.js app to Heroku is simple, we just need to make sure that the following information is specified in our package.json file -

The main script
The start script
Any dependencies
The version of Node.js

This is my package.json file for the bot -

{
  "name": "botsofcode",
  "version": "1.0.0",
  "description": "A bot for bitsofco.de",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "author": "ire-aderinokun",
  "dependencies": {
    "twit": "^2.2.4"
  },
  "engines": {
    "node": "4.1.1"
  }
}

Optional - Setting up Config Variables #

To keep the Twitter Application keys out of the app files, I used Heroku's config variables. These can be defined under the application settings.

In the actual application script, we can then reference them as environment variables -

const T = new Twit({
	consumer_key: process.env.consumer_key,
	consumer_secret: process.env.consumer_secret,
	access_token: process.env.access_token,
	access_token_secret: process.env.access_token_secret
});

That's it! You can follow @botsofcode, view it's source, or click the tweet button below to see it in action.

JavaScript Array Methods - Mutator Methods

2016-08-09T00:00:00Z

Whenever an array is created, we have access to some native methods we can use to with the array. There are currently over 30 of these methods. In this video, which is the first part in this series, I go over the "mutator methods", which are methods that will modify the original array when used. These are -

Array.prototype.pop()
Array.prototype.shift()
Array.prototype.push()
Array.prototype.unshift()
Array.prototype.reverse()
Array.prototype.sort()
Array.prototype.splice()
Array.prototype.fill()
Array.prototype.copyWithin()

You can get the files I worked with in this video in my repository.

Creating An Accessible Modal Dialog

2016-08-02T00:00:00Z

Modal Dialogs are a tricky thing to make accessible. For visual users navigating with a mouse, creating a dialog is as simple as styling the element to look visually different from the rest of the page. However, users navigating a site via a keyboard and/or screenreader need a lot more.

Luckily, the WAI-ARIA Specification provides some guidelines on how to build an accessible modal dialog. Their guidelines can be broken up into size parts -

Markup the Dialog and Dialog Overlay Appropriately
On Dialog Open, Set Focus
On Dialog Close, Return Focus to the Last Focused Element
While Open, Prevent Mouse Clicks Outside the Dialog
While Open, Prevent Tabbing to Outside the Dialog
While Open?
Allow the ESC Key to Close the Dialog

1. Markup the Dialog and Dialog Overlay Appropriately #

The Dialog #

Dialogs should have an appropriate role and label

When creating a dialog, we need to make sure that it has the appropriate role, in this case dialog. We also need to make sure that there is a label for the dialog, provided using the aria-labelledby and optionally the aria-describedby attributes (see HTML for Screen Readers).

Neither of the labels need to be visually displayed on the screen, as long as they are in the document tree.

<div class="dialog" role="dialog" aria-labelledby="dialog-title" aria-describedby="dialog-description">
	<h1 id="dialog-title">Site Navigation</h1>
	<p id="dialog-description" class="sr-only">Description goes here</p>
	<nav>
		<ul>
			<li><a href="one.html">Link One</a></li>
			<li><a href="two.html">Link Two</a></li>
			<li><a href="three.html">Link Three</a></li>
		</ul>
	</nav>
	<button type="button" aria-label="Close Navigation" class="close-dialog"> <i class="fa fa-times"></i> </button>
</div>

The Overlay #

The dialog overlay should be a separate element, preferably a child of the <body> element (we will see why in a following section). It does not require any special ARIA attributes.

<body>
	<div class=“body-content”></div>
	<div class=“dialog”></div>
	<div class=“dialog-overlay”></div>
<body>

2. On Dialog Open, Set Focus #

When first opened, focus should be set to the first focusable element within the dialog

To achieve this, we need to generate an array of all the focusable elements within the dialog. Elements that can receive focus are anchors, form input elements, buttons, and any element with a tabindex of 0 or greater. We can get the array by querying the document for all of these types of elements -

function Dialog(dialogEl, overlayEl) {

    this.dialogEl = dialogEl;

    var focusableEls = this.dialogEl.querySelectorAll('a[href], area[href], input:not([disabled]), select:not([disabled]), textarea:not([disabled]), button:not([disabled]), [tabindex="0"]');
    this.focusableEls = Array.prototype.slice.call(focusableEls);
}

We can then get the first of these focusable elements and use the focus() method to direct focus to it.

this.firstFocusableEl = focusableEls[0];
this.firstFocusableEl.focus();

There should be always at least one focusable element in the dialog. If there are no focusable elements within the content of the dialog, there should still be the button that closes the dialog itself.

3. On Dialog Close, Return Focus to Last Focused Element #

When the dialog is closed, focus should be returned to the element that opened it

When the dialog is first opened, we can determine which element opened it by checking the active element in the document (before we redirect focus away).

Dialog.prototype.open = function() {
    this.focusedElBeforeOpen = document.activeElement;
}

When the dialog is then closed, we can easily set that element to focus.

Dialog.prototype.close = function() {
    this.focusedElBeforeOpen.focus();
};

4. While Open, Prevent Mouse Clicks Outside the Dialog #

Users should not be able to click on elements outside the dialog window

We can achieve this with some simple styling of the dialog overlay element. First, we position the overlay on the z-axis in-between the dialog itself and the rest of the body content -

.dialog { z-index: 3; }
.dialog-overlay { z-index: 2; }
.body-content { z-index: 1; }

This is where it helps that these three elements are directly children of the <body>. Next, we need to make sure that the overlay takes up the entire viewport -

.dialog-overlay {
	position: fixed;
	top: 0;
	left: 0;
	width: 100%;
	height: 100%;
	background-color: rgba(0,0,0,0.7);
}

Finally, in our HTML, we set a tabindex of -1 on the overlay to prevent it from receiving focus.

<body>
	<div class=“body-content”></div>
	<div class=“dialog”></div>
	<div class=“dialog-overlay” tabindex="-1"></div>
<body>

5. While Open, Prevent Tabbing to Outside the Dialog #

User navigating with a keyboard should not be able toTAB out of the dialog content

Although keyboard traps are typically discouraged, modal dialogs are one scenario in which they are necessary. Because a modal visually constrains the user to the dialog window, keyboard users should have the same experience.

To achieve this, we need to intercept two situations -

If the user is tabbing forward (pressing the TAB key alone) from the last focusable element, then we need to move them to the first focusable element.
If the user is tabbing backward (pressing the SHIFT and TAB keys) from the first focusable element, then we need to move them to the last focusable element.

If there is only one focusable element, then just prevent any behaviour from occurring when the user presses the TAB key.

Dialog.prototype.handleKeyDown = function(e) {

	var Dialog = this;
	var KEY_TAB = 9;

	function handleBackwardTab() {
		if ( document.activeElement === Dialog.firstFocusableEl ) {
			e.preventDefault();
			Dialog.lastFocusableEl.focus();
		}
	}
	function handleForwardTab() {
		if ( document.activeElement === Dialog.lastFocusableEl ) {
			e.preventDefault();
			Dialog.firstFocusableEl.focus();
		}
	}

	switch(e.keyCode) {
		case KEY_TAB:
			if ( Dialog.focusableEls.length === 1 ) {
				e.preventDefault();
				break;
			}

			if ( e.shiftKey ) {
				handleBackwardTab();
			} else {
				handleForwardTab();
			}

			break;
		default:
			break;
	} // end switch


};

6. Allow the `ESC` Key to Close the Dialog #

When the dialog is open, pressing the ESC key should close it

Besides our intercept of the TAB key, all other keys should work as they normally would. This means that pressing the ESC key should close anything that is open.

We can modify the Dialog.prototype.handleKeyDown function to allow for this.

Dialog.prototype.handleKeyDown = function(e) {

	var Dialog = this;
	var KEY_TAB = 9;
    var KEY_ESC = 27;

	switch(e.keyCode) {
		case KEY_TAB:
			/* Handle if TAB key is pressed (see above) */
		case KEY_ESC:
			Dialog.close();
			break;
		default:
			break;
	} // end switch

};

Demo & Source Code #

The Background Properties

2016-07-26T00:00:00Z

As I have mentioned before, every element in the document tree is just a rectangular box. Each of these boxes has a background layer that can either be fully transparent, a colour, or an image. This background layer is controlled by 8 CSS properties (plus 1 shorthand property).

background-color #

The background-color property sets a background colour for the element. It's value can be any accepted colour value, or the transparent keyword.

.left { background-color: #ffdb3a; }
.middle { background-color: #67b3dd; }
.right { background-color: transparent; }

The background colour is drawn within the area of the box model specified by the background-clip property. If any background images are also set, the colour layer is drawn behind them. Unlike image layers which can be multiple, we can have only one colour layer for an element.

background-image #

The background-image property defines a background image (or images) for the element. It's value is typically a url to an image defined with the url() notation. A value of none can also be used, which will count as a layer, but an empty one.

.left { background-image: url('ire.png'); }
.right { background-image: none; }

We can also specify multiple background images, each separated by a comma. Each subsequent image drawn is placed behind the previous on the z-axis.

.middle {
  background-image: url('khaled.png'), url('ire.png');

  /* Other styles */
  background-repeat: no-repeat;
  background-size: 100px;
}

background-repeat #

The background-repeat property controls how a background image is tiled after it has been sized (by the background-size property) and positioned (by the background-position property).

The value for this property can be one of the following keywords - repeat-x, repeat-y, repeat, space, round, no-repeat. Besides the first two (repeat-x and repeat-y), the other values can be defined either once for both the x-axis and y-axis, or each dimension individually.

.top-outer-left { background-repeat: repeat-x; }
.top-inner-left { background-repeat: repeat-y; }
.top-inner-right { background-repeat: repeat; }
.top-outer-right { background-repeat: space; }

.bottom-outer-left { background-repeat: round; }
.bottom-inner-left { background-repeat: no-repeat; }
.bottom-inner-right { background-repeat: space repeat; }
.bottom-outer-right { background-repeat: round space; }

background-size #

The background-size property defines the size of the background image. It's value can either be a keyword, a length, or a percentage.

The keywords available for this property are contain and cover. The keyword contain will scale the image to the largest size it can be where both it's height and width can fit within the area. cover, on the other hand, will scale the image to the smallest possible size where entire background area is still covered.

.left {
  background-size: contain;
  background-image: url('ire.png');
  background-repeat: no-repeat;
}
.right { background-size: cover; /* Other styles same as .left */ }

For length values and percentage values, we can specify both the width and height of the background image. Percentage values are calculated in relation to the size of the element.

.left { background-size: 50px; /* Other styles same as .left */ }
.right { background-size: 50% 80%; /* Other styles same as .left */ }

background-attachment #

The background-attachment property controls how the background image scrolls in relation to the viewport and the element. It has three potential values.

The keyword fixed means that the background image is fixed to the viewport and does not move, even when the user is scrolling along the viewport. local means that the background should be fixed to its position in the element. If the element has a scrolling mechanism and the background image is positioned to the top, as the user scrolls down the element, the background image will scroll out of view. Finally, scroll means that the background image is fixed and will not scroll even with the contents of it's element.

.left {
  background-attachment: fixed;
  background-size: 50%;
  background-image: url('ire.png');
  background-repeat: no-repeat;
  overflow: scroll;
}
.middle { background-attachment: local; /* Other styles same as .left */ }
.right { background-attachment: scroll; /* Other styles same as .left */ }

background-position #

This property, in combination with the background-origin property, defines where the starting position for the background image should be. It's value can either be a keyword, a length, or a percentage, and we can specify the position along the x-axis as well as the y-axis.

The keywords available are top, right, bottom, left, and center. We can use these keywords in any combination, and if only one keyword is specified, the other is presumed to be center.

.top-left {
  background-position: top;
  background-size: 50%;
  background-image: url('ire.png');
  background-repeat: no-repeat;
}
.top-middle { background-position: right;  /* Other styles same as .top-left */ }
.top-right { background-position: bottom;  /* Other styles same as .top-left */ }
.bottom-left { background-position: left;  /* Other styles same as .top-left */ }
.bottom-right { background-position: center;  /* Other styles same as .top-left */ }

For length and percentage values, we can also specify the position along the x-axis and y-axis. Percentage values are in relation to the containing element.

.left { background-position: 20px 70px; /* Others same as .top-left */ }
.right { background-position: 50%; /* Others same as .top-left */ }

background-origin #

The background-origin property specifies which area of the box model the background image should be positioned according to.

The values available are border-box, which positions the image based on the Border Area, padding-box, which uses the Padding Area, and content-box, which uses the Content Area.

.left {
  background-origin: border-box;
  background-size: 50%;
  background-image: url('ire.png');
  background-repeat: no-repeat;
  background-position: top left;
  border: 10px dotted black;
  padding: 20px;
}
.middle { background-origin: padding-box;  /* Other styles same as .left*/ }
.right { background-origin: content-box;  /* Other styles same as .left*/ }

background-clip #

The background-clip property determines the background painting area, which is the area that the background can be painted onto. Like the background-origin property, it is based on the box model areas.

.left{
  background-clip: border-box;
  background-size: 50%;
  background-color: #ffdb3a;
  background-repeat: no-repeat;
  background-position: top left;
  border: 10px dotted black;
  padding: 20px;
}
.middle { background-clip: padding-box;  /* Other styles same as .left*/ }
.right { background-clip: content-box;  /* Other styles same as .left*/ }

background #

Finally, the background property is a shorthand for the other background related properties. The order of the sub-properties does not matter because the data types for each property are different . However, for the background-origin and background-clip properties, if only one box model area is specified, it is used for both properties. If two are specified, the first sets the background-origin property.

The Service Worker Lifecycle

2016-07-19T00:00:00Z

If you have worked with Service Workers, you may have run into some issues with previous Service Workers still being in control of a document, even though the file itself has been updated. The reason for this is to do with some nuances in the lifecycle of the Service Worker; it may be installed and valid, but not yet actually in control of the document.

A Service Worker can be in one of the following six states - parsed, installing, installed, activating, activated, and redundant.

Parsed #

When we first attempt to register a Service Worker, the user agent parses the script and obtains the entry point. If parsing is successful (and some other requirements, e.g. HTTPS, are met), we will have access to the Service Worker registration object. This contains information about the state of the Service Worker as well as it’s scope.

/* In main.js */
if ('serviceWorker' in navigator) {
	navigator.serviceWorker.register('./sw.js')
	.then(function(registration) {
		console.log("Service Worker Registered", registration);
	})
	.catch(function(err) {
		console.log("Service Worker Failed to Register", err);
	})
}

Successful registration of the Service Worker doesn’t mean that it has been installed yet or is active, just that the script has been successfully parsed, it is on the same origin as the document, and the origin is HTTPS. Once this is complete, the Service Worker moves on to the next state.

Installing #

Once the Service Worker script has been parsed, the user agent attempts to install it and it moves to the installing state. In the Service Worker registration object, we can check for this state in the installing child object.

/* In main.js */
navigator.serviceWorker.register('./sw.js').then(function(registration) {
    if (registration.installing) {
        // Service Worker is Installing
    }
})

During the installing state, the install event in the Service Worker script is carried out. In a typical install event, we cache the static files for the document.

/* In sw.js */
self.addEventListener('install', function(event) {
  event.waitUntil(
    caches.open(currentCacheName).then(function(cache) {
      return cache.addAll(arrayOfFilesToCache);
    })
  );
});

If there is an event.waitUntil() method in the event, the installing event will not be successful until the Promise within it is resolved. If the Promise is rejected, the install event fails and the Service Worker becomes redundant.

/* In sw.js */
self.addEventListener('install', function(event) {
  event.waitUntil(
   return Promise.reject(); // Failure
  );
});

Install Event will fail

Installed / Waiting #

If the installation is successful, the Service Worker moves to the installed (also called waiting) state. In this state it is a valid, but not yet active, worker. It is not yet in control of the document, but rather is waiting to take control from the current worker.

In the Service Worker registration object, we can check for this state in the waiting child object.

/* In main.js */
navigator.serviceWorker.register('./sw.js').then(function(registration) {
    if (registration.waiting) {
        // Service Worker is Waiting
    }
})

This can be a good time to notify the app user that they can update to a new version, or automatically update for them.

Activating #

The activating state will be triggered for a waiting Service Worker in one of the following scenarios -

If there is no current active worker already
If the self.skipWaiting() method is called in the Service Worker script
If the user has navigated away from the page, thereby releasing the previous active worker
If a specified period of time has passed, thereby releasing the previous active worker

During the activating state, the activate event in the Service Worker script is carried out. In a typical activate event, we clear files from old caches.

/* In sw.js */
self.addEventListener('activate', function(event) {
  event.waitUntil(
    // Get all the cache names
    caches.keys().then(function(cacheNames) {
      return Promise.all(
        // Get all the items that are stored under a different cache name than the current one
        cacheNames.filter(function(cacheName) {
          return cacheName != currentCacheName;
        }).map(function(cacheName) {
          // Delete the items
          return caches.delete(cacheName);
        })
      ); // end Promise.all()
    }) // end caches.keys()
  ); // end event.waitUntil()
});

Similarly to the install event, if there is an event.waitUntil() method in the activate event, activation will not be successful until the Promise is resolved. If the Promise is rejected, the activate event fails and the Service Worker becomes redundant.

Activated #

If activation is successful, the Service Worker moves to the active state. In this state, it is an active worker in full control of the document. In the Service Worker registration object, we can check for this state in the active child object.

/* In main.js */
navigator.serviceWorker.register('./sw.js').then(function(registration) {
    if (registration.active) {
        // Service Worker is Active
    }
})

When a Service Worker is active, it can now handle the functional events - fetch, and message.

/* In sw.js */

self.addEventListener('fetch', function(event) {
  // Do stuff with fetch events
});

self.addEventListener('message', function(event) {
  // Do stuff with postMessages received from document
});

Redundant #

A Service Worker can become redundant for one of the following reasons -

If the installing event failed
If the activating event failed
If a new Service Worker replaces it as the active service worker

If the Service Worker is redundant for the first two reasons, we can see it (and related information) in our Dev Tools -

If there was a previously active Service Worker, it maintains control of the document.

JavaScript Promises 101

2016-07-12T00:00:00Z

A JavaScript Promise represents the result of an operation that hasn't been completed yet, but will at some undetermined point in the future. An example of such an operation is a network request. When we fetch data from some source, for example an API, there is no way for us to absolutely determine when the response will be received.

This can be problematic if we have other operations dependent on the completion of this network request. Without Promises, we would have to use callbacks to deal with actions that need to happen in sequence. This isn't necessarily a problem if we only have one asynchronous action. But if we need to complete multiple asynchronous steps in sequence, callbacks become unmanageable and result in the infamous callback hell.

doSomething(function(responseOne) {
    doSomethingElse(responseOne, function(responseTwo, err) {
        if (err) { handleError(err); }
        doMoreStuff(responseTwo, function(responseThree, err) {
            if (err) { handleAnotherError(err); }
            doFinalThing(responseThree, function(err) {
                if (err) { handleAnotherError(err); }
                // Complete
            }); // end doFinalThing
        }); // end doMoreStuff
    }); // end doSomethingElse
}); // end doSomething

Promises provide a standardised and cleaner method of dealing with tasks that need to happen in sequence.

doSomething()
.then(doSomethingElse)
.catch(handleError)
.then(doMoreStuff)
.then(doFinalThing)
.catch(handleAnotherError)

Creating Promises #

A Promise is created using the Promise Constructor. This accepts a function with two arguments (resolve & reject) as its only parameter.

var promise = new Promise( function(resolve, reject) { /* Promise content */ } )

Within the function, we can execute whatever asynchronous task we want. To mark the promise as fulfilled, we call resolve(), optionally passing a value we want to return. To mark the promise as rejected or failed, we call reject(), optionally passing an error message. Before a promise is fulfilled or rejected, it is in a pending state.

Here is a common promise-ified version of an XMLHttpRequest -

/* CREDIT - Jake Archibald, https://www.html5rocks.com/en/tutorials/es6/promises/ */

function get(url) {
  return new Promise(function(resolve, reject) {

    var req = new XMLHttpRequest();
    req.open('GET', url);

    req.onload = function() {
      if (req.status == 200) {
          resolve(req.response); /* PROMISE RESOLVED */
      } else {
          reject(Error(req.statusText)); /* PROMISE REJECTED */
      }
    };

    req.onerror = function() { reject(Error("Network Error")); };
    req.send();
  });
}

Using Promises #

Once we have created the Promise, we need to actually use it. To execute the promise-ified function, we can call it like any regular function. But, because it is a promise, we now have access to the .then() method, which we can append to the function and which will be executed when the Promise is no longer pending.

The .then()method accepts two optional parameters. First, a function called if the promise is fulfilled. Second, a function called if the promise is rejected.

get(url)
.then(function(response) {
    /* successFunction */
}, function(err) {
    /* errorFunction */
})

Handling Errors #

Since both the success and error functions are optional, we can split them into two .then()s for better readability.

get(url)
.then(function(response) {
    /* successFunction */
}, undefined)
.then(undefined, function(err) {
    /* errorFunction */
})

To make things even more readable, we make use of the .catch() method, which is a shorthand for a .then(undefined, errorFunction).

get(url)
.then(function(response) {
    /* successFunction */
})
.catch(function(err) {
    /* errorFunction */
})

Chaining #

The real value in promises is when we have multiple asynchronous functions we need to execute in order. We can chain .then() and .catch() together to create a sequence of asynchronous functions.

We do this by returning another promise within a success or error function. For example -

get(url)
.then(function(response) {
    response = JSON.parse(response);
    var secondURL = response.data.url
    return get( secondURL ); /* Return another Promise */
})
.then(function(response) {
    response = JSON.parse(response);
    var thirdURL = response.data.url
    return get( thirdURL ); /* Return another Promise */
})
.catch(function(err) {
    handleError(err);
});

If a promise within the chain resolved, it will move on to the next success function (.then()) in the sequence. If, on the other hand, a promise rejected, it will jump to the next error function (.catch()) in the sequence.

Executing Promises in Parallel #

There may be cases where we want to execute a bunch of promise-ified functions in parallel, and then perform an action only when all the promises have been fulfilled. For example, if we want to fetch a bunch of images and display them on the page.

To do this, we need to make use of two methods. First, the Array.map() method allows us to perform an action on each item in an array, and creates a new array of the results of these actions.

Second, the Promise.all() method returns a promise that is only resolved when every promise within an array is resolved. If any single promise within the array is rejected, the Promise.all() promise is also rejected.

var arrayOfURLs = ['one.json', 'two.json', 'three.json', 'four.json'];
var arrayOfPromises = arrayOfURLs.map(get);

Promise.all(arrayOfPromises)
.then(function(arrayOfResults) {
    /* Do something when all Promises are resolved */
})
.catch(function(err) {
    /* Handle error is any of Promises fails */
})

If we look at the Network panel in our Development tools, we can see that all the fetch requests are happening in parallel.

Support #

If you have to support Internet Explorer or Opera Mini, you can make use of this Promise Polyfill.

The :target Trick

2016-07-05T00:00:00Z

The :target pseudo-class refers to an element within the document that the URL’s fragment points to. For example, this piece of text is wrapped in a <mark> element which has an ID of #target-test. If you went to the url, GHOST_URL/the-target-trick#target-test, then that element will be the target and and styles applied to the :target pseudo-class for that element will take effect.

Last year, I wrote about the :target pseudo-class in my article on 5 Lesser Used CSS Selectors (and some use cases for them). The example I mentioned for the :target pseudo-class was to highlight the section of the page that is being referenced. For example, adding a background colour or border to it like in the example above.

But it recently occurred to me that we can use the :target pseudo-element in a much more useful way, to create interactive elements on the page without needing javascript.

Example 1 - Hiding & Showing Content #

A simple use case for the :target pseudo-class is just to hide and show the content targeted. In a blog, for example, we may not want to display the comments section until the user clicks to show them. To achieve this we can simply hide the element unless it is a :target.

<a href="#comments">Show Comments</a>

<section id="comments">
	<h3>Comments</h3>
	<!-- Comments here... -->
	<a href="#">Hide Comments</a>
</section>

#comments:not(:target) {
	display: none;
}
#comments:target {
	display: block;
}

View Live Demo

Another use case is in creating a slide-out navigation drawer. We can fix the navigation drawer relative to the viewport to ensure that there will be no jumping around when the user clicks to open.

#nav {
	position: fixed;
	top: 0;
    height: 100%;
	width: 80%;
	max-width: 400px;
}

#nav:not(:target) {
	right: -100%;
	transition: right 1.5s;
}

#nav:target {
	right: 0;
	transition: right 1s;
}

View Live Demo

Taking this further, we can create a modal that will fill the entire page.

#modal-container {
	position: fixed;
	top: 0;
	left: 0;
	width: 100%;
	height: 100%;
	background: rgba(0,0,0,0.8);
	display: flex;
	justify-content: center;
	align-items: center;
}

.modal {
	width: 70%;
	background: #fff;
	padding: 20px;
	text-align: center;
}

#modal-container:not(:target) {
	opacity: 0;
	visibility: hidden;
	transition: opacity 1s, visibility 1s;
}

#modal-container:target {
	opacity: 1;
	visibility: visible;
	transition: opacity 1s, visibility 1s;
}

View Live Demo

Example 4 - Changing Global Styles #

A final use case, although a less semantically-proper one, could be to apply :target to the <body> element itself, and completely restyle the page or alter its layout.

#body:not(:target) {
	main { width: 60%; }
	aside { width: 30%; }
	.show-sidebar-link { display: none; }
}

#body:target {
	main { width: 100%; }
	aside { display: none; }
	.hide-sidebar-link { display: none; }
}

View Live Demo

Is this Semantic and Accessible? #

As I mentioned in Anchors vs Buttons, when an <a> element is used, the browser expects that the user be navigated to a different page or a different section within the page. In these examples (except the last one), that is essentially what is happening. The only trick is that the target element is being styled so it is hidden and shown dynamically.

As far as I can tell, there are two potential issues with this method -

There is a change in the URL, which affects the user's browsing history. This means that if the user goes "back", they may be unintentionally navigated to the target element.
To "close" the target element, the user needs to be navigated to either another element or just a #. The latter, which I have used in my examples, is not the most semantic and will cause the user to jump to the top of the page if they aren't there already.

Nonetheless, if used correctly, I think this method can still be at least a fallback to provide interaction for users if JavaScript is not an option. In some cases, like in my first example, it can even be preferable to and simpler than using JavaScript. As always, it depends on the scenario.

All the Generic CSS Data Types

2016-06-28T00:00:00Z

Values for properties in CSS can be in a number of formats. In order for a user agent to be able to determine if a value is valid, it needs to make sure it conforms to one of the speicfic types of values. These are called data types, and are typically written in the specs like <this>.

There are two kinds of data types - specific and generic. Specific data types are related a single property or a small group of properties. For example, the <transform-function> data type is used as the value for the transform property alone.

Generic data types, on the other hand, are not related to any specific property. For example we can have a value of 10px, which is a <length> data type, for the margin, font-size or a number of other propertes.

In this article, I'm going to give an overview of all the generic data types.

Category	Name	Type
Textual	Keywords	`<ident>`
Custom Keywords	`<custom-ident>`
Quoted Strings	`<string>`
Resource Locators	`<url>`
Basic Numeric	Integers	`<integer>`
Real Numbers	`<number>`
Ratios	`<ratio>`
Percentages	`<percentage>`
Dimensions	Distances	`<length>`
Angles	`<angle>`
Duration	`<duration>`
Frequency	`<frequency>`
Resolution	`<resolution>`
Other	Colours	`<color>`
Images	`<image>`
Position	`<position>`

Textual Data Types #

Keywords #

The <ident> data type refers to the pre-defined keywords in CSS. This includes both the unique values for certain properties, for example block for the display property, as well as the CSS-wide values initial, inherit and unset (See Initial, Inherit, Unset, and Revert).

.foo {
  border-color: red;
  position: inherit;
}

These keywords are case-insensitive and must always be written without quotes, less they be misinterpreted as the <string> data type.

Custom Keywords #

The <custom-ident> (also referred to as <user-ident>) data type refers to keywords that have been defined by the author of the stylesheet. There are restrictions as to what can be a valid <custom-ident>, for example it cannot be one of the CSS-wide values.

A common example of a custom keyword is the value for the animation-name property. This property can accept as its value the name of a custom animation, as defined by the stylesheet author.

@keyframes hulkify { 
  from {
    color: pink;
    transform: scale(1);
  } 
  to {
    color: green;
    transform: scale(2);
  } 
}
.bruce-banner { animation-name: hulkify; }

Quoted Strings #

The <string> data type refers to any quoted string. The text within the quotes can be any sequence of Unicode characters.

.foo::after {
  content: "Hello, world!";
}
.foo::before {
  content: "We can add 'quotes' within quotes \A And move to a separate line";
}

Resource Locators #

The <url> data type is used to reference a resource file or fragment. This data type is typically written using the url() function, but can be represented as a <string> in some cases, notably with the @import rule.

There are three types of URLs that can be used with this data type -

Absolute URLs are those that specify a protocol and domain. The resource these URLs direct to are not necessarily in the same domain as the stylesheet they are referred from.
Relative URLs are those that are refer to a file using the referring stylesheet's location as the base location.
Fragment URLs are used to refer to elements in the host document itself. The reference is the ID of the element, not a path to a file.

 /* Absolute URL */
@import url("https://fonts.googleapis.com/css?family=Source+Sans+Pro:400");

 /* Realtive URL */
.foo { background-image: url("../img/bg.png"); }
@import "components/buttons.css";

 /* Fragment URL */
.bar { filter: url("#blurFilter"); }

Basic Numeric Data Types #

Integers #

An <integer> data type is the same as an integer as defined mathematically. It is a whole number, i.e. not a fraction, and can be position or negative. The first digit may be preceded by a - or + to indicate it's sign, although a + is implied if nothing is specified.

.foo { z-index: 10; }
.foo { z-index: +10; }
.bar { z-index: -10; }

Real Numbers #

The <number> data type is a "real number". It can be an <integer>, 0, or a fraction written as a decimal. Like integers, real numbers can be positive or negative, as indicated by a sign preceding the first digit.

.foo { line-height: 3; }
.bar { line-height: -2.5; }
.foo { line-height: +5.5; }

Ratios #

The <ratio> data type specifies a relationship between two numbers, specifically two positive <integer>s. Although ratios can be written in different ways in mathematics, in CSS they are always written as <integer> / <integer>.

Ratio data types are typically used in media queries to target device aspect ratios.

@media screen and (device-aspect-ratio: 16/9) { /* Wide screen displays, iPhone 5 */ }
@media screen and (device-aspect-ratio: 4/3) { … }

Percentages #

The <percentage> data type is made up of a <number> followed by a % sign. It represents a value that is a fraction of some other value with it's own data type. Therefore, we can have different kinds of the percentage data type, depending on what data type the value is.

The <length-percentage> data type represents a fraction of a <length> value.
The <number-percentage> data type represents a fraction of a <number> value.
The <angle-percentage> data type represents a fraction of a <angle> value.
The <time-percentage> data type represents a fraction of a <time> value.
The <frequency-percentage> data type represents a fraction of a <frequency> value.

.foo {
	width: 50%; /* <length-percentage> */
	line-height: 200% /* <number-percentage> */
	voice-pitch: 25% /* <frequency-percentage> */
}

Dimensional Data Types #

Dimensions are numeric data types, specifically <number>s, but qualified by a unit of measurement. They are written as a <number> followed by the unit identifier. When the <number> is 0, however, it can be written without it's unit.

Distances #

The <length> data type represents units of distance. There are two types of length units.

Absolute units, for example px, cm, and pt, are fixed and (mostly) relate to some physical measurement. Once they are declared, their size cannot be altered by changing the font size of a containing element.
Relative units, for example em, rem, and the viewport units, do not have an objective measurement. Instead, their actual size is determined by the size of a parent element. This means that their size can be altered by changing the sizing of that dependent element.

(See CSS Font Sizing)

.foo {
	font-size: 16px; /* absolute */
	width: 50vw; /* relative */
}

Angles #

The <angle> data type represents an angle of a circle. There are four units we can use to define this angular dimension.

Thedeg unit represents the angle in Degrees. There are 360 degrees in a full circle.
Thegrad unit represents the angle in Gradians. There are 400 gradians in a full circle.
Therad unit represents the angle in Radians. There are 2πrad in a full circle (roughly 57.29rad).
Theturn unit represents the angle in Turns. There is 1 turn in a full circle.

These units can be positive or negative, denoting if the turn is happening clockwise or anti-clockwise, respectively. Below is an example of how a 90 degrees clockwise turn can be written in each of these units.

.foo {
    /* Going clockwise */
	transform: rotate(90deg);
	transform: rotate(100grad);
	transform: rotate(0.25turn);
	transform: rotate(1.57rad);

	/* Going anti-clockwise */
	transform: rotate(-270deg);
	transform: rotate(-300grad);
	transform: rotate(-1.25turn);
	transform: rotate(-55.72rad);
}

Duration #

The <time> data type represents a unit of time. There are two units we can use to define duration.

The s unit represents a Second.
The ms units represents a Millisecond. There are 1000 milliseconds in one second.

.foo { transition-duration: 1s; }
.bar { transition-duration: 1000ms; }

Frequency #

The <frequency> data type represents the sound frequency. There are two units we can use to define frequency.

The kHz unit represents a KiloHertz.
The Hz units represents a Hertz. There are 1000 KiloHertz in one Hertz.

.foo { voice-pitch: 250Hz; }
.bar { voice-pitch: 1kHz; }

Resolution #

The <resolution> data type represents resolution of the user's current device. The resolution itself is the size of a single "dot". The size of this dot is calculated by indicating how many of them will fit in a CSS inch, centemetre, or pixel. Depending on which CSS unit we are using, we can specify resolution in one of four units.

The dpi unit represents a represents how many dots will fit in a CSS Inch.
The dpcm unit represents a represents how many dots will fit in a CSS Centemetre.
The dppx unit represents a represents how many dots will fit in a CSS Pixel.

@media (min-resolution: 100ddpx) { .. }
@media (min-resolution: 100dpcm) { .. }
@media (min-resolution: 300dpi) { /* Retina display */ }

Other Data Types #

Colours #

The <color> data type is used to define a colour value. The data type can be one of two formats.

A keyword, which can either one of the pre-defined colours (e.g. cornflowerblue), the transparent keyword, or the currentColor keyword.
A numeric value using one of the colour notations; #rgb``rgb(), rgba(), hsl(), hsla().

Below is an example of how we can achieve the colour black using these different formats.

.foo {
   color: black;
   color: #000;
   color: rgb(0,0,0);
   color: rgba(0,0,0,1);
   color: hsl(0,0%,0%);
   color: hsla(0,0%,0%, 1);
}

Images #

The <image> data type represents a 2D image. It can be one of three formats.

A URL reference, specified using the <url> data type.
An element in the document, using the element() function. (Note - This function is has very limited support).
A gradient function, using the <gradient> data type.

.foo { background-image: url('path/to/bg.png'); }
.bar { background-image: element('#background'); }
.baz { background-image: linear-gradient(white, gray); }

Position #

The <position> data type denotes the position of an element within a containing area or element. It can be one of three other data types -

A keyword of either top, right, bottom, left, or center.
A length value.
A percentage, specifically <length-percentage>, value.

Below is an example of how to achieve getting a background image (100x100px) to be positioned in the bottom right hand corner of it's container (300x300px) -

.foo {
  background-position: right bottom;
  background-position: 200px 200px;
  background-position: 100% 100%;
}

Realtime Form Validation

2016-06-21T00:00:00Z

Last week, I went over some Techniques for Form Validation, including using CSS for visual feedback as well as the Constraint Validation API. I also discussed the benefits of validating inputs in realtime, and so this week I built out this simple registration form, demonstrating realtime validation.

View Live Demo

There are three key features of this form -

The requirements for each input are clearly displayed even before the user starts typing
As the user starts typing on the field and fulfils each requirement, they are given real time feedback on their success (or failings)
The feedback is presented in such a way that the user will not submit the form without knowing of the errors in their input

If you'd like to see a walkthrough of how I built this out, you can watch the video below.

And here is the JavaScript behind the realtime validation -

/* ----------------------------

	CustomValidation prototype

	- Keeps track of the list of invalidity messages for this input
	- Keeps track of what validity checks need to be performed for this input
	- Performs the validity checks and sends feedback to the front end

---------------------------- */

function CustomValidation() {
	this.invalidities = [];
	this.validityChecks = [];
}

CustomValidation.prototype = {
	addInvalidity: function(message) {
		this.invalidities.push(message);
	},
	getInvalidities: function() {
		return this.invalidities.join('. \n');
	},
	checkValidity: function(input) {
		for ( var i = 0; i < this.validityChecks.length; i++ ) {

			var isInvalid = this.validityChecks[i].isInvalid(input);
			if (isInvalid) {
				this.addInvalidity(this.validityChecks[i].invalidityMessage);
			}

			var requirementElement = this.validityChecks[i].element;
			if (requirementElement) {
				if (isInvalid) {
					requirementElement.classList.add('invalid');
					requirementElement.classList.remove('valid');
				} else {
					requirementElement.classList.remove('invalid');
					requirementElement.classList.add('valid');
				}

			} // end if requirementElement
		} // end for
	}
};



/* ----------------------------

	Validity Checks

	The arrays of validity checks for each input
	Comprised of three things
		1. isInvalid() - the function to determine if the input fulfills a particular requirement
		2. invalidityMessage - the error message to display if the field is invalid
		3. element - The element that states the requirement

---------------------------- */

var usernameValidityChecks = [
	{
		isInvalid: function(input) {
			return input.value.length < 3;
		},
		invalidityMessage: 'This input needs to be at least 3 characters',
		element: document.querySelector('label[for="username"] .input-requirements li:nth-child(1)')
	},
	{
		isInvalid: function(input) {
			var illegalCharacters = input.value.match(/[^a-zA-Z0-9]/g);
			return illegalCharacters ? true : false;
		},
		invalidityMessage: 'Only letters and numbers are allowed',
		element: document.querySelector('label[for="username"] .input-requirements li:nth-child(2)')
	}
];

var passwordValidityChecks = [
	{
		isInvalid: function(input) {
			return input.value.length < 8 | input.value.length > 100;
		},
		invalidityMessage: 'This input needs to be between 8 and 100 characters',
		element: document.querySelector('label[for="password"] .input-requirements li:nth-child(1)')
	},
	{
		isInvalid: function(input) {
			return !input.value.match(/[0-9]/g);
		},
		invalidityMessage: 'At least 1 number is required',
		element: document.querySelector('label[for="password"] .input-requirements li:nth-child(2)')
	},
	{
		isInvalid: function(input) {
			return !input.value.match(/[a-z]/g);
		},
		invalidityMessage: 'At least 1 lowercase letter is required',
		element: document.querySelector('label[for="password"] .input-requirements li:nth-child(3)')
	},
	{
		isInvalid: function(input) {
			return !input.value.match(/[A-Z]/g);
		},
		invalidityMessage: 'At least 1 uppercase letter is required',
		element: document.querySelector('label[for="password"] .input-requirements li:nth-child(4)')
	},
	{
		isInvalid: function(input) {
			return !input.value.match(/[\!\@\#\$\%\^\&\*]/g);
		},
		invalidityMessage: 'You need one of the required special characters',
		element: document.querySelector('label[for="password"] .input-requirements li:nth-child(5)')
	}
];

var passwordRepeatValidityChecks = [
	{
		isInvalid: function() {
			return passwordRepeatInput.value != passwordInput.value;
		},
		invalidityMessage: 'This password needs to match the first one'
	}
];



/* ----------------------------

	Check this input

	Function to check this particular input
	If input is invalid, use setCustomValidity() to pass a message to be displayed

---------------------------- */

function checkInput(input) {

	input.CustomValidation.invalidities = [];
	input.CustomValidation.checkValidity(input);

	if ( input.CustomValidation.invalidities.length == 0 && input.value != '' ) {
		input.setCustomValidity('');
	} else {
		var message = input.CustomValidation.getInvalidities();
		input.setCustomValidity(message);
	}
}



/* ----------------------------

	Setup CustomValidation

	Setup the CustomValidation prototype for each input
	Also sets which array of validity checks to use for that input

---------------------------- */

var usernameInput = document.getElementById('username');
var passwordInput = document.getElementById('password');
var passwordRepeatInput = document.getElementById('password_repeat');

usernameInput.CustomValidation = new CustomValidation();
usernameInput.CustomValidation.validityChecks = usernameValidityChecks;

passwordInput.CustomValidation = new CustomValidation();
passwordInput.CustomValidation.validityChecks = passwordValidityChecks;

passwordRepeatInput.CustomValidation = new CustomValidation();
passwordRepeatInput.CustomValidation.validityChecks = passwordRepeatValidityChecks;




/* ----------------------------

	Event Listeners

---------------------------- */

var inputs = document.querySelectorAll('input:not([type="submit"])');
var submit = document.querySelector('input[type="submit"');

for (var i = 0; i < inputs.length; i++) {
	inputs[i].addEventListener('keyup', function() {
		checkInput(this);
	});
}

submit.addEventListener('click', function() {
	for (var i = 0; i < inputs.length; i++) {
		checkInput(inputs[i]);
	}
});

Full Source Code | Live Demo

As always, there are improvements that can be made and since I built and recorded this I've already had some ideas for how to improve the form. For example -

Give feedback when a user focuses out of an invalid input
Use a custom tooltip in place of the in-built browser tooltips for more consistent and reliable behaviour across browsers

If you have more ideas, or feedback on the implementation, do leave a comment below.

Form Validation Techniques

2016-06-14T00:00:00Z

We all know that online forms can be a hassle to have to fill out. Especially when there is nothing but a list of inputs presented without much guidance or feedback. But as form creators, there are many things we can do to improve the experience for the users filling out forms online.

Using CSS #

Using CSS, we have access to four states of a form input with pseudo-classes - :valid, :invalid, :required and :optional. We can use these states to provide some - albeit limited - feedback to users as they fill out the form.

Using :valid and :invalid, we can let users know, in real time, if their input satisfies all the requirements necessary.

input:valid { border-color: green; }
input:invalid { border-color: red; }

One problem with using this method, however, is that the styles are applied even before the user starts to act on the form. For required inputs, they will show us as :invalid, and optional inputs will show as :valid. This means that before the user is even given the chance to start, they may already be given negative feedback, which isn’t a great experience.

Styling :required and :optional states alone is typically not very useful either as this is information that is usually given in a label. However, we may want to combine these states with the :valid/:invalid pseudo-classes and only style certain combinations. For example, we may want to only give positive feedback when a required input is valid.

input:required:valid { border-color: green; }

Using JavaScript #

Using JavaScript, we can create a much better user experience when filling out forms. For example, consider these three number inputs, each of them requiring a minimum value of 10, a maximum of 100, and a step of 10.

<form>
    <label>
        Number Input 1
	 <input type="number" min="10" max="100" step="10">
    </label>
    <label>
        Number Input 2
	 <input type="number" min="10" max="100" step="10">
    </label>
    <label>
        Number Input 3
	 <input type="number" min="10" max="100" step="10">
    </label>

    <input type="submit">
</form>

By setting the min, max and step attributes, we can control the number the user inputs only if they use the controls on the input element. However, this doesn’t stop the user from manually typing in invalid numbers. If they type in 1, 12, and 123 respectively to the three inputs and submits the form, this is what happens -

What happens is the user only gets an error message for the first input and they only get one error message, even though the input violates 2 of the requirements. We can fix this by modifying the validity message being passed.

When validating inputs, the browser does checks for a defined list of potential invalidites. There is an object, validity, that is attached to all inputs. It contains a list of keys with boolean values, each checking if a certain type of invalidity applies to this input. For example, this is the validity object returned when the user inputs 1 on the previous input.

input.validity = {
    valid:false // If the input is valid
    customError:false // If a custom error message has been set
    patternMismatch:false // If the invalidity is against the pattern attribute
    rangeOverflow:false // If the invalidity is against the max attribute
    rangeUnderflow:true // If the invalidity is against the min attribute
    stepMismatch:true // If the invalidity is against the step attribute
    tooLong:false // If the invalidity is against the maxlength attribute
    tooShort:false // If the invalidity is against the minlength attribute
    typeMismatch:false // If the invalidity is against the type attribute
    valueMissing:false // If the input is required but empty
}

By default, the browser will only display one of these invalidities. So what we can do instead is check each of these values ourselves and, if we find an invalidity, store it. Once we have stored all the invalidity messages for an input, we can then set the whole list as a custom validity message using the setCustomValidity() function.

function CustomValidation() { }
CustomValidation.prototype = {
	// Set default empty array of invalidity messages
	invalidities: [],

	// Function to check validity
	checkValidity: function(input) {

		var validity = input.validity;

		if ( validity.patternMismatch ) {
			this.addInvalidity('This is the wrong pattern for this field');
		}
		if ( validity.rangeOverflow ) {
			var max = getAttributeValue(input, 'max');
			this.addInvalidity('The maximum value should be ' + max);
		}
		if ( validity.rangeUnderflow ) {
			var min = getAttributeValue(input, 'min');
			this.addInvalidity('The minimum value should be ' + min);
		}
		if ( validity.stepMismatch ) {
			var step = getAttributeValue(input, 'step');
			this.addInvalidity('This number needs to be a multiple of ' + step);
		}
		// Additional validity checks here...
	},

	// Add invalidity message to invalidities object
	addInvalidity: function(message) {
		this.invalidities.push(message);
	},

	// Retrieve the invalidity messages
	getInvalidities: function() {
		return this.invalidities.join('. \n');
	}
};

// On click of form submit buttons
submit.addEventListener('click', function(e) {
    // Loop through all inputs
	for ( var i = 0; i < inputs.length; i++ ) {

		var input = inputs[i];

		// Use native JavaScript checkValidity() function to check if input is valid
		if ( input.checkValidity() == false ) {

            var inputCustomValidation = new CustomValidation(); // New instance of CustomValidation
			inputCustomValidation.checkValidity(input); // Check Invalidities
			var customValidityMessage = inputCustomValidation.getInvalidities(); // Get custom invalidity messages
			input.setCustomValidity( customValidityMessage ); // set as custom validity message

		} // end if
	} // end loop
});

Doing, this, when the form from above is submitted again, this is what happens -

This is better, because all the error messages for that input are now being displayed. However, we still have the problem that only the error message for the first input is being displayed.

This is a limitation of the native browser validation message. So, we need to find an alternative.

Displaying all error messages for all inputs #

Instead of using the built-in tooltip, we can add the error messages to the DOM directly. This way, all the error messages for each input will be clearly displayed next to them.

We can do this very simply with a couple of additional lines -

CustomValidation.prototype.getInvaliditiesForHTML = function() {
    return this.invalidities.join('. <br>');
}

// On click of form submit buttons
submit.addEventListener('click', function(e) {
    // Loop through all inputs
	for ( var i = 0; i < inputs.length; i++ ) {

		var input = inputs[i];

		// Use native JavaScript checkValidity() function to check if input is valid
		if ( input.checkValidity() == false ) {

            var inputCustomValidation = new CustomValidation(); // New instance of CustomValidation
			inputCustomValidation.checkValidity(input); // Check Invalidities
			var customValidityMessage = inputCustomValidation.getInvalidities(); // Get custom invalidity messages
			input.setCustomValidity( customValidityMessage ); // set as custom validity message

			// DISPLAY ERROR MESSAGES IN DOCUMENT
			var customValidityMessageForHTML = inputCustomValidation.getInvaliditiesForHTML();
		    input.insertAdjacentHTML('afterend', '<p class="error-message">' + customValidityMessageForHTML + '</p>')
			stopSubmit = true;

		} // end if
	} // end loop
    if ( stopSubmit ) { e.preventDefault(); }
});

Now, this is what happens when the user clicks submit -

Using custom validation checks #

Sometimes, the validation checks available in the browser may not be enough. We may want to check the inputted value against some custom requirements, for example if a text input requires special characters.

Since we are already checking for each validity message separately in our CustomValidation.prototype.checkValidity function, we can easily add additional checks here as well.

CustomValidation.prototype.checkValidity = function(input) {

    // In-built validity checks here ------

    // Custom Validity checks ------
    if ( !input.value.match(/[a-z]/g) ) {
    	this.addInvalidity('At least 1 lowercase letter is required');
    }
    if ( !input.value.match(/[A-Z]/g) ) {
	this.addInvalidity('At least 1 uppercase letter is required');
    }
}

Realtime validation #

Although this is a lot better, it is not without its flaws, the biggest being that the user has to submit the form before they get any specific feedback on what exactly is wrong with their inputs. However, the best user experience for forms is when validation happens in real time. There are three parts to this -

The requirements for each input are clearly displayed even before the user starts typing
As the user starts typing on the field and fulfils each requirement, they are given real time feedback on their success (or failings)
The feedback is presented in such a way that the user will not submit the form without knowing of the errors in their input

In next week's article (see here), I'm going to show how I implement real-time validation, by recreating this simple registration form -

If you'd like to try recreating this (or a better version) yourself before then, you can use this boilerplate code.

Anchors vs Buttons

2016-06-05T00:00:00Z

For the longest time, web developers (myself included) have been using <a>s, <div>s, <span>s, and everything but <button>s to create interactive clickable elements. It would typically go something like this -

<a href="#" role="button" onclick="openMenuModal();">Navigation</a>

Don't do this

A non-actionable or meaningless href is applied to the anchor element so that the user isn't navigated away from the page, and JavaScript is used to hijack the click event for the link. But there's actually an HTML element for this behaviour - the <button>, more specifically the <button type=“button”>, element.

<button type="button" onclick="openMenuModal();">Navigation</button>

Despite this, the anchor element is still used to initiate interactions on a page and in many or most cases, this is simply incorrect. However, the button element is not perfect itself and there are some cases in which I think using the anchor tag is still appropriate. To understand how and why, let's first get into the difference between anchors and buttons.

What’s the Difference? #

Visually, the <a> and <button type=“button”> elements can look identical if styled correctly. Semantically, on the other hand, they come with different repercussions, particularly for users who aren't interacting with the element through the simple point-and-click.

The Anchor Element #

The <a> element represents a hyperlink to a destination page or a section within a page. The element is labelled by its contents, which can be anything from an image to additional (non-interactive) elements like <div>s, <p>s, etc.

Because the <a> element is related to a link, the css pseudo-classes :link and :visited are available to it. This is in addition to the user-action pseudo-classes :hover, :active and :focus.

When navigating with a keyboard, the anchor element can be “clicked” by pressing the enter key. To screen readers, when an anchor tag is clicked, it is expected that the user be navigated away to another page or section.

The Button Element #

The <button> element, more specifically the <button type=“button”> element, does nothing. Unlike other button types, such as the <button type=“reset”> which resets the form it is nested within, the <button type=“button”> does not have any default behaviour.

Because no link is related to the element, only the default user-action pseudo-classes (:hover, :active and :focus) are available to it. Nowadays, it can be styled as easily and extensively as an anchor element.

When navigating with a keyboard, the button element can be “clicked” by pressing either the enter or space keys, the latter being more commonly used. To screen readers, when a button is clicked, it is expected that JavaScript be used to create some interaction on the page. Some screen readers will announce the element as a button, and speech recognition software should enable the button to be clicked by saying "click".

What's the Problem? #

The Problem with Buttons #

First, let me re-iterate the point that if your HTML looks like this ...

<a href="#" role="button" onclick="openMenuModal();">Navigation</a>

Don't do this

...you should probably use a button instead.

However, in some cases, using the button element alone isn't necessarily the most suitable solution either.

The <button type=“button”> element, as mentioned, by default does nothing. JavaScript must be used to add functionality to it. Therefore, if the user doesn’t have JavaScript enabled on their device, then they can no longer access the content behind the interaction, in this case the navigation menu.

Although we have done right by screen reader users by using semantic markup, we have neglected users who can't/don't enable JavaScript by putting a critical user interaction behind this wall.

The Problem with Anchors #

A common solution to the problem with the button element is to use the anchor element instead, but modify it in two ways -

Provide a meaningful fallback link in the href attribute; and
Alter the semantics of the anchor element so it looks and behaves like a button to screen readers

For example, the anchor-button will look like this -

<a href="#navigation-alternative" role="button" onclick="openMenu();">Navigation</a>

This way, if a user does not have JavaScript enabled they can still access the contents of the modal further down the page. Additionally, because the button element is typically "clicked" with the space key, we can also bind that event to the anchor-button element.

var bindSpaceKey = function(anchor) {
	anchor.addEventListener('keyup', function(event) {
		if (event.keyCode == 32) { anchor.click(); }
	})
}
var anchorButtons = document.querySelectorAll('a[role="button"]');
for ( var i = 0; i < anchorButtons.length; i++ ) {
	bindSpaceKey( anchorButtons[i] );
}

Even though, in my opinion, this solution is better than using a simple button, it isn't perfect either. First, if JavaScript is not enabled then the anchor element should semantically be a link, not a button. But, since we added the button role, it appears to be a button to screen readers even in this case when it is not.

Second, even though we have added the button role, I'm not entirely convinced that this makes the element exactly the same as though it were an actual button. Even though user agents and screen readers should treat it as a button, there is not guarantee that they do.

What's the Solution? #

We have a dilemma.

The <button> is semantically correct, but not progressively enhancive, and the <a> is progressively enhancive but not semantically correct.

Therefore, the only solution I see is to change the element used based on the circumstance. If we are going to have to use JavaScript to bind the space key event to an <a role="button">, we might as well go all the way for semantic consistency. When there is no Javascript, the element remains as a regular link semantically. But when there is Javascript, the anchor element is swapped for a button element instead.

Here's how it would work. The element defined in the markup will be a regular link, unmodified.

<a href="#navigation-alternative" class="anchorButton">Navigation</a>

If Javascript is enabled, we can then change all the anchor elements to buttons.

var changeAnchorToButton = function(anchor) {

	// Create button element with same content and attributes as anchor
	var button = document.createElement('button');
    button.setAttribute('type', 'button');
	button.innerHTML = anchor.innerHTML;
	button.id = anchor.id;
	for ( var i = 0; i < anchor.classList.length; i++ ) {
		button.classList.add(anchor.classList[i]);
	}

	// Change anchor element to button element
	var anchorParent = anchor.parentNode;
	anchorParent.replaceChild(button, anchor);
}
var anchorButtons = document.getElementsByClassName('anchorButton');
for ( var i = 0; i < anchorButtons.length; i++ ) {
	changeAnchorToButton( anchorButtons[i] );
}

We can style the .anchorButton element so both the<a> and <button> look the same visually -

.anchorButton {
  /* Resets */
  font-family: sans-serif;
  font-size: 16px;
  color: #000;
  border: 1px solid #000;
  border-radius: 0;
  background-color: transparent;

  margin: 0;
  padding: 0;
  height: auto;
  width: auto;
  cursor: pointer;

  /* More styles... */
}
a.anchorButton {
  /* Styles for when it's an <a> */
  text-decoration: none;
}
button.anchorButton {
  /* Styles for when it's a <button> */
  -webkit-appearance: none;
  -moz-appearance: none;
}

Although this may be a bit radical, it's the only solution I could come up with that works visually, semantically, and accessibility-wise. And, if we style the .anchorButton element correctly, adding this snippet shouldn't affect the visual look of the page at all.

Making Messenger Hunt - An Introduction to Messenger Bots

2016-05-31T00:00:00Z

Since Facebook announced the introduction of bots on Messenger, I knew I had to try making one myself (as I'm a bit obsessed with the idea of bots). So, I decided to make Messenger Hunt, a Messenger bot for Product Hunt.

Message the Bot | Source Code

Here is how I worked with the Messenger API to create the bot. This article if going to be a bit similar to my "An Introduction to Slack Bots" as I'm using the same framework, Botkit to develop it.

The Setup #

The setup process for Messenger Bots can be a bit complicated. Because the Messenger API requires a callback URL hosted on a secure server, we can't work locally alone. We have to start live. I use (and recommend) BeepBoop for hosting bots. They are really easy to use and reliable. These are the steps to setting up a new Messenger bot being hosted through BeepBoop.

Step 1. Create a new Node.js (with Botkit) project. Here is a simple boilerplate code to get started -

var Botkit = require('botkit')

var accessToken = process.env.FACEBOOK_PAGE_ACCESS_TOKEN
var verifyToken = process.env.FACEBOOK_VERIFY_TOKEN
var port = process.env.PORT

if (!accessToken) throw new Error('FACEBOOK_PAGE_ACCESS_TOKEN is required but missing')
if (!verifyToken) throw new Error('FACEBOOK_VERIFY_TOKEN is required but missing')
if (!port) throw new Error('PORT is required but missing')

var controller = Botkit.facebookbot({
  access_token: accessToken,
  verify_token: verifyToken
})

var bot = controller.spawn()

controller.setupWebserver(port, function (err, webserver) {
  if (err) return console.log(err)
  controller.createWebhookEndpoints(webserver, bot, function () {
    console.log('Ready')
  })
})

Step 2. Push to a Github repository and connect with BeepBoop. If you don't already have an account with BeepBoop you'll need to create one.

Step 3. Enable the bot as a Facebook Messenger bot in BeepBoop's Project Settings.

Step 4. Generate a random key to use as the Verify Token (you can use the Random Key Generator) and paste it under the bot project settings.

Step 5. Get the Base Callback URL from the project settings. Note that this is only the base, the actual callback URL we will give to facebook will have the suffix /facebook/receive.

Step 6. Create a new Facebook Page, or use an existing one. This is the page where people will interact with your bot.

Step 7. Create a new Facebook Application.

Step 8.. Enable "Messenger" for the application. You can find this under "Product Settings".

Step 9. Setup a New Webhook using the Callback Url from BeepBoop (step 5) and the Verify Token (step 4). Make sure to subscribe to the four fields needed (message_deliveries, messages, messaging_optins, messaging_postbacks).

Step 10. Under the "Messenger" section, generate an Access Token for the Page and save it under the BeepBoop project settings.

Step 11. Restart the bot.

Listening for Events and Keywords #

Next, we can start having the bot interact with users. Similar to Slack bots, a Messenger bot can respond to events that happen, e.g. when a user clicks a Send-to-Messenger button, or to specific keywords.

Listening for Events #

There are four events a Messenger bot can listen for -

message_received - When a user sends a message to the bot
facebook_postback - When a user clicks a postback button provided by the bot
message_delivered - When it is confirmed that the user has received a message sent by the bot
facebook_optin - When a user clicks a Send-to-Messenger button

Using this, we can send a welcome message when a user first adds the bot to Messenger -

controller.on("facebook_optin", function(bot, message) {
   // Send welcome message
})

We can also listen for postbacks triggered when a user clicks a button -

controller.on('facebook_postback', function (bot, message) {
    if ( message.payload === "button_postback_name" ) {
        // Do stuff related to this button
    }
})

Listening for Keywords #

We can also listen for specific keywords from a user’s message with the controller.hears method. Unlike Slack bots in which we can listen for keywords from a variety of contexts, there is only one context for Messenger bots, message_received.

controller.hears(array_of_keywords, "message_received", function(bot, message) {
  // do stuff
})

With Messenger Hunt, for example, it listens for the mention of any of the categories on Product Hunt -

controller.hears(['podcasts', 'podcast'], "message_received", function(bot, message) {
  // Get products from the Podcasts category
})
controller.hears(['games', 'game'], "message_received", function(bot, message) {
  // Get products from the Games category
})
// And so on

Responding to Events #

Messenger bots, like Slack bots, can respond to events using the simple bot.reply method. This method allows the bot to give a simple text reply to any message.

controller.hears(['hello', 'hi', 'hey'], 'message_received', function (bot, message) {
    bot.reply(message, "Hi there!");
})

Structured Messages #

In addition to the simple reply methods, Messenger bots can send what are called Structured Messages. These are messages that follow one of Facebook’s predefined formats and can include attachments such as images and buttons.

For example, the Messenger Hunt bot sends products from a particular category as a Generic Template structured message.

var structured_message = {
    attachment: {
      type: 'template',
      payload: {
        template_type: 'generic', // The Generic Template Structured Message
        elements: [
	        // Array of products
            {
		      "title": post.name,
		      "image_url": post.thumbnail.image_url,
		      "subtitle": post.tagline,
		      "buttons": [
		          // CTAs for each product
		          {
		            "type": "postback",
		            "payload": "postInfo_"+post.id,
		            "title":"More Info"
		          },
		          {
		            "type":"web_url",
		            "url": post.redirect_url,
		            "title":"Hunt This"
		          },
		          {
		            "type":"web_url",
		            "url": post.discussion_url,
		            "title":"Discuss/Upvote"
		          }
		      ]
	        },
		    { ... },
		    { ... }
        ]
      }
    }
}

// Send the structured message object instead of a simple string
bot.reply(message, structured_message);

Here is the result -

Postbacks #

The Messenger Hunt bot, as you may have noticed, is not really conversational. Instead, the user interacts with the bot mainly through clicking buttons that trigger postbacks. In my opinion, this is more useful as it doesn't force the user to learn how to "speak" with the bot. Postbacks allow us to create defined responses a user can give and, instead of the user having to type out those specifically, they can just click a button.

For example, when users are presented with the list of products from the Messenger Hunt bot, one of the buttons is an option to get more information about the product.

var buttons = [
   {
	  "type": "postback",
	  "payload": "postInfo_"+post.id,
	  "title":"More Info"
    },
    { ... },
    { ... }
]

Clicking this button triggers a postback, which we can listen for with the controller.on method and respond accordingly.

controller.on('facebook_postback', function (bot, message) {

    if ( message.payload.indexOf('postInfo_') > -1 ) {
        var postID = message.payload.split("_")[1];

        // Call function to get more information about the product
        getPostInfo(bot, message, postID);
    }

    // Handle other postbacks below
})

Everything Else #

Those are the basics of working with Messenger bots. Everything else is to do with the logic of the particular bot and what it does. If you're interested in seeing the logic behind Messenger Hunt, you can checkout out the full source code at my repository, ireade/messenger-hunt.

You can also chat with Messenger Hunt or discuss/vote on it on Product Hunt.

The box-shadow Property

2016-05-24T00:00:00Z

The box-shadow property is a CSS3 property that allows us to create shadow effects on almost any element, similar to the drop shadows we can create in design software. These shadow effects allow us to create the illusion of depth in an otherwise flat, 2-dimensional-looking page.

The Syntax #

The box-shadow property accepts a value made up of up to 5 different parts.

box-shadow: offset-x offset-y blur spread color position;

Unlike other properties, such as border, in which the parts are broken up into sub-properties, the box-shadow property stands alone. This means that it is even more important to take note of the order in which the parts are stated, particularly the length values.

offset-x #

The first length value specified is the horizontal offset of the shadow, i.e. the position of the shadow on the x-axis. Positive values push the position of the shadow to the right of the element, whereas negative values push the position of the shadow to the left of the element.

.left { box-shadow: 20px 0px 10px 0px rgba(0,0,0,0.5) }

.right { box-shadow: -20px 0px 10px 0px rgba(0,0,0,0.5) }

offset-y #

The second length value specified is the vertical offset of the shadow, i.e. the position of the shadow on the y-axis. Positive values push the position of the shadow below the element and negative values push the position of the shadow above the element.

.left { box-shadow: 0px 20px 10px 0px rgba(0,0,0,0.5) }

.right { box-shadow: 0px -20px 10px 0px rgba(0,0,0,0.5) }

blur #

The third length value given represents the blur radius of the shadow, for example what you would get using a Gaussian blur filter in design software. A value of 0 means that the shadow is completely solid and sharp with no blur at all. The larger the blur value, the less sharp and more hazy/blurry the shadow. Negative values are not allowed and will result in a value of 0.

.left { box-shadow: 0px 0px 0px 0px rgba(0,0,0,0.5) }

.middle { box-shadow: 0px 0px 20px 0px rgba(0,0,0,0.5) }

.right { box-shadow: 0px 0px 50px 0px rgba(0,0,0,0.5) }

spread #

The fourth and final length value given represents the size of the shadow. This value can also be thought of us the distance of the shadow from the element. Positive values will extend the shadow outside the element in all directions by the amount specified. Negative values will shrink the shadow smaller than the element size. The default value of 0 will keep the shadow spread the same size as the element.

.left { box-shadow: 0px 0px 20px 0px rgba(0,0,0,0.5) }

.middle { box-shadow: 0px 0px 20px 20px rgba(0,0,0,0.5) }

.right { box-shadow: 0px 50px 20px -20px rgba(0,0,0,0.5) }

color #

A colour value given represents, as you would expect, the colour of the shadow. It can be any colour unit (see Working with Colour in CSS).

.left { box-shadow: 0px 0px 20px 10px #67b3dd }

.right { box-shadow: 0px 0px 20px 10px rgba(0,0,0,0.5) }

position #

The final part of the box-shadow property value is an optional keyword, which represents the position of the shadow. By default, this value is not given, which means that the shadow is an outer box-shadow. We can make the shadow an inner box shadow by using the inset keyword.

.left { box-shadow: 20px 20px 10px 0px rgba(0,0,0,0.5) inset }

.right { box-shadow: 20px 20px 10px 0px rgba(0,0,0,0.5) }

Multiple Shadows #

The box-shadow property is able to accept multiple shadows on a single element. Each shadow is added to the box-shadow property as a comma-separated list.

.foo {
	box-shadow: 20px 20px 10px 0px rgba(0,0,0,0.5) inset, /* inner shadow */
			    20px 20px 10px 0px rgba(0,0,0,0.5); /* outer shadow */
}

Rounded Shadows #

The box-shadow property's border-radius is controlled by the border-radius property on the same element.

.foo {
	box-shadow: 20px 20px 10px 0px rgba(0,0,0,0.5);
	border-radius: 50%;
}

Putting it all together #

Putting all of these parts together, we can create some amazing effects using the box-shadow property.

An Alternative Non-Layout-Blocking Border #

We can use the box-shadow property to create a border around an element that doesn't interfere with the box model or the rest of the layout of the page. Further, using the ability to have multiple shadows, we can have different borders on different sides of the element.

.simple {
	box-shadow: 0px 0px 0px 40px indianred;
}

.multiple {
	box-shadow: 20px 20px 0px 20px lightcoral,
				-20px -20px 0px 20px mediumvioletred,
				0px 0px 0px 40px rgb(200,200,200);
}

Pop-Up Effect #

Using transforms on the box-shadow (& transform) property, we can create the illusion of an element moving closer or further away from the user.

.popup {
	transform: scale(1);
	box-shadow: 0px 0px 10px 5px rgba(0, 0, 0, 0.3);
	transition: box-shadow 0.5s, transform 0.5s;
}
.popup:hover {
	transform: scale(1.3);
	box-shadow: 0px 0px 50px 10px rgba(0, 0, 0, 0.3);
	transition: box-shadow 0.5s, transform 0.5s;
}

Floating Effect #

We can add a box-shadow to the :after pseudo-element as well. We can use this to create a shadow below the element, giving it the illusion of being lifted up or dropped down.

.floating {
	position: relative;

	transform: translateY(0);
	transition: transform 1s;
}
.floating:after {
    content: "";
    display: block;
    position: absolute;
    bottom: -30px;
    left: 50%;
    height: 8px;
    width: 100%;
    box-shadow: 0px 0px 15px 0px rgba(0, 0, 0, 0.4);
    border-radius: 50%;
    background-color: rgba(0, 0, 0, 0.2);

    transform: translate(-50%, 0);
    transition: transform 1s;
}

/* Hover States */
.floating:hover {
	transform: translateY(-40px);
	transition: transform 1s;
}
.floating:hover:after {
	transform: translate(-50%, 40px) scale(0.75);
	transition: transform 1s;
}

There are many other effects we can achieve with the box-shadow property. For example, this popular pen uses the property to create 8 paper-like effects. Even though it is ostensibly a tool for creating simple drop shadows, it can be a lot more powerful that that alone.

Using Jekyll for Rapid CSS Testing

2016-05-17T00:00:00Z

Last week, I gave a talk at JekyllConf, the free online global conference for all things Jekyll. My talk, "Using Jekyll for Rapid CSS Testing", was about how I use Jekyll to quickly and easily create visual demos of CSS properties and their potential values. Using this method, I created cheatsheets.bitsofco.de, where I display the resulting demos. Here's an example of the cheatsheet for Flexbox -

You can watch the full talk here, but here is an overview of the method I used to create the site.

Setting up the Jekyll Site #

The Cheatsheets site uses Jekyll in a rather unconventional way. There are no blog posts, as is usually expected and instead we have “cheatsheets” (e.g. the cheatsheet for Flexbox or object-fit & object-position).

If we want to use Jekyll for groups of content other than blog posts or pages, we can use what is called a custom collection. To create a custom collection, we define it in the _config.yml file. This is how the cheatsheets custom collection is defined -

collections:
  cheatsheets: # The name of the custom collection
    output: true  # Makes the collection public
    permalink: /:path/ # Sets the permalink structure

We can also specify default front matter for custom collections. For example, instead of having to set the layout for each cheatsheet in the front matter of each file, we can set this as the default behaviour in the _config.yml file.

defaults:
  -
    scope: # Sets the scope of the defaults we are about to set to cheatsheets collection
      type: "cheatsheets"
    values: # The default values
      layout: "cheatsheet"

When a custom collection is created, Jekyll expects the files within that collection to be stored in a directory titled after the name of the collection. So, the files within the cheatsheets collection should be in a directory titled _cheatsheets.

The resulting directory for the Cheatsheets Jekyll site looks like this -

- _cheatsheets/
- _data/
- _includes/
- _layouts/
- _sass/
- _site/
- css/
- js/
- _config.yml
- index.html

Creating a Cheatsheet #

Once the Jekyll site is setup, we can start creating the actual cheatsheet files. There are 3 files involved to create a cheatsheet.

1. The Data #

Every cheatsheet has a data file, a YAML file stored in the _data directory (e.g. _data/DATA_NAME.yml). This is where the CSS properties and their values are stored. The file contains an array of properties, each with its own array of values.

properties:
- {
  property: 'PROPERTY_NAME',
  values: [
    {
      value: 'VALUE_NAME',
      default: true
    },
    {
      value: 'VALUE_NAME',
    },
  ]
}
- { ... }
- { ... }
- { ... }

Additional information can also be specified here such as a description of the property or value. We can also add custom keys for anything specific to the cheatsheet group. For example, in the cheatsheet for Flexbox, I added a custom key, applies-to, in order to differentiate between properties that apply to the Flex Container versus the Flex Item.

2. The Demo #

This is the actual cheatsheet file, stored in the _cheatsheets directory (e.g., _cheatsheets/CHEATSHEET_NAME.yml). We can link the cheatsheet to the relevant data file from the _data directory by specifying it in the front matter.

---
title: CHEATSHEET_NAME
data_file: DATA_NAME
---

<!-- Demo will go here -->

Once we have linked the data to the page, we can now create the demos of the properties in the file. In the content of the page, we can loop through each property in the data file and each value for each property.

<!-- Loop through each property -->

3. The Layout #

This file defines the layout for the cheatsheet page (_layouts/cheatsheet.html). As specified in our _config.yml file, it is the default layout for all files within the cheatsheets collection.

In addition to laying out the key elements on the page such as the header and footer, it also creates a table of all the property-value pairs so a complete overview can be seen on one table.

<table>
  <thead>
    <tr>
      <th class="property">Property</th>
      <th class="description">Description</th>
      <th class="values">Values</th>
    </tr>
  </thead>
  <tbody>
    <!-- Loop through each property -->
    
  </tbody>
</table>

An Example #

Here is a very basic example of a cheatsheet for one property, text-align. The data file, _data/text-align.yml, only contains one property, text-align, which has four potential values.

properties:
- {
  property: 'text-align',
  description: 'Describes how inline-level content of a block container is aligned.',
  values: [
    {
      value: 'left',
      default: true
    },
    {
      value: 'right',
    },
    {
      value: 'center',
    },
    {
      value: 'justify',
    }
  ]
}

The cheatsheet file, _cheatsheets/text-align.html, applies the property-value pairs we are testing to a <div> containing a single paragraph -

---
title: Text-Align
data_file: text-align
---

<!-- Loop through each property -->


<!-- Note: I've removed the classes and IDs on the elements for clarity -->

Here's the result we get -

Visit this page

The Cheatsheets site can also handle much more complex situations. For example the object-position property, whose values are not static but can be a range of length units. You can watch the talk to see how I handle those situations, and how the data file can be modified to allow for them. You can also find the source for the Cheatsheets site at my repository, ireade/cheatsheets.

I plan on adding more cheatsheets to the site as I test more CSS properties. If there's anything you'd like to see in particular, let me know.

Setting up a Basic Service Worker

2016-05-10T00:00:00Z

Service Workers are a relatively new, but incredibly powerful, technology. A service worker is a JavaScript file that runs independently to a web page and can perform specific services such as background sync, push notifications, handling network requests, and caching. Because of its independence, it does not have the access to the DOM a typical JavaScript file does, but this allows it to be fully asynchronous and therefore non-blocking.

Because service workers can be used in a variety of circumstances for many different tasks, they can get quite complicated. So, to get started, I thought I would show how to setup a basic service worker to handle something simple, caching. I also decided to try something a bit different and made it a video tutorial instead of a regular article. Here it is -

And this was the service-worker.js we setup in the tutorial -

// Set a name for the current cache
var cacheName = 'v1';

// Default files to always cache
var cacheFiles = [
	'./',
	'./index.html',
	'./js/app.js',
	'./css/reset.css',
	'./css/style.css',
	'https://fonts.googleapis.com/css?family=Source+Sans+Pro:400,700,400italic,700italic'
]


self.addEventListener('install', function(e) {
    console.log('[ServiceWorker] Installed');

    // e.waitUntil Delays the event until the Promise is resolved
    e.waitUntil(

    	// Open the cache
	    caches.open(cacheName).then(function(cache) {

	    	// Add all the default files to the cache
			console.log('[ServiceWorker] Caching cacheFiles');
			return cache.addAll(cacheFiles);
	    })
	); // end e.waitUntil
});


self.addEventListener('activate', function(e) {
    console.log('[ServiceWorker] Activated');

    e.waitUntil(

    	// Get all the cache keys (cacheName)
		caches.keys().then(function(cacheNames) {
			return Promise.all(cacheNames.map(function(thisCacheName) {

				// If a cached item is saved under a previous cacheName
				if (thisCacheName !== cacheName) {

					// Delete that cached file
					console.log('[ServiceWorker] Removing Cached Files from Cache - ', thisCacheName);
					return caches.delete(thisCacheName);
				}
			}));
		})
	); // end e.waitUntil

});


self.addEventListener('fetch', function(e) {
	console.log('[ServiceWorker] Fetch', e.request.url);

	// e.respondWidth Responds to the fetch event
	e.respondWith(

		// Check in cache for the request being made
		caches.match(e.request)


			.then(function(response) {

				// If the request is in the cache
				if ( response ) {
					console.log("[ServiceWorker] Found in Cache", e.request.url, response);
					// Return the cached version
					return response;
				}

				// If the request is NOT in the cache, fetch and cache

				var requestClone = e.request.clone();
				fetch(requestClone)
					.then(function(response) {

						if ( !response ) {
							console.log("[ServiceWorker] No response from fetch ")
							return response;
						}

						var responseClone = response.clone();

						//  Open the cache
						caches.open(cacheName).then(function(cache) {

							// Put the fetched response in the cache
							cache.put(e.request, responseClone);
							console.log('[ServiceWorker] New Data Cached', e.request.url);

							// Return the response
							return response;

				        }); // end caches.open

					})
					.catch(function(err) {
						console.log('[ServiceWorker] Error Fetching & Caching New Data', err);
					});


			}) // end caches.match(e.request)
	); // end e.respondWith
});

Full Source Code | Live Demo

This is the first video tutorial like this I've done, so excuse my nervousness! I would also love to hear any feedback you have on the video; if you found it helpful or ways I could improve on it.

Making IFrames Responsive

2016-04-26T00:00:00Z

While creating the embed for caniuse, one part I found quite challenging was making the iframe fully responsive. When the iframe is resized, the content within it shifts, and the height that the <iframe> element itself should be, changes. However, because of the Content Security Same-origin Policy, there is no way to access the height of the content within the iframe from the document hosting the iframe.

With most embedded content, for example a Youtube Video, we can workaround this because, even though the height does change, the aspect ratio stays the same. So, we can use CSS to determine what the height of the iframe should be at any given width. With this caniuse embed, however, there is no standard size so I needed to have access to the actual height of the content within the iframe to determine what the height of the <iframe> element should be.

I spent ages looking around for how I could do this and came up short. The solution I eventually came up with was to use the postMessage API to communicate between a script in the embedded document, and a script in the hosting document.

Although this method is limited in that requires that we have access to both documents, I thought it would still be useful to share just in case someone else is in the same situation. So here is how it works.

1. Determine the height of the iframe content on page load #

Firstly, there are two scripts involved here -

iframe.js - the script associated with the iframe document
parent.js - the script associated with the document loading the iframe

In iframe.js, we have to determine the height of the document before we can pass it to the parent document. We do this by getting the scrollHeight of the main element (#main-element) within the document.

var documentHeight = document.getElementById(‘main-element').scrollHeight;

We use the height of the main container element instead of just the body because using the body element will cause an infinite loop when we repeat this on the resize of the window (See step 4).

2. Pass the height to the hosting document #

Once we have the height, we can use the postMessage API to send the message to parent.js.

// Add some unique identifier to the string being passed
var message = 'documentHeight:'+documentHeight;

// Pass message to (any) parent document
parent.postMessage(message, "*");

Then, in parent.js, we add an event listener for the message. The method I’m using here is based off an article from David Walsh.

// Setup event listener
var eventMethod = window.addEventListener ? "addEventListener" : "attachEvent";
var eventer = window[eventMethod];
var messageEvent = eventMethod == "attachEvent" ? "onmessage" : "message";

// Listen for event
eventer(messageEvent,function(e) {

  // Check that message being passed is the documentHeight
  if (  (typeof e.data === 'string') && (e.data.indexOf('documentHeight:') > -1) ) {

    // Split string from identifier
    var height = e.data.split('documentHeight:')[1];

   // do stuff with the height

  } 
},false);

3. Resize the `<iframe>` element's height appropriately #

When we receive the new height from the iframe.js, we can change the height of the <iframe> element in the parent document.

var height = e.data.split('documentHeight:')[1],
    height = parseInt(height) + 30; // add a bit of extra space as buffer

// Change height of <iframe> element
document.getElementById('myIframe').height = height + 'px';

4. Repeat on resize of the iframe #

Back in iframe.js, we can send the new height to parent.js everytime the height of the document changes. Using window.onresize, we can check if the documentHeight has changed significantly (in this case by at least 10px), then send the new height to parent.js.

// On resize of the window, recalculate the height of the main element,
// and pass to the parent document again
window.onresize = function(event) {
	var newDocumentHeight = document.getElementById(‘main-element').scrollHeight;
	var heightDiff = documentHeight - newDocumentHeight;

	// If difference between current height and new height is more than 10px
	if ( heightDiff > 10 | heightDiff < -10 ) {
		documentHeight = newDocumentHeight;
		message = 'documentHeight:'+documentHeight;
		parent.postMessage(message,"*");
	}

}

Once the message is posted to parent.js, the <iframe> element's height will be updated.

The reason we don't use the body element to check the height of the iframe content is because, when we resize the <iframe> element in the parent document, that itself will trigger a change in the height of the body element in the iframe document, causing an infinite loop.

You can check out a demo of this at demo.bitsofco.de/responsive-iframe.

Initial, Inherit, Unset, and Revert

2016-04-19T00:00:00Z

There are four values that theoretically can be applied to any CSS property (besides none). These are the explicit defaulting values - initial, inherit, unset, and revert. These values allow us a lot of nuance in setting defaults for properties. Although they are not all universally supported yet, they can be useful to know and understand their differences.

Initial #

The initial value represents the default value for the property, as defined by the official CSS Specification. For example for a <p> element, text-align is left and display is inline.

<p style="text-align: initial;
          display: initial;
          background-color: rgba(255,219,58, 0.3)">
  Hello, world!
</p>

Inherit #

The inherit value represents the value of the element's immediate parent for the same property.

<div style="border: 2px solid plum;">
  <div style="border: inherit; background-color: rgba(255,219,58, 0.3);">
      Hello, world!
  </div>
</div>

If the property is not explicitly defined for the parent element, the behaviour of revert will occur. It will not keep travelling up the element's parents to find a value for that property that has been explicitly defined.

<div style="border: 2px solid plum;">
  <div>
	<div style="border: inherit; background-color: rgba(255,219,58, 0.3);">
		   Hello, world!
	</div>
  </div>
</div>

Unset #

The unset value is sort of a combination of initial and inherit.

There are some properties that, if not explicitly specified, will default to inherit. For example, if we set the color for an element, it applies to all child elements by default. Whereas other properties, like border, do not inherit by default.

<div style="border: 2px solid plum; color: cornflowerblue;">
  <div style="background-color: rgb(200, 200, 200)">
    Hello, world
  </div>
</div>

The color property is inherited but border is not

When unset is applied to a property, it will apply either initial or inherit, depending on what the property's default behaviour is. If the property by default inherits, the inherit will be applied. Otherwise, initial will be applied.

<div style="border: 2px solid plum; color: cornflowerblue;">
  <div style="border: unset; color: unset; background-color: rgb(200, 200, 200)">
    Hello, world
  </div>
</div>

For the border property, the initial value is applied whereas for the color property, the inherit value is applied

Revert #

The revert value, previously called default, represents whatever value the property would be if nothing was applied to it at all.

If no value is applied to a property in the author stylesheet (the styles we as the webpage authors write), the following steps are taken to find a value -

The user defined stylesheet is checked for styles applied to that element.
If nothing is found, the user agent stylesheet is checked.
If nothing is found, the equivalent of unset is applied.

For example, a style frequently added to <div> elements by user agent stylesheets is display: block;, even though the initial value for display is inline. Here is what happens when revert is used compared to initial -

<div style="display: revert;
            background-color: rgba(255,219,58, 0.3)">
  Hello, world! (revert)
</div>
<div style="display: initial;
            background-color: rgba(255,219,58, 0.3)">
  Hello, world! (initial)
</div>

A Gulp Workflow for Building HTML Email

2016-04-12T00:00:00Z

Every week when I publish a new article to this site, I use MailChimp to send out an rss-based newsletter with the latest article to people subscribed. I designed and built the template for this newsletter and, as you would expect, it was quite a process. I was initially using Jekyll and going a lot of things manually, but the whole process was just really a mess. So, I have been working on creating a gulp workflow for building HTML emails.

I needed this workflow to enable me to do a few things -

Have templating and partials to enable splitting up of the template files
Compile SASS files to CSS (optionally include PostCSS for additional features)
Inline the compiled CSS
Allow for an additional CSS file that is embedded in a <style> element, not inlined
Easily test with real data

You can get the workflow files here. It comes with a simple responsive MailChimp template to get started.

If you are completely new to Gulp, you should check out this Simple Gulp Workflow to give you a quick introduction into how it works.

The Folder Structure #

Here is how the working directory is structured, including the default files -

— gulp-email-workflow/
	— src/
		— data/
			— mailchimp.json
		— emails/
			— index.nunjucks
		— sass/
			— inline.scss
			— embedded.scss
		— templates/
			— mailchimp.nunjucks
			— partials/
				— header.nunjucks
				— footer.nunjucks
	— build/
		— css/
			— inline.css
			— embedded.css
		— index.html
	— gulpfile.js
	— package.json

The src/ directory contains all the working files. The templates are contained in the templates/ directory, as well as any partials. The two main SASS files, inline.scss and embedded.scssare contained in the sass/ directory. Any global data is held within the data/ directory. By default, there is one file, mailchimp.json which contains global information about the mailchimp campaign. Finally, the emails/ directory holds the actual emails being created, based off the templates.

The build/ directory contains the final output. This includes the CSS (both the files that are inlined or embedded) as well as the raw HTML.

Setting up Templating, Partials, and Custom Data #

To enable templating and use of partials, I used nunjucks. Nunjucks is a really great templating language developed by Mozilla for JavaScript. To pass global data to the template files, I use the gulp-data plugin.

Here is the nunjucks gulp task -

var nunjucksRender = require('gulp-nunjucks-render');
var data = require('gulp-data');

var globalData = {
    mailchimp: require('./src/data/mailchimp.json')
};

gulp.task('nunjucks', ['sassEmbedded'], function() {
    return gulp.src('src/emails/*.nunjucks')
        .pipe(
            data(function() {
                return globalData;
            })
            .on('error', gutil.log)
        )
        .pipe(
            nunjucksRender({
                path: ['src/templates/', 'build/css/']
            })
            .on('error', gutil.log)
        )
        .pipe(gulp.dest('build/'));
});

This task does a few things -

Wait for the sassEmbedded gulp task to be completed first. This is because, before we include the embedded.css file in the template, we want to make sure that it is the compiled CSS first
Looks at the email files in src/emails/*.nunjucks
Passes those files the mailchmp data from /src/data/mailchimp.json
Generates the HTML page based on the templates and partials in the src/templates/ and build/css/ directories
Builds the completed files into the build/ directory

SASS Compilation (with Post CSS) #

I use Ashley Nolan’s method of combining SASS with PostCSS. This allows us to make use of PostCSS processors, while still writing SASS.

Here are the two gulp tasks for the inline SASS and the embedded SASS -

var sass = require('gulp-sass');
var postcss = require('gulp-postcss');
var scss = require('postcss-scss');
var autoprefixer = require('autoprefixer');
var postcssProcessors = [
    autoprefixer( { browsers: ['last 2 versions', 'ie > 10'] } )
]

gulp.task('sassInline', function(callback) {
    return gulp.src('src/sass/inline.scss')
        .pipe(
           postcss(postcssProcessors, {syntax: scss})
        )
        .pipe(
            sass({ outputStyle: 'expanded' })
            .on('error', gutil.log)
        )
        .pipe(gulp.dest('build/css/'));
});

gulp.task('sassEmbedded', function(callback) {
    // Similar to sassInline task
});

What it does -

Applies PostCSS processors to the SCSS files
Compiles the SCSS files to CSS
Sends the complied CSS files to the build/css/ directory

Inlining CSS #

To inline the CSS, I use gulp-inline-css. This takes an HTML document, looks at CSS being applied to the page, and inlines it to the relevant elements.

Here is the gulp task for inlining CSS -

var inlineCss = require('gulp-inline-css');

gulp.task('inlinecss', ['sassInline', 'nunjucks'], function() {
    return gulp.src('build/*.html')
        .pipe(
            inlineCss({
                applyStyleTags: false,
                removeStyleTags: false
            })
            .on('error', gutil.log)
        )
        .pipe(gulp.dest('build/'));
});

What it does -

Waits for the nunjucks and sassInline gulp tasks to be completed first
Looks at the compiled HTML in the build/ directory
Inlines CSS from the <link rel=“stylesheet”> tag only, so the embedded CSS within the <style> element remains
Replaces the file in the build/ directory with the inlined CSS file

Testing with Real Data #

Now we have set up the various gulp tasks, we can begin writing emails. First, we need to create a template. The default template included in this workflow is mailchimp.nunjucks, which is catered to regular non-RSS MailChimp campaigns.

{% include "partials/header.nunjucks" %}
<center id="body-container">

  <!-- PREHEADER -->
  <table border="0" cellpadding="0" cellspacing="0" id="template-preheader" width="100%">
    <tr>
      <td mc:edit="preheader_left" valign="top" width="50%">
          {% block preheader %}{% endblock %}
      </td>
      <td mc:edit="preheader_right" valign="top" width="50%">
          <a href="*|ARCHIVE|*">View this email in your browser</a>
      </td>
    </tr>
  </table>

  <!-- The rest of the template here... -->

</center>
{% include "partials/footer.nunjucks" %}

To create an email based off of this template, we create a file in the emails/ directory. We use the {% extends %} syntax to specify which template to use, and then we can then write the content for any blocks included in the template.

<!-- Use mailchimp.nunjucks template -->
{% extends "mailchimp.nunjucks" %}

<!-- Apply content to the preheader block -->
{% block preheader %}
Lorem ipsum dolor sit amet
{% endblock %}

And that's it! You can get the files for the workflow from github and start creating your own HTML emails hopefully a bit more pain-free. It's still a work in progress, so if you have any questions or suggestions, leave a comment below.

The Problem with iOS Safari and shrink-to-fit

2016-04-05T00:00:00Z

For a long time, the standard viewport meta tag went like this -

<meta name="viewport" content="width=device-width, initial-scale=1">

However, since iOS Safari 9.0 was introduced in September last year, a new additional value is now needed for most responsive websites, making this the new standard meta tag -

<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">

Why do we need to add this new value? #

To understand why we need to include this new value, we need to observe what happens if we don’t include it.

Nowadays, the majority of elements are styled with responsive dimensions. This means using adaptive units like percentages and viewport units, rather than simple pixels. However, there are some circumstances in which a fixed-width element is included. And, the width of the element is not necessarily smaller than the width of the viewport. For example, a 800px-wide div on an iPhone.

Normally, the behaviour we would expect is that there will be an overflow, and a scrollbar will be introduced to enable the user to see the rest of the width of the content. However, when Safari is in the new Split View mode (i.e. when there are multiple apps open side-by-side on the screen), this doesn't happen.

What happens instead is that Safari manipulates the viewport to be equal to the width of the overflowing element, e.g. 800px, so that it's entirety fits on the screen. The effect of this is that the rest of the page is "shrunk to fit" the larger element.

And we can also see that when the fixed-width element is not larger than the viewport, everything is normal.

Why does Safari behave this way? #

According to the developers working on WebKit, the reason for this is because, based on their data, the majority of websites were misusing the meta viewport tag.

@KMuncie It is intentional. Only a minority of websites were using "initial-scale=1" or "width=device-width" correctly so this was added :( — Benjamin Poulain (@awfulben) September 22, 2015

Instead of using the standard value of width=device-width, initial-scale=1, they were either hard-coding viewport sizes or missing it altogether. Therefore, because of the introduction of Split View, a lot of websites were not prepared for the enforced responsiveness and broke.

Adding `shrink-to-fit` #

Apple's response to this problem was to, by default, shrink all overflowing content on the page to fit the width of the browser viewport. For websites that are responsibly responsive, we can add the new viewport meta value, shrink-to-fit=no, to signal this to Safari and disable this default feature.

<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">

Although we don't know if Apple will keep this around forever, it is certainly here to stay for the foreseeable future, until the balance between properly responsive websites and those that aren't falls on the correct side.

The Holy Grail Layout with CSS Grid

2016-03-29T00:00:00Z

The CSS Grid Layout Module, although still in Editor's Draft, is nearing finalisation. We can now enable it in a number of browsers for testing and help figure out any bugs it may have.

The CSS Grid Layout is really complex, even more so than Flexbox. It has 17 new properties and introduces a lot of new concepts around the way we write css. So, in an attempt to wrap my head around this new specification and figure out how it works, I used it to create the Holy Grail Layout.

What's the Holy Grail Layout? #

The Holy Grail Layout is a web page layout that consists of four sections - a header, footer, and a main content area with two sidebars, one on each side. The layout also adheres to the following rules -

Has a fluid center column width fixed-width sidebars
The center column should appear first in the markup, before the two sidebars (but after the header)
All three columns should be the same height, regardless of the content within them
The footer should always be at the bottom of the browser viewport, even when the content doesn't fill up the height of the viewport
The layout should be responsive, all the sections should collapse into one column on smaller viewports

It is famously difficult to create simply in CSS without any hacks.

The Solution with CSS Grid #

Here is the solution I came up with using the CSS Grid Layout. First, the markup -

<body class="hg">
  <header class="hg__header">Title</header>
  <main class="hg__main">Content</main>
  <aside class="hg__left">Menu</aside>
  <aside class="hg__right">Ads</aside>
  <footer class="hg__footer">Footer</footer>
</body>

And the CSS, at only 31 lines (expanded!) -

.hg__header { grid-area: header; }
.hg__footer { grid-area: footer; }
.hg__main { grid-area: main; }
.hg__left { grid-area: navigation; }
.hg__right { grid-area: ads; }

.hg {
	display: grid;
	grid-template-areas: "header header header"
	                     "navigation main ads"
	                     "footer footer footer";
	grid-template-columns: 150px 1fr 150px;
	grid-template-rows: 100px
						1fr
						30px;
	min-height: 100vh;
}

@media screen and (max-width: 600px) {
	.hg {
		grid-template-areas: "header"
		                     "navigation"
		                     "main"
		                     "ads"
		                     "footer";
		grid-template-columns: 100%;
		grid-template-rows: 100px
							50px
							1fr
							50px
							30px;
	}
}

Breaking it Down #

As I mentioned, CSS Grid Layout can be very complicated. However, for the purpose of creating this layout, I only used 4 of the 17 new properties -

grid-area
grid-template-areas
grid-template-columns
grid-template-rows

My solution to the Holy Grail Layout using these CSS Grid properties can be broken down into five steps.

1. Defining the Grid #

The first thing we want to do is define the grid areas, so we can refer to them by this alias when creating the grid. We do this with the grid-area property.

.hg__header { grid-area: header; }
.hg__footer { grid-area: footer; }
.hg__main { grid-area: main; }
.hg__left { grid-area: navigation; }
.hg__right { grid-area: ads; }

Then, using the grid-template-areas property, we can specify the layout of the grid in a really intuitive and visual way. The grid-template-areas property accepts a space-separated list of strings. Each string represents a row. Within each string, we have a space-separated list of grid areas. Each grid area defined takes up one column. So if we want an area to span two columns, we define it twice.

In our Holy Grail Layout, we have 3 columns and 3 rows. The header and footer rows span 3 columns, while the other areas span 1 column each.

.hg {
	display: grid;
	grid-template-areas: "header header header"
	                     "navigation main ads"
	                     "footer footer footer";
}

With this markup, we get the following result.

2. Defining Column Widths #

Next, we want to define the widths of the columns. We define the width of columns in our grid with the grid-template-columns property. This property accepts a space-separated list of widths, one for each column in the grid. Because we have 3 columns in our layout, we can specify 3 widths -

grid-template-columns: [column 1 width]  [column 2 width]  [column 3 width];

For the Holy Grail Layout, we want the 2 sidebars to be 150px width each.

.hg {
  grid-template-columns: 150px  [column 2 width] 150px;
}

We also want the middle column to take up the rest of the space. We can do this by using the new fr unit. This unit represents a fraction of the free space left in the grid. In our case, this adds up to the current width of the grid minus 300px (the width of the two sidebars).

.hg {
	grid-template-columns: 150px 1fr 150px;
}

After setting the grid columns, this is what the layout looks like -

3. Defining Row Heights #

Next, we want to define the heights of the rows. Similar to how we define the column widths with grid-template-columns, we define the row heights with grid-template-rows. This property also accepts a space-separated list of heights for each row in our grid. Although we can write it on one line, I think it's nicer and more visually clear to write it one row per line.

.hg {
	grid-template-rows: 100px
						1fr
						30px;
}

So our header height is 100px, our footer height is 30px, and the middle row (with the main content and two sidebars) takes up the rest of the available space in the .hg element.

In the Holy Grail Layout, we want the footer to always be at the bottom of the viewport, even if the content on the page is sparse. To achieve this, we can set a minimum height on the .hg element to be the height of the viewport.

.hg {
	min-height: 100vh;
}

Because we specified that the middle row should fill up the rest of the available space, it stretches to fill the screen.

5. Making it Responsive #

Finally, we want to make the layout responsive. On smaller devices, all the grid items should be displayed in a single column, one after the other. To do this, we need to redefine the 3 properties we defined before - grid-template-areas, grid-template-columns and grid-template-rows.

First, we want all the items in the grid to be in one column, in a particular order -

@media screen and (max-width: 600px) {
	.hg {
		grid-template-areas: "header"
		                     "navigation"
		                     "main"
		                     "ads"
		                     "footer";
	}
}

Next, we want all items to span the full width of the grid -

@media screen and (max-width: 600px) {
	.hg {
		grid-template-columns: 100%;
	}
}

Finally, we need to reset the heights of each of the rows. All rows, besides the main row, have a defined height -

@media screen and (max-width: 600px) {
	.hg {
		grid-template-rows: 100px /* Header */
							50px /* Navigation */
							1fr /* Main Content */
							50px /* Ads */
							30px; /* Footer */
	}
}

And that's it! You can check out a demo of this here, as well as the source (nb: you may need to enable experimental web features in your browser to see it).

Support #

Better Detection and Analytics for Opera Browsers

2016-03-22T00:00:00Z

In my article, WTF Opera Mini?!, I wrote about the lack of support that the Opera Mini browser has for what I considered basic development features (e.g., font properties and 2d transforms).

If you didn't already know, in the Opera Mini browser, the user has the option between two modes - High/Normal Savings Mode and Extreme Savings Mode. A lot of the complaints I had with Opera Mini are actually constrained to the Extreme Savings Mode in the browser. However, because there was no way to determine which mode was being used, I had to assume that all Opera Mini users were on the Extreme Savings Mode, especially as it is enabled by default.

However, through a bit of research, I managed to find a way to detect which savings mode a user is currently on, as well some other useful information.

Better Detection #

The method I used to detect the various Opera Browsers and savings modes is through looking at the navigator.userAgent string returned by the browser. Here is an example user agent string returned from the Opera Mini Browser on a Nexus 5 running Android Marshmallow -

Mozilla/5.0 (Linux; U; Android 6.0.1; en-GB; Nexus 5 Build/MMB29V) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 OPR/15.0.2125.101257 Mobile Safari/537.36

The user agent string differs across browsers, devices, and operating systems, but there are some commonalities between all Opera browsers we can use for detection. For example, we can detect if the browser is an Opera browser by checking for the following -

var isOpera = window.opera |
              window.opr |
              navigator.userAgent.indexOf(' OPR/') > -1 |
              navigator.userAgent.indexOf(' Coast/') > -1 |
              navigator.userAgent.indexOf(' OPiOS/') > -1;

Detecting Savings Mode #

When Opera Mini is in Extreme Savings Mode, a completely different engine is used and this is reflected in the user agent string. For example, this is the user agent string for Opera Mini on the Nexus 5 in High versus Extreme Savings Mode -

// High Savings Mode (Normal)
Mozilla/5.0 (Linux; U; Android 6.0.1; en-GB; Nexus 5 Build/MMB29V) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 OPR/15.0.2125.101257 Mobile Safari/537.36

// Extreme Savings Mode
Opera/9.80 (Android; Opera Mini/15.0.2125/37.8025; U; en) Presto/2.12.423 Version/12.16

In Extreme Savings Mode, the Presto engine is being used. So, we can determine which savings mode the user is currently on based on this information.

if ( navigator.userAgent.indexOf('Presto/') > -1 &&
     navigator.userAgent.indexOf('Opera Mini/') > -1 ) {
  // Extreme Savings Mode
} else {
  // High/Normal Savings Mode
}

Detecting Other Information #

The user agent string can also give us more information about the browser and device being used. So, instead of just detecting which savings mode is being used, I wrote a small detection script that will determine the following information -

Browser - Opera, Opera Mini, Opera Mobile, or Opera Coast
Operating System - iOS, OSX, Windows, or Android
Platform - Mobile/Tablet, Desktop, or TV
Mode - High/Normal Savings or Extreme Savings

The opera-detect.js script returns an object, operaDetect, with the following information -

var operaDetect = {
  isOpera: // Boolean, if the current browser is an Opera browser
  isExtremeMode: // Boolean, if is the Extreme Savings Mode is on
  results: {
    mode: // String, which Savings Mode is being used, e.g. "High/Normal Savings"
    platform: // Which platform, e.g. "Mobile/Tablet"
    browser: // e.g. "Opera Coast
    OS: // e.g. "Android"
  }
}

With this information, we can easily detect information about the savings mode a user is on, and alter their experience if necessary.

if ( operaDetect.isExtremeMode ) {
  // do stuff
}

You can get this script to use yourself at my github repo, ireade/operadetect.

Better Analytics #

Google Analytics has some great browser detection. Not only can you detect which browsers your visitors are using, but you can get more information on the browser such as versions. However, the default analytics are limited in two ways -

No information on Savings Mode
Opera Coast and Opera Mini (Normal Mode) on iOS show up as Safari, not Opera. (I assume this is because they use iOS Webview)

To solve this, we can set up custom dimensions with Google Analytics to track the four pieces of information we receive from the opera-detect.js script. Once the custom dimensions are set up through Google Analytics, we can easily pass the information -

if ( operaDetect.isOpera ) {
  ga('set', 'dimension1', operaDetect.results.mode);
  ga('set', 'dimension2', operaDetect.results.platform);
  ga('set', 'dimension3', operaDetect.results.browser);
  ga('set', 'dimension4', operaDetect.results.OS);
}

// Send pageview
ga('send', 'pageview');

To make things even easier, we can setup a custom dashboard to easily view this information -

If you want to set these analytics up for your site, you can follow these instructions.

On :not and Specificity

2016-03-15T00:00:00Z

The negation pseudo-class, :not, can be incredibly useful. It allows us to target elements based on what attributes they don't have, rather than what they do. This helps us avoid writing extra, increasingly specific, rules in an attempt to override previous ones.

A common example of this is when we want to apply a style to all list items, expect the last one. For example -

/* Without :not */
li { border-right: 1px solid #000; }
li:last-child { border-right: none; }

/* Using :not */
li:not(:last-child) { border-right: 1px solid #000; }

The :not pseudo-class is one I use a lot. However, in my past use, I would occasionally run into scenarios in which the :not declaration would override a positive one. For example -

a:not(.ul) { text-decoration: none; }
nav a { text-decoration: underline; }

When I did this, I found that the nav a elements would still not have an underline. I was initially a bit baffled as to why this would happen, until I did more reserach into how the :not rule actually works, and it's effect on specificity.

Specificity 101 #

Specificity in CSS can be complicated to grasp, so it's best to start with an example. Consider the following element -

<p class="foo" id="bar">Lorem ipsum dolor sit amet.</p>

And the following styles -

p { color: red; }
.foo { color: green; }
#bar { color: blue; }
p.foo#bar { color: yellow; }

In cases like this where there are multiple selectors targeting the same element, which selector's rules will prevail is determined by its specificity. The specificity of a selector is determined by 2 things -

What kinds of selectors are used. There are three kinds of selectors -
1. ID Selectors, e.g. #bar
2. Class Selectors (including Pseudo-Classes), e.g. .foo or :last-child
3. Type Selectors, e.g. p
The number of each kind of selector. For example if there are 2 IDs and 3 Classes.

These two factors combined determine the level of specificity for a selector. Using the example above, this is how specificity is calculated for each selector -

Selector	No of IDs	No of Classes	No of Types	Specificity	Winner
`p`	0	0	1	0-0-1
`.foo`	0	1	0	0-1-0
`#bar`	1	0	0	1-0-0
`p.foo#bar`	1	1	1	1-1-1	✓
The way to read the resulting specificity is not to read it as one number, but to consider each unit itself, from left to right.

When comparing two selectors, we take the first value (representing the number of ID Selectors) and compare that. If one selector has a higher ID value, then it automatically wins the specificity battle. If, and only if, the two selectors are equal in that value, do we move on to the next value (representing the number of Class Selectors), and so on.

Consider the following examples -

Selector	No of IDs	No of Classes	No of Types	Specificity	Winner
`p`	0	0	1	0-0-1
`p:last-child`	0	1	1	0-1-1
`p.foo.bar.baz`	0	3	1	0-3-1
`#bar`	1	0	0	1-0-0	✓
A single ID will always beat 100 classes, because the number of classes is irrelevant if IDs exist.

(As a side note, it is important to remember that these calculations only apply to styles defined in CSS. Inline styles override all selector-based styles.)

What about :not? #

The :not itself doesn't add anything to the specificity number as other pseudo-classes do. However, the selectors within the :not do.

With respect to specificity, adding p:not(.foo), is essentially the same as adding .notFoo to all p's that do not have the the class of .foo

Fo example -

p.bar { color: red; }
p:not(.foo) { color: green; }

What colour would you expect <p class="bar"> to be? The correct answer is green, not red.

This is because, by adding the the :not rule, we have essentially added a class .notFoo to our <p class="bar"> element.

Selector	No of IDs	No of Classes	No of Types	Specificity	Winner
`p.bar`	0	1	1	0-1-1	Equal
`p:not(.foo)`	0	1	1	0-1-1	Equal
The `:not` rule is now the same level of specificity as the positive class element. So, because it is defined later in the CSS, it prevails. This also explains why, in the `nav` example, the `:not` rule won over the nested type selectors.

Selector	No of IDs	No of Classes	No of Types	Specificity	Winner
`a:not(.ul)`	0	1	1	0-1-1	✓
`nav a`	0	0	2	0-0-2

Things get even more messy when we introduce IDs. The same way that p:not(.foo) is almost like adding .notFoo to all <p> elements, adding p:not(#bar) is like adding #notBar to all <p> elements. For example -

p:not(#foo) { color: green; }
p.bar { color: red; }

What colour would you expect <p class="bar"> to be? The correct answer is green, not red.

Selector	No of IDs	No of Classes	No of Types	Specificity	Winner
`p.bar`	0	1	1	0-1-1
`p:not(#foo)`	1	0	1	1-0-1	✓
Even though our positive class element is defined later in the css, we have essentially inadvertently added an ID to the element from the `:not` rule! 😱

Using :not #

This effect of :not has made me re-think the way I use it. Even though it feels like we are bypassing the need to write increasingly specific rules to override others, like in the li:last-child example, it seems like :not inadvertently does the same thing.

I will definitely keep using :not because, in many circumstances, it is still the cleaner way to write styles. However, I will use it with a few caveats -

Never use it with IDs, e.g. :not(#bar)
Restrict using it with generic type selectors, e.g. div:not(.foo)
Define :not rules earlier in CSS so they can be overridden if necessary

Styling Broken Images

2016-03-08T00:00:00Z

Broken images are ugly.

But they don’t always have to be. We can use CSS to apply styles to the <img> element to provide a better experience than the default.

Two Facts About The `<img>` Element #

To understand how we can style broken images, there are two facts about the way the <img> element behaves that we need to understand first.

We can apply regular typography-related styling to the <img> element. These styles will be applied to the alternative text, if it is displayed, and will not affect the working image.
The <img> element is a replaced element. This is an element “whose appearance and dimensions are defined by an external resource” (Sitepoint). Because the element is controlled by an external source, the :before and :after pseudo-elements typically shouldn’t work with it. However, when the image is broken and not loaded, these pseudo-elements can appear.

Because of these two facts, we are able to apply styles to the <img> element that will only appear when the image is broken, and will leave a working image unaffected.

Putting It Into Practice #

Using this information, here are some examples of how we can style broken images, using the following broken link -

<img src="https://bitsofco.de/broken.jpg" alt="Kanye Laughing">

Adding Helpful Information #

One way we can handle broken images is to provide a message to the user saying that the image is broken. Using the attr() expression, we can even display the link to the broken image.

img {
  font-family: 'Helvetica';
  font-weight: 300;
  line-height: 2;
  text-align: center;

  width: 100%;
  height: auto;
  display: block;
  position: relative;
}

img:before {
  content: "We're sorry, the image below is broken :(";
  display: block;
  margin-bottom: 10px;
}

img:after {
  content: "(url: " attr(src) ")";
  display: block;
  font-size: 12px;
}

Replacing The Default Alternative Text #

Alternatively, we can use the pseudo-elements to replace the default alt text that shows, by positioning the pseudo-element on top of the default text, hiding it from view.

img { /* Same as first example */ }

img:after {
  content: "\f1c5" " " attr(alt);

  font-size: 16px;
  font-family: FontAwesome;
  color: rgb(100, 100, 100);

  display: block;
  position: absolute;
  z-index: 2;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  background-color: #fff;
}

Extra Styling #

In addition to (or instead of) displaying a custom message, we can use the pseudo-elements to apply more styling to the broken image.

img {
  /* Same as first example */
  min-height: 50px;
}

img:before {
  content: " ";
  display: block;

  position: absolute;
  top: -10px;
  left: 0;
  height: calc(100% + 10px);
  width: 100%;
  background-color: rgb(230, 230, 230);
  border: 2px dotted rgb(200, 200, 200);
  border-radius: 5px;
}

img:after {
  content: "\f127" " Broken Image of " attr(alt);
  display: block;
  font-size: 16px;
  font-style: normal;
  font-family: FontAwesome;
  color: rgb(100, 100, 100);

  position: absolute;
  top: 5px;
  left: 0;
  width: 100%;
  text-align: center;
}

If the image is not broken, with all the same styles applied to the element, the image is displayed normally. The pseudo-elements are not generated at all.

Browser Compatibility #

Unfortunately, not all browsers handle broken images in the same way. For some browsers, even though the image is not displayed, the pseudo-elements don't show up at all.

Here’s what I’ve found from my tests -

Browser	Alt Text	:before	:after
Chrome (Desktop and Android)	✓	✓	✓
Firefox (Desktop and Android)	✓	✓	✓
Opera (Desktop)	✓	✓	✓
Opera Mini	✓ **	✗	✗
Safari (Desktop and iOS)	✓ *	✗	✗
iOS Webview (Chrome, Firefox, others)	✓ *	✗	✗

* The alt text will only show if the width of the image is large enough to accommodate it. If no width is specified for the img, the alt text may not be displayed at all ** Font styling not applied

For browsers that don’t support the pseudo-elements, the styles applied are ignored, so they don’t interfere in a breaking way. This means that we can still apply the styles and serve a more pleasant experience for users on a supporting browser.

Challenge - Recreating Clear with Pure JavaScript

2016-03-01T00:00:00Z

If you don’t already follow @wesbos on twitter, you probably should. Recently, he has been posting some interesting javascript challenges - see the first one and the second one. I found those challenges really helpful, so I decided to create one myself.

I use the todo application, Clear, a lot and thought it would be an interesting challenge to recreate the core interactions in the browser.

The Challenge #

This is what the final product looks like -

Start the Challenge | Live Demo with My Solution

The key interactions -

Drag a list item right to mark it as complete - Once the user has dragged the item past a certain point and releases the mouse, the item should swipe away fully.
Completed items appear at the bottom - The completed item should reappear at the bottom of the list.
Drag a list item left to delete it - Deleted items are removed from the HTML completely.
Drag left on a completed item to delete it - The user can drag a completed item left to delete it. Dragging right should not do anything.

If you want to try out this challenge, you can get the boilerplate HTML and CSS here. The aim of the challenge is to use only JavaScript, but if you’re a beginner you can use jQuery as well.

My Solution #

If you're going to try the challenge yourself, don't look past here. Otherwise, this is the solution that I came up with. It can be summarised in four key functions.

addMouseDownEventListener() #

In this function, I add an event listener on mousedown for all of the list items. When this event is fired, 2 other event listeners are added - mousemove and mouseup.

function addMouseDownEventListener() {

	// Reset values to use in handleMouseMove()
	cursorXPosition = 0;
	cursorXPositionDiff = 0;

	// Loop through all tasks and add the event listener to each
	for ( var i = 0; i < tasks.length; i++ ) {
		tasks[i].addEventListener("mousedown", function(event) {
			this.addEventListener("mousemove", handleMouseMove, false);
			this.addEventListener("mouseup", handleMouseUp, false);
		})
	}
}

handleMouseMove() #

This is the function that is called when the user has clicked and moved the mouse together (so essentially, dragging). It does two things -

Drags the list item along with the mouse
Adds a class of .completing or .deleting depending on if the list item has been dragged right/left by a certain threshold

var handleMouseMove = function(event) {

	if ( cursorXPosition === 0 ) { cursorXPosition = event.x; }

	// Set the margin-left of the list item to move with the mouse
	cursorXPositionDiff = event.x - cursorXPosition;
	event.target.style.marginLeft = cursorXPositionDiff + 'px';

	var taskIsNotCompleted = !(event.target.className.indexOf("completed") > -1);

	// Add class if the cursorXPositionDiff gets to a certain amount (40px)
	if ( cursorXPositionDiff > 40 && taskIsNotCompleted ) {
		event.target.classList.add('completing');

	} else if ( cursorXPositionDiff < -40 ) {
		event.target.classList.add('deleting');

	} else {
		event.target.classList.remove('completing');
		event.target.classList.remove('deleting');
	}
}

handleMouseUp() #

This is the function that is called after the user releases the grip on the list item. It checks if the item has been marked as .completing, .deleting, or neither, and handles each case -

var handleMouseUp = function(event) {

	var className = event.target.className;

	if ( className.indexOf('completing') > -1 ) {
		// SWIPE AWAY CURRENT LIST ITEM (RIGHT)
		swipeElement(event.target.id, true);

	} else if ( className.indexOf('deleting') > -1 ) {
		// SWIPE AWAY CURRENT LIST ITEM (LEFT)
		swipeElement(event.target.id, false);

	} else {
		// REPOSITION LIST ITEM BACK TO NORMAL POSITION
		event.target.style.marginLeft = "";
	}

     // Remove mousemove listener, and re-add mousedown listeners to all list items
	this.removeEventListener("mousemove", handleMouseMove, false);
	addMouseDownEventListener();
}

swipeElement() #

This function handles the swiping away/in of the list items -

function swipeElement(elementID, swipingRight, swipingIn) {

	var element = document.getElementById(elementID);

	// Swiping an element out - marking as completed or done
	function swipeElementOut() {
		var currentMargin = getCurrentMargin(element),
			currentMargin = swipingRight ? currentMargin += 1 : currentMargin -= 1;

		element.style.marginLeft = currentMargin + '%';

		if ( currentMargin == 100 | currentMargin == -100 ) {
			clearInterval(interval);
			// Either append completed item to bottom or delete item
			swipingRight ? appendCompletedItem(element) : element.remove();
		}
	}

	// Swiping an element in - appending completed item to list
	function swipeElementIn() {
		var currentMargin = getCurrentMargin(element);
			currentMargin -= 1;

		element.style.marginLeft = currentMargin + '%';
		if ( currentMargin == 0 ) { clearInterval(interval); }
	}

    // Choose which function to use
	var interval = swipingIn ? setInterval(swipeElementIn, 5) : setInterval(swipeElementOut, 5);
}

There's still a lot I can do to improve this, but this is the solution I have found for now. You can view my full solution here.

The real value in doing these challenges is seeing how others tackle the problem. So, if you do this, do leave a comment with a link to your codepen/github and I’ll add a list of everyone’s solutions.

6 Reasons to Start Using Flexbox

2016-02-23T00:00:00Z

Do you use flexbox? Last week on twitter, I asked this question and was surprised to find out that less than 50% of people answered yes. This was surprising to me because, up until recently, I wasn't using flexbox in any production projects either, and I thought I must be the only one.

There were a number of reasons why I hadn't started using flexbox regularly but, having done more research, my concerns have subsided and I've become a convert. So, here are 6 reasons you should start using flexbox (too).

1. It’s supported in all major browsers #

The main reason I hadn’t been using flexbox was because of a perceived lack of browser support. But in actual fact, flexbox is very well supported, at 95.89% global support. If you disregard IE 10 and below, which Microsoft says you now can, this number is even higher.

Flexbox has even more support than other features I still use such as 2D transforms (with 91.85%) or even position:fixed (with 92.98%).

2. You don’t have to worry about syntax #

Even though the current syntax of flexbox is supported in the current versions of all browsers, what about the old versions? Because the syntax has changed over the years, there is some inconsistency in how to write it. To support the last 2 versions of all browsers currently, we would have to write at least 4 versions of every rule using various vendor prefixes.

The solution to this I have settled on is to just use autoprefixer. Keeping track of which vendor prefixes we need to use for what isn’t necessarily the best use of our time and effort, so we can and should automate it.

Using autoprefixer, we can specify which browser versions we want to support, and the correct vendor prefixes will be automatically added.

/* Write this */
.flex-container {
  display: flex;
}

/* Compiles to this (with autoprefixer set to support last 2 versions of all browsers) */
.flex-container {
  display: -webkit-box;
  display: -webkit-flex;
  display: -ms-flexbox;
  display: flex;
}

3. It can be simple to get started #

Admittedly, learning all of flexbox isn’t so straightforward. There are 12 new properties, each with an average of 4 potential values. It can be a bit overwhelming to jump right in with everything.

But you don’t have to start with everything. For a great number of circumstances, I find myself only needing to use 3 properties -

display - This sets the element as an inline or block flexbox container element
justify-content - This controls the horizontal alignment of items within the flex container (If the flex-direction is the default value of row or row-reverse)
align-items - This controls the vertical alignment of items within the flex container (If the flex-direction is the default value of row or row-reverse)

With these properties alone, which are applied to the flex container, we can produce a lot of different layouts. And when you’re ready to learn more, there is an abundance of resources/cheatsheets/exercises to help you learn -

Flexbox Playground - A live document you can play around with to test the effect of each property-value pair
A Complete Guide to Flexbox (CSS Tricks) - An overview of all of flexbox
Flexbox Froggy - A game for learning CSS flexbox
Flexbugs - A community-curated list of flexbox issues and cross-browser workarounds for them
Flexibility - A polyfill to support legacy browsers

4. You can finally centre elements #

Besides the support for flexbox, a reason to use it is the ease in which we can centre elements, both horizontally and vertically.

With only 3 declarations, we can achieve a perfectly centred child element -

.flex-container {
  display: flex;
  justify-content: center; /* horizontal centering */
  align-items: center; /* vertical centering */

  border: 2px dashed #000;
}

5. You can manipulate inline elements easily #

One issue with having inline items positioned beside each other is the infamous extra 4px margin. Although there are ways to get around this, like floating the elements, that comes with its own problems as well.

With flexbox, we can deal with inline elements effortlessly. We can align the elements edge-to-edge -

.flex-container { display: flex; }
.flex-item { width: 20%; }

We can have space evenly distributed on both sides of the items -

.flex-container {
  display: flex;
  justify-content: space-around;
}

We can even have the space distributed evenly between only the middle items, without dealing with :first-child or :last-child -

.flex-container {
  display: flex;
  justify-content: space-between;
}

6. It simplifies complexity #

The reason flexbox was created in the first place was for this very reason, to allow us to achieve the complex layouts we already create, in as little as one declaration.

In the previous examples, I showed what could be done by styling the flex container alone. However, we can achieve much more fine-tuned styling by targeting the flex items. For example, a common layout for pricing tables is this -

There are three divs, and the middle one is twice the width of the others. To achieve this layout using flexbox, we could write.

.flex-container {
  display: flex;
  align-items: center;
}

.flex-items:not(:nth-child(2)) {
  flex-grow: 1;
  height: 300px;
}

.flex-items:nth-child(2) {
  flex-grow: 2;
  height: 350px;
}

I realise I'm late to the party, but thought there may still be other people out there that needed the extra nudge. Do you already use flexbox? If not, have you been convinced to give it a try?

Making KhaledBot - An Introduction to Slack Bots

2016-02-16T00:00:00Z

So I made a Slack bot… @khaledbot.

You can get the bot yourself at khaledbot.com, or download the source from my github repository. As @khaledbot says,

Learning is cool, but knowing is better, and I know the key to success.

So here is how I created this Slack bot, and an introduction to creating bots for Slack in general.

1. Create a Bot User with Token #

The first thing we will need to is create a new bot user for the Slack team.

All we need to do is choose a username for the bot, and a custom API Token for the bot will be generated. We can also add extra details like a real First and Last name for the bot, and a description of what the bot does.

2. Create a New Node.js Project with Botkit #

As I’m more familiar with JavaScript, I decided to create this bot using Node.js and Botkit. Botkit is a framework, recommended by Slack, for building bots quickly and easily.

We can install the botkit module via npm -

npm install botkit --save

Once botkit is installed, we can setup the bot. In the main index.js file -

var Botkit = require(‘botkit’) // require botkit module
var token = process.env.SLACK_TOKEN // get slack token passed as variable

// Setup new slackbot with botkit
var controller = Botkit.slackbot({
  debug: false
})

// Check that token was passed
if (!token) {
  console.error(’SLACK_TOKEN is required’)
}

// Start Slack’s Bot Real Time Messaging API (RTM)
controller.spawn({
  token: token
}).startRTM(function(err,bot,payload) {
  if (err) {
    throw new Error(err)
  }
});

3. Start Bot #

While working on the bot, we can start it locally. From the terminal, while in the directory for the project, all we have to do is pass the token (from Step 1) as a variable while starting the main file -

SLACK_TOKEN=[slack-token-here] node index.js

4. Listening for Events and Keywords #

Once our bot is setup, we can start adding functionality to make it do what we want. Typically, bots respond to events that happen, e.g. a user joining a channel, or to keywords.

Listening for Events #

There are several events that a bot can respond to. For example -

bot_channel_join - When the bot is invited to a new channel
direct_mention - When someone mentions the bot’s username directly, e.g. @khaledbot: hi!
direct_message - When someone sends a direct (private) message to the bot

For @khaledbot, I had it listen for when it was added to a channel. For example -

controller.on("bot_channel_join", function(bot, message) {
 // do stuff
})

Listening for Keywords #

A bot can also be alerted when another member of the Slack team mentions a keyword in certain circumstances. To set this up, we specify two things -

The keyword to listen for, e.g. "hello"
The context in which the keyword was mentioned. For example, if it was a direct_message, a direct_mention, or ambient (when the bot is not directly mentioned, but is active in the channel)

controller.hears(array_of_keywords, array_of_contexts, function(bot, message) {
  // do stuff
})

For @khaledbot, whenever someone mentioned “khaled", the bot was alerted -

controller.hears(["khaled"], ["ambient"], function(bot, message) {
  // do stuff
})

5. Responding to Events #

When an event happens, we want the bot to do something in response. A bot can send a single reply using bot.reply. This function accepts two arguments - the message the bot is replying to, and the reply text.

For @khaledbot, whenever someone mentioned “khaled”, the bot responds to them.

controller.hears(["khaled"], ["ambient"], function(bot, message) {

  var userID = message.user // the ID of the user that mentioned "khaled"
  var user = "<@"+userID+">" // wrap around like this to create an @ mention of the user

  var reply = user+" you spoke my name?"; // create reply

  bot.reply(message, reply); // send reply
})

We can use a series of these listens and replies to create the bot.

6. Deploying to a Server #

Once we have created our bot, we need it to live on a server to be online 24/7.

For @khaledbot, I used Beep Boop, which is a service for easily deploying Slack bots. They offer free hosting for your bots for 24 hours (after that, you can restart the bot for another free 24 hour period or pay to maintain uptime).

And We're Live #

You can get @khaledbot from khaledbot.com. It's also on product hunt. If you have any feedback on how I can improve on it, let me know. Bless up!

The One CSS Feature I Really Want

2016-02-09T00:00:00Z

There are many cutting edge CSS features/properties I wish were more widely supported.

Variables
Flexbox
Transforms
Animations

The list can go on. However, there is one feature, introduced in CSS3, that I cannot wait to be supported in all, or at the least current versions of the major browsers. This is @supports.

The Magic That is @supports #

The @supports rule is a conditional group rule, similar to media queries, but for detecting if the current user agent supports a particular CSS property-value pair. Like media queries, if the statement given evaluates to true, the declarations within the group are applied.

The @supports rule allows us to detect feature support in four ways -

1. Detect if a property-value pair is supported #

The most basic way we can use the rule is to detect if a single CSS property-value pair is supported. For example, if we want to check if the current flexbox syntax is supported, we can write -

@supports ( display: flex ) {
  .foo { display: flex; }
}

For browsers such as Internet Explorer 9, everything within the block will be ignored.

2. Detect if all of several property-value pairs are supported #

Sometimes, we need to use properties in combination. With the and rule, we can detect if a list of property-value pairs are supported by the browser.

@supports ( ( font-kerning: normal ) and
            ( font-feature-settings: "kern" 1 ) ) {
  .foo {
    font-kerning: normal;
    font-feature-settings: "kern" 1;
  }
}

3. Detect if either of several property-value pairs are supported #

We can also detect if any of a list of properties are supported. This can be useful when trying to determine if a prefixed or unprefixed version of a property is supported.

@supports ( ( tranform: translate(-50%, -50%) ) or
            ( -webkit-tranform: translate(-50%, -50%) ) ) {
  .foo {
    -webkit-tranform: translate(-50%, -50%);
    tranform: translate(-50%, -50%);
  }
}

4. Detect if a property-value pair is not supported #

Being able to detect if certain property-value pairs are supported is useful, but also being able to detect if a pair is not supported is even more useful. With the not rule, we can do just that.

@supports not ( display: flex ) {
  .foo { display: table; }
}

Even more magically, we can detect if one property-value pair is supported and another is not supported. For example, we can target browsers that only support the old flexbox syntax.

@supports ( display: flexbox )
          and
          ( not ( display: flex ) ) {
  .foo { display: flexbox; }
}

😍😍😍

Why @supports? #

The reason why I want this feature above all the other fun/crazy/cool features in CSS is because, currently, I can’t use those fun/crazy/cool features.

If a browser, such as IE or Opera Mini, doesn’t support a feature, I simply cannot use it because a lot of the websites I build are for an audience that use those browsers.

The @supports rule allow will allow me to have the best of both worlds - being able to write the fun, cutting-edge stuff for the browsers that support it, while writing the old tried-and-tested stuff for the browsers that don’t.

Is @supports Supported? #

The global support for @supports is currently at about 70%.

Even though @supports is currently supported by the majority of browsers, I can’t feel comfortable using it until at least all current browser versions support it. If it only works in some browsers, that sort of defeats the point of it.

So I guess this is my open letter, pleading to those browsers, to support @supports. On the day that I see that all current versions of major browsers support this, this will be me.

In the mean time, is supports supported yet?

Responsive Images - The srcset and sizes Attributes

2016-02-02T00:00:00Z

In the responsive web design revolution, images are one thing that have seemingly lagged behind. Until relatively recently, serving different images based on screen size or pixel density was not something that was done at all.

The <picture> element shows a lot of promise in changing this. But whether the picture element is used at all, there are two attributes that are key in providing responsive images - srcset and the accompanying sizes.

The `srcset` attribute #

The srcset attribute allows us to provide a set of images that can be potentially served by the browser. We, as the authors, provide a comma-separated list of images and the user agent determines which image to display depending on the particulars of the device.

When listing the images, we provide two pieces of information about each image -

The path to the image file
The pixel density or width of the image

To define pixel density, we add an x to the density number for the image. For example -

<img src="one.png"
     srcset="two.png 2x, three.png 3x, four.png 4x">

The image defined with the src attribute is assumed to be 1x.

When the srcset attribute was first specified in 2012, we could only provide images of different pixel densities, as shown above. However, the 2014 Specification introduced the width value, which allows us to assign the width of the different images.

To assign the width of the image, we add a w to the pixel width number for the image. For example -

<img src="one.png"
     srcset="two.png 100w, three.png 500w, four.png 1000w">

Only when using the width version of the srcset attribute, can we accompany it with the sizes attribute.

The `sizes` attribute #

The sizes attribute allows us to explicitly define the size the image should be according to a set of media conditions.

<img src="one.png"
     srcset="two.png 100w, three.png 500w, four.png 1000w"

     sizes="<media condition> <width>,
            <media condition> <width>,
            <optional default image width>">

Media Conditions #

A media condition is not exactly a media query. It is part of a media query. It doesn’t allow us to specify media types, e.g. screen or print, but accepts the condition we usually add to a media type.

A valid media condition can be either -

A plain media condition, e.g. (min-width: 900px)
A “not” media condition, e.g. ( not (orientation: landscape) )
An “and” media condition, e.g. (orientation: landscape) and (min-width: 900px)
An “or” media condition, e.g. ( (orientation: portrait) or (max-width: 500px) )

Width #

The width specified can be almost any length value, e.g. em, rem, pixels, and viewport width.

However, percentage values are not allowed, "to avoid confusion about what it would be relative to". The vw value is recommended as an alternative if a relative value is needed.

Putting it Together #

Putting the media condition and width together -

<img src="one.png"
     srcset="two.png 100w, three.png 500w, four.png 1000w"

     sizes="(min-width: 900px) 1000px,
            (max-width: 900px) and (min-width: 400px) 50em,
            ( not (orientation: portrait) ) 300px,
            ( (orientation: landscape) or (min-width: 1000px) ) 50vw, 
            100vw">

If the media condition is true, the user agent will choose what image to serve at the size specified based on the different images defined in the srcset attribute.

Support #

The srcset and sizes attributes are relatively well supported.

For browsers that do not support the attributes, the image is fetched from the regular src attribute and displayed normally across all media conditions.

Creating an Embed for CanIUse

2016-01-26T00:00:00Z

Like a lot of developers, I use caniuse a lot. Additionally, because of this blog, I frequently reference support for particular features and wanted a way of providing up-to-date information from caniuse within a post.

So, I decided to create an (unofficial, but with permission) embed for caniuse. For example -

Create an embed | View on Github

Creating the Embed #

Having never done something like this before, here is how I created this embed.

1. Hosting the Embedded Document #

The embed is an iframe that loads a particular document. This document is hosted via Github Pages at -

https://caniuse.bitsofco.de/embed/index.html

This url accepts 2 parameters -

feat - the ID of the feature on caniuse
periods - The browser versions to display, e.g. current, past_1, future_1 etc.

For example, for the "CSS 2D Transforms" feature above, the embed is hosted at -

https://caniuse.bitsofco.de/embed/index.html?feat=transforms2d&periods=future_1,current,past_1,past_2

2. Getting the Relevant Data #

The caniuse data is made publicly available in raw json format with a CC BY 4.0 licence. Performing an XMLHttpRequest on full data file, we get the following object returned -

{
  agents: Object // List of browsers
  cats: Object // List of categories
  data: Object // List of features
  eras: Object
  statuses: Object
}

Based on the featured ID that was passed through the URL, we can get the relevant feature data -

var featureID = location.href.split('?feat=')[1],
    featureID = featureID.split('&periods=')[0];

loadJSON(caniuseDataUrl, function(res) {
  var feature = res.data[featureID];
});

We now have the feature object with the following information -

{
  categories: Array[1]
  chrome_id: "6437640580628480"
  description: "Method of transforming an element including rotating, scaling, etc. Includes support for `transform` as well as `transform-origin` properties."
  firefox_id: ""
  ie_id: "transforms"
  keywords: "transformation,translate,rotation,rotate,scale,css-transforms,transform-origin,transform:rotate,transform:scale"
  links: Array[7]
  notes: "The scale transform can be emulated in IE < 9 using Microsoft's "zoom" extension, others are (not easily) possible using the MS Matrix filter"
  notes_by_num: Object
  parent: ""
  spec: "https://www.w3.org/TR/css3-2d-transforms/"
  stats: Object // Support data for each browser
  status: "wd"
  title: "CSS3 2D Transforms"
  ucprefix: false
  usage_perc_a: 0
  usage_perc_y: 91.38
  webkit_id: ""
}

Once we have the relevant data, it just needs to be displayed in the document and styled appropriately.

3. Using a Placeholder for the Embed #

To actually display the embed in an HTML document, you use a placeholder. For example -

<p class="ciu_embed" data-feature="transforms2d" data-periods="future_1,current,past_1,past_2">
  <a href="https://caniuse.com/#feat=transforms2d">Can I Use transforms2d?</a>
  Data on support for the transforms2d feature across the major browsers from caniuse.com.
</p>

By using a placeholder, we are able to provide a fallback (the content within the <p> tags) for situations where an iframe can't be loaded.

For example, if you're reading this article via the email newsletter, I used an image of the embed as the fallback instead of just text.

4. Loading the Embedded Document #

Finally, to swap the placeholder for the actual iframe, I created a small script, which should be loaded onto any page with the embed.

<script src="https://caniuse.bitsofco.de/caniuse-embed.min.js"></script>

This script does a few things -

Finds all elements with the class ciu_embed and swaps the fallback content with the iframe.
Determines what feature to load from the data-feature attribute and adds the relevant ID to the feat parameter
Determines what browser versions to display from the data-periods attribute and adds the relevant information to the periods parameter
Calculates the correct sizing of the <iframe> responsively depending on the contents

You can view the source for the embed on github or visit caniuse.bitsofco.de to create an embed to use yourself.

The Effect of Importance and Origin on CSS Specificity

2016-01-19T00:00:00Z

When we think of the cascading nature of CSS, we usually think of specificity. Rules that are applied to an ID override rules that are applied to a class. However, specificity is not the only factor taken into account when determining which of two conflicting rule declarations should prevail.

According to the W3C Recommendation, there are 4 stages to cascade -

Find all declarations that apply to the element and property in question, for the target media type. Declarations apply if the associated selector matches the element in question and the target medium matches the media list on all @media rules containing the declaration and on all links on the path through which the style sheet was reached.

Sort according to importance and origin.
Sort rules with the same importance and origin by specificity of selector. More specific selectors will override more general ones. Pseudo-elements and pseudo-classes are counted as normal elements and classes, respectively.
Finally, sort by order specified. If two declarations have the same weight, origin and specificity, the latter specified wins. Declarations in imported style sheets are considered to be before any declarations in the style sheet itself.

Before the specificity of the rule is taken into account, the importance and origin of the rule is first considered.

Importance and Origin #

Declaration Origin #

The origin of the rule declared refers to where it comes from. There are three potential origins for a rule.

User agent - This is typically the browser. Browsers have their own “user agent stylesheet” with default styles. For example, in most browsers, a default style included is -

head {
  display: none;
}

Author - This refers to the person creating the website. The person who writes the HTML and CSS processed by the user agent. Styles written by the author are included either inline or by linking to an external stylesheet.

<p style=“color: red;">Lorem ipsum</p>

User - This refers to the person using the website. This person can include their own CSS to be used within a browser across all websites they visit. User defined styles are usually for accessibility concerns, for example -

p { font-size: 18px; }
a { text-decoration: underline; }

Declaration Importance #

The importance of the rule is whether it has been specified as important or normal. By default, all rules are considered normal until we specify them to be important.

A rule can be marked as important by using the !important rule -

p {
  font-size: 18px !important;
}

The Balance Between Importance and Origin #

Once the importance and origin have been determined, conflicting rules relating to the same element are sorted according to the following -

User agent declarations (lowest priority)
User normal declarations
Author normal declarations
Author important declarations
User important declarations (highest priority)

This means that only multiple rules with the same level of importance and origin will move to the stage of determining specificity. If a rule does not have competing rule of the same importance and origin, its specificity is not considered.

Take, for example, this paragraph.

<p class=“foo” id=“bar”>Lorem ipsum dolor sit amet.</p>

Example 1. If there is an !important rule defined in the user stylesheet, it will prevail over more specific rules in the author stylesheet.

/* user defined stylesheet */
p { color: orange !important; } /* this will prevail */

/* author stylesheet */
p { color: red; }
.foo { color: green; }
#bar { color: blue; }

Example 2. If there is an !important rule defined in the author stylesheet, it will prevail over more specific normal rules in the both stylesheets.

/* user defined stylesheet */
#bar { color: orange; }

/* author stylesheet */
p { color: red !important; } /* this will prevail */
.foo { color: green; }
#bar { color: blue; }

Example 3. If there are two conflicting normal rules, the one in the author stylesheet will prevail, even if it is less specific.

/* user defined stylesheet */
#bar { color: orange; }

/* author stylesheet */
.foo { color: green; } /* this will prevail */

Because user defined stylesheets are not particularly common, the origin aspect is something us, as authors, need to be concerned about less. However, if we ever need to write a user agent stylesheet, it helps to know how to write rules that can/cannot be overridden.

Labelling Form Elements

2016-01-12T00:00:00Z

One context in which providing the correct labels for elements can be crucial is in HTML forms. Because users are interacting with forms more directly unlike with some UI elements, it is important that each form widget - input, textarea, select etc. - is correctly labelled.

Depending on context, there are a number of ways to provide labels for form widgets.

The `name` and `id` attributes #

For most form widgets, it is important to include both name and id attributes.

The name attribute provides the label the form widget is referenced by when submitted with the form data.
The id attribute is used to reference the form widget when labelling using the <label for=""> element.

It is helpful to have both these labels be identical, so that the form widget is referenced in the same way on the front end as well as server-side.

<input type="text" name="username" id="username">

Besides the typical form widgets, it is useful to give the <form> element itself a unique name and/or id.

<form name=“myForm” id="myForm">
  <!-- form widgets -->
</form>

Besides providing a label for the form, it can be used to reference the form and check it's validity.

var myForm = $("#myForm");

myForm.validate(); // Check the form values
myForm.valid(); // Boolean value for if form is valid

The `<label>` element with the `for` attribute #

The <label> element (with the for attribute) is the most commonly used way of labelling form widgets. Using the for attribute, we can reference the ID of the form widget that the label is for.

<label for=“username”>Your Username:</label>
<input type=“text” id=“username” name="username">

We can also have multiple labels for one form widget.

<label for=“pwd”>Your Password:</label>
<input type=“password” id=“pwd” name="pwd">
<label for=“pwd”>Your password must be at least 8 characters long.

The `<label>` element as a parent #

Another way of using the <label> element is to simply make it the parent of both the form widget and labelling text. Using this method, we do not need to specify the label’s for attribute or the widget's id attribute.

All text within the element is taken as the label for the form widget.

<label>
  Your Password:
  <input type=“password” name=“pwd”>
  Your password must be at least 8 characters long.
</label>

The `<fieldset>` and `<legend>` elements for related widgets #

The <fieldset> element is used to group semantically related form widgets, and the <legend> element provides a label for the group. One common example of when this is used is when an address is broken up into multiple fields.

<fieldset>
  <legend>You Address:</legend>

  <label>
    Street Address
    <input type=“text” name="street_address">
  </label>

  <label>
    City
    <input type=“text” name="city">
  </label>

  <label>
    State
    <input type=“text” name="state">
  </label>

  <label>
    Country
    <input type=“text” name="country">
  </label>

  <label>
    Postal Code
    <input type=“text” name="postal_code">
  </label>
</fieldset>

Another great use for <fieldset> and <legend> is for radio inputs. Because each radio input has its own <label> element, we can’t use another <label> to group together the group of radio inputs.

As a solution, we can use the <fieldset> element to group all the radio inputs together, and the <legend> element as a label for the group.

<fieldset>
  <legend>Have you read the terms and conditions?</legend>

  <label>
    Yes
    <input type="radio" name="terms" value="yes">
  </label>

  <label>
    No
    <input type="radio" name="terms" value="no">
  </label>
</fieldset>

Using this method for radio/checkbox inputs is also great because some screen readers read the text within the legend before the label for each widget.

In the example above, a screen reader may read aloud “Have you read the terms and conditions? Yes” and “Have you read the terms and conditions? No" for each radio input.

The `label` attribute for `<optgroup>` #

The <optgroup> element may be the only form element that using a <label> or <fieldset>+ <legend> elements is not a practical way to label it.

Because of this, we have available the label attribute to provide a label for it.

<label for="colours">Choose a colour</label>

<select id=“colours” name=“colours”>
  <option>Black</option>
  <option>White</option>

  <optgroup label=“Primary”>
    <option>Red</option>
    <option>Yellow</option>
    <option>Blue</option>
  </optgroup>

  <optgroup label=“Secondary”>
    <option>Green</option>
    <option>Purple</option>
    <option>Orange</option>
  </optgroup>
</select>

The `aria-*` attributes #

For cases where, because of the structure of our HTML, we cannot use any of these typical methods, we can use one of the ARIA labelling attributes.

Use aria-labelledby to reference the ID of the labelling element -

<p id="username-label">Your Username</p>
<div>
  <input type="text" name="username" aria-labelledby="username-label">
</div>

Use aria-label to provide the label text itself -

<input type="text" name="username" aria-label="Your Username">

Use aria-describedby to reference the ID of an element that describes the form widget -

<p id="username-label">Username</p>
<p id="username-description">Your username must be at least 4 characters long.</p>
<div>
  <input type="text" name="username" aria-labelledby="username-label" aria-describedby="username-description">
</div>

You can read more about using these ARIA attributes in my article on HTML For Screen Readers

WTF Opera Mini?!

2015-12-22T00:00:00Z

According to StatCounter statistics, the global usage statistic for the Opera Mini mobile web browser is about 11.3%. However, in some developing countries such as Nigeria (where I live), this percentage goes up to 73%.

This is a huge problem.

It’s a problem because Opera Mini today is basically like IE 8. It has terrible support for a lot of development features we take for granted. For example -

2D transforms
@font-face Web fonts and, by extension, icon fonts
Basically any styling for fonts including line-height, text-decoration, and using font families not native to the OS

I only discovered this professional-life-altering fact about a week ago thanks to a friend, and it’s been seriously racking my brain ever since.

Although, as a developer, I personally dislike Opera Mini for this fact, there is a reason that people use it. For a particular kind of user, for example one with very limited data connection, it is very useful. Even though their experience may be diminished compared to if they were using a fully-fledged browser, all the feature-cutting works for their particular needs.

wtfoperamini.com #

So, I decided to create this site, wtfoperamini.com, which is a list of all the unsupported or partially supported development features on the Opera Mini mobile browser, and some crowdsourced workarounds for them.

Although this is directed at Opera Mini, I hope for it to be a useful resource for anyone practicing progressive enhancement or graceful degradation.

Workarounds #

The aim of WTF Opera Mini?! isn’t really Opera Mini bashing, but rather a way to crowdsource some workarounds people can use if they need to support the browser.

For example, a particular pain point for me was the lack of support for 2D Transforms. To align elements both horizontally and vertically, I frequently use this magical snippet -

.centered-element {
  position: absolute;
  top: 50%;
  left: 50%;
  -webkit-transform: translate(-50%, -50%);
  -ms-transform: translate(-50%, -50%);
  transform: translate(-50%, -50%);
}

.centered-element-parent {
  /* make sure parent is positioned e.g. relative */
}

This doesn’t work in Opera Mini because the transform property is not supported. So I’ve had to use different workarounds based on the situation. For example, one workaround is using tables and vertical-align -

.centered-element {
  display: table-cell;
  vertical-align: middle; /* vertical */
  text-align: center; /* horizontal */
}

.centered-element-parent {
  display: table;
}

Submit a Workaround #

If you have ideas for workarounds for this or other features, you can submit one yourself. Follow the instructions for contributing.

bitsofcode

When is :focus-visible visible?

1. Has the user expressed a preference for always visible focus? #

2. Does the focused element support keyboard input? #

3. Is the user interacting with the focused element with a non-pointing device? #

4. Did a script cause focus to move from a previously visibly-focused element? #

Bonus - User agent wildcard #

From Ghost to 11ty

Step 1 - Convert the Ghost export to markdown #

Step 2 - Organise each post into sub-folders #

Step 3 - Download media hosted on Ghost #

Step 4 - Use the 11ty Image Plugin #

Step 5 - Setup 11ty with eleventy-base-blog #

Permalinks #

Tags #

Post excerpts #

CanIUse Embed #

Set 6 - Run npm start and fix bugs #

Web Performance Metrics Cheatsheet

Four Questions #

1. Is it happening? #

Time to First Byte (TTFB) #

First Paint (FP) #

First Contentful Paint (FCP) #

2. Is it useful? #

Largest Contentful Paint (LCP) ⭐️ #

Visually Complete (VC) #

Speed Index (SI) #

3. Is it usable? #

First Input Delay (FID) ⭐️ #

Max Potential First Input Delay (mFID) #

Total Blocking Time (TBT) #

Time to Interactive (TTI) #

4. Is it delightful? #

Cumulative Layout Shift (CLS) ⭐️ #

Frame Rate #

The Cheatsheet #

Setting up a Decentralised Website (ENS + IPFS = dWeb)

A short intro to ENS, IPFS, and the dWeb #

How to publish a dWebsite #

1. Build your website #

2. Register an ENS name #

3. Upload your files on IPFS #

4. Link your ENS name to your website #

Redirecting an ENS name to an existing website #

Highlights from Chrome Dev Summit 2020

Simplified performance metrics with the "Core Web Vitals" #

New CSS properties for performance #

Shipping modern Javascript #

type=module #

Package exports #

Tabbed desktop PWAs! (& more) #

What I wish I knew about React

React is a library, not a framework #

What’s the difference between a library and a framework? #

What does that really mean? #

React is a UI library #

React component libraries are always for UI #

Components will update, whether you want them to or not #

useEffect is a major 🔑 #

How I created 488 "live images"

Step 1: Capture 488 images using Puppeteer #

Step 2: Upload 488 images to Cloudinary #

Step 3: Create URL redirects on Cloudflare #

Step 4: Deploy to Heroku and Schedule Daily Job #

Highlights from Chrome Dev Summit 2019

HTML is (finally) getting some 💕 #

Redesigned form elements #

Extensibility of form elements #

New elements? #

CSS is getting better too! #

The :is() selector #

Logical properties #

The web is coming for native #

Progressive enhancement through “adaptive loading” #

How to use Puppeteer in a Netlify (AWS Lambda) function

Puppeteer 101 #

Netlify functions 101 #

Putting it all together #

Gotcha 1: Puppeteer vs Puppeteer Core #

Set 6 - Run `npm start` and fix bugs #

`type=module` #

Package `exports` #

The `:is()` selector #

What’s the difference between `call()` and `send()`? #

What’s the effect of `call()` vs `send()`? #

`private` #

`internal` #

`external` #

`public` #

Creating the `budget.json` #

Enhancing the `abbr` element #

`self.skipWaiting()` to the rescue! #

The `[lang]` attribute selector doesn’t know the element’s language #

The `:lang` pseudo-class #

`:lang` and the "content language" #

`:lang` and nesting #