These snippets are my attempt to save and organize various bits of code, best practices, and resources relating to web development and design. They also function as a to do list of sorts, for things I want to implement in my own code, but haven't yet. The concept is inspired by Jeremy Keith's links and CSS-Tricks, among other things. Enjoy.

Print style tips from Jeremy Keith

I really wanted to make sure that the print styles for Resilient Web Design were pretty good—or at least as good as they could be given the everlasting lack of support for many print properties in browsers.

Here’s the first thing I added:

Code language: CSS

@media print {
  @page {
    margin: 1in 0.5in 0.5in;
    orphans: 4;
    widows: 3;

That sets the margins of printed pages in inches (I could’ve used centimetres but the numbers were nice and round in inches). The orphans: 4 declaration says that if there’s less than 4 lines on a page, shunt the text onto the next page. And widows: 3 declares that there shouldn’t be less than 3 lines left alone on a page (instead more lines will be carried over from the previous page).

I always get widows and orphans confused so I remind myself that orphans are left alone at the start; widows are left alone at the end.

I try to make sure that some elements don’t get their content split up over page breaks:

Code language: CSS

@media print {
  p, li, pre, figure, blockquote {
    page-break-inside: avoid;

I don’t want headings appearing at the end of a page with no content after them:

Code language: CSS

@media print {
  h1,h2,h3,h4,h5 {
    page-break-after: avoid;

But sections should always start with a fresh page:

Code language: CSS

@media print {
  section {
    page-break-before: always;

There are a few other little tweaks to hide some content from printing, but that’s pretty much it. Using print preview in browsers showed some pretty decent formatting. In fact, I used the “Save as PDF” option to create the PDF versions of the book. The portrait version comes from Chrome’s preview. The landscape version comes from Firefox, which offers more options under “Layout”.

For some more print style suggestions, have a look at the article I totally forgot about print style sheets. There’s also tips and tricks for print style sheets on Smashing Magazine. That includes a clever little trick for generating QR codes that only appear when a document is printed.

`font-display`, a CSS alternative to JavaScript font loading

The font-display property is landing in browsers, and this is a great introduction to using it:

If you don’t know which option to use, then go with swap. Not only does it provide an optimal balance between custom fonts and accessibility of content, it provides the same font loading behavior that we’ve relied on JavaScript for. If you have fonts on the page that you’d like to have load, but could ultimately do without, consider going with fallback or optional when using font-display.

Until it’s more widely supported, you can continue to use a JavaScript solution, but even then you can feature detect first:

Code language: JavaScript

if ("fontDisplay" in === false) {
  /* JavaScript font loading logic goes here. */

Multi-line Padded Text with the CSS box-decoration-break Property


I love stumbling upon CSS properties in time of great need. Recently, I was working on a personal project, and I wanted to have multi-line highlighted text. My requirements were pretty simple from a design point of view:

  1. Text should be highlighted, i.e. have a background colour
  2. Highlights should only cover areas where there is text
  3. Each line should have a little left and right padding so that the text isn’t flush against the highlight box

My desired HTML was something like this:

Code language: HTML

<span>Hello, this is a long string of text that spills onto many lines</span>

And the desired output something like this:


If I used it as is, the output would look something like this:


So, how can we solve this? Luckily, CSS has thrown us a piece of candy in the box-decoration-break property. Let’s take a look.


Here’s an excerpt from the MDN:

The box-decoration-break CSS property specifies how the background, padding, border, border-image, box-shadow, margin and clip of an element is applied when the box for the element is fragmented. Fragmentation occurs when an inline box wraps onto multiple lines…

Basically, this property is giving us a bit more granularity in how an inline element gets rendered. By default, it’s set to slice, which means that it treats the inline box as if it weren’t fragmented at all. I like to think of it like this. Imagine that we took that multi-line inline element, stretched it out onto one line, applied the styling, sliced it into pieces, then moved each piece back to a new line. The result would be that the properties mentioned above would act on the entire box of the element, rather than each of its parts.

However, there is a second option for us, and that is:

Code language: CSS

box-decoration-break: clone;

When we set the property to clone, we can imagine a similar scenario as above, except one important thing. This time, let’s imagine that all the styles get applied after the element gets fragmented and distributed on multiple lines. In other words, paddings, borders, etc would be applied to each fragment almost as if they were separate elements.

That’s pretty awesome, and with one simple property, we’ve unleashed a ton of possibilities! Here’s a CodePen link with various demos for you to play around with.

10 things I learned making the fastest site in the world

Most of this post is really useful (and also hilarious), but these stand out as possibly super helpful:

So, this is what I wanted to happen:

  • Start downloading the data as soon as possible (without blocking the HTML).
  • Start downloading the app’s JavaScript as soon as possible (without blocking the HTML).
  • When both the script and the data are downloaded, and the HTML has been parsed, run the script which will breath life into the page.

I could have done all sorts of fancy footwork in JavaScript to get this working, but I have a better solution. Well, it works, but I have a nagging feeling I’m doing something [ableist slur].

Browser experts get your magnifying glasses out…

  • In the <head> I have a <link rel="preload" … > for both the JSON and and the JS (I have prefetch as well for browsers that don’t support preload yet)
  • At the end of the body I load the application JS in a regular <script> tag.
  • When the JS executes, it’s does a fetch() for the JSON file, and .then() kicks off the rendering of the React app.

That looks something like this.


Once any asset is on the way down, further calls to download it won’t go out to the network. The network calls look like this:


So unless I’m wrong, I see no reason to not preload everything at the top of the page.

Portier - an email-based, passwordless authentication service that you can host yourself

Portier (pronounced “Por-tee-ay”) is a self-hostable login service that you can use instead of passwords. Portier sits between your website and third-party services like Google Sign-In to provide your users the fastest and easiest login experience, without ever needing a new password.

Best of all, Portier works for everyone, because it can fall back to traditional “click the link” methods of email confirmation.

  • Email-first: Email addresses are decentralized, self-hostable, and useful on their own, so Portier uses email addresses instead of usernames to identify users.

  • Connected: Whenever possible, Portier integrates with major APIs like Google Sign-In to provide seamless, in-browser identity verification.

  • Decentralized: Anyone can host their own Portier Broker; there are no centralized dependencies.

  • Open and Transparent: Because Portier uses email addresses, there is never any lock-in.

Portier is inspired by many projects and considers itself a spiritual successor to Mozilla Persona.

In the detail: close button (or how to style a close button using a font for the icon)

There’s a × character in most common fonts which you should use instead of an x for close, but getting it to look right across devices requires an eye for the detail.

Here’s a screenshot of the simulator vs. the real device, with exactly the same CSS applied to create the effect. Notice that the vertical align is off?


It took me a while to work out what was different, but it’s the font. The font I’m using (if you’re on a Mac - as I was), is Helvetia Neue, but my Android doesn’t have that font, so it was falling back to the next default (possibly set as sans-serif, which could be Open Sans, or it could be something else). In this case, the different font had a slightly different letter height, so it caused (obviously) as slightly different result.

The pro tip: make sure to use a common font, probably Arial (IHMO ideally a font that doesn’t need to be downloaded) for button icons.

Yes, I know this is obvious if you’re using an icon font…but maybe not immediately obvious if you’re re-using system fonts.

Accessibility: Allow users to control their environment

Opening links in a new window [or tab] allows users to explore related materials without losing contact with the originating site; removing link underlines makes pages cleaner and easier to read because underlines are distracting and interfere with letterforms; and creating fixed-width pages restricts line length so users are not forced to read long lines of text. However, each decision has the potential of causing usability problems for some users: When links open in a new window, users who rely on the back button to navigate the Web will not have access to that functionality; when links are not underlined, users who cannot distinguish colors may not be able to identify links; and when pages are set to a fixed width, users who need to enlarge text will be forced to read narrow text columns.