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

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 #