Forem: Claire Parker-Jones

CSS Transitions for Multiple Properties on One Element

Claire Parker-Jones — Wed, 27 May 2020 21:18:02 +0000

This caught me out recently so I thought it was worth documenting in a blog post.

How do you define a CSS transition for multiple properties on the same HTML element?

The CSS transition property defines the effect between two different states of an element. transition is a shorthand property, which means it combines other CSS properties in single declaration. The resulting shorthand is simpler to read and write. Other common shorthand properties are margin, background and font.

An example of applying a transition to every transitionable state on an element is:

.menu {
  transition: all 1s ease;
}

The transition property here includes definitions for transition-property, transition-duration and transition-timing-function. (We could also add transition-delay.) Using the shorthand saves us from writing out three separate declarations.

The example above sets a transition for every animatable property on the element. You may need to be more specific, for example only transitioning the font color:

.menu {
  transition: color 1s ease;
}

How do we extend this to transition both the font color and the margin, but with the same duration and timing function?

Even if properties share certain values, they can't be combined in the transition shorthand. Instead, write out each property declaration in full and comma separate each one:

.menu {
  transition: color 1s ease, margin 1s ease;
}

An alternative is to write single declarations instead of using the transition shorthand. The following code achieves the same effect as the previous example:

.menu {
  transition-property: color, margin;
  transition-duration: 1s;
  transition-timing-function: ease-out;
}

I've created this CodePen example illustrating both methods for adding transitions to an element where you can edit the code and experiment further.

How to Reverse Ordered List Counters in HTML

Claire Parker-Jones — Mon, 30 Mar 2020 20:56:35 +0000

An ordered list in HTML uses ascending numbers to display list items, beginning at number 1. The code:

<ol>
  <li>Don't Stop Me Now</li>
  <li>Under Pressure</li>
  <li>We Are the Champions</li>
  <li>Bohemian Rhapsody</li>
</ol>

produces the following list:

Don't Stop Me Now
Under Pressure
We Are the Champions
Bohemian Rhapsody

It's possible to reverse the order of the counters with only HTML - no CSS or JavaScript required!

Add a HTML attribute called reversed to the <ol> tag.

The same code as above, only now with the reversed attribute:

<ol reversed>
  <li>Don't Stop Me Now</li>
  <li>Under Pressure</li>
  <li>We Are the Champions</li>
  <li>Bohemian Rhapsody</li>
</ol>

produces a list with descending counters:

Don't Stop Me Now
Under Pressure
We Are the Champions
Bohemian Rhapsody

Note that this only reverses the sequence of the numbers, and not the position of the list items contained with the <li> tags.

Where could you use this technique? The only situation I can think of is in a countdown, and perhaps this is why I'd never encountered this attribute before!

The reverse attribute is supported in all modern browsers but has no support in IE. See the caniuse table for the reverse attribute for more details.

I've created a Codepen demo of the reverse attribute which you can play with below:

Styling list bullets with emoji

Claire Parker-Jones — Sat, 27 Apr 2019 08:51:40 +0000

The available styles of bullet points for HTML unordered lists <ul> are limited. Using CSS, they can be changed to something more exciting, like emoji! 🎉👯‍♂️✨

In this post, I'll show you two methods to replace them: @counter-style, which is concise and flexible (but your browser probably doesn’t support it), and the more tried-and-tested technique of using the ::before pseudo-element.

We will transform an unordered list with unstyled counters from this:

To this:

Note: the following code examples are written in Sass to utilise nesting, in order to keep them short.

Method 1: `@counter-style` at-rule

CSS at-rules are statements that instruct CSS how to behave, for example @import, @font-face or @media.

The @counter-style at-rule was proposed in order to provide more options and functionality to the existing set of bullet styles in HTML lists.

@counter-style is a level 3 proposal, at Candidate Recommendation stage, which means that the spec is stable enough to be implemented by browsers. However, as of April 2019 it is only supported by Firefox (caniuse stats for @counter-style). Example output in this post is provided as a image, although the code for all examples is available in the CodePen at the bottom of the page.

Counter-style rule example

To use counter-style, write a rule then declare is as the value of the list-style-type CSS property on a <ul> or <ol> tag. The syntax for a counter-style rule has several optional descriptors, as listed on the MDN documentation page. MDN also provide an interactive demo of different counter-style variants (best viewed in a supported browser like Firefox).

In order to replace the bullet points with an emoji, we need to give options to the "system", "symbols" and "suffix" descriptors. Choose the "cyclic" system and provide the unicode code points for the desired emoji symbols. Note that you need to use the unicode code point to represent the emoji rather than just the character, e.g. "\1F431" instead of 🐱. Find a complete list on the unicode website. Setting "suffix" to " " means that no other characters like a period appear after the counter.

The "symbols" descriptor can accept a space-separated set of symbols. Combined with the "cyclic" system option, this means that our final bullet points design will rotate through all provided symbols.

@counter-style repeating-emoji {
  system: cyclic;
  symbols: "\1F431" "\1F436" "\1F984"; // unicode code point
  suffix: " ";
}

// Add this class to the ul or ol element
.repeating-counter-rule {
  list-style-type: repeating-emoji;
}

Method 2: `::before` pseudo-element

This method can be used replace the standard discs with images, and not just emoji. The downside is that it doesn't provide the flexibility of @counter-style.

Begin by setting list-style: none on the parent list element, <ul> or <ol>, and then adjusting padding and margin for the list item elements <li>. The icon used for the bullet point is added using the ::before pseudo-element.

To replace the default discs with the same emoji, the following code could be used, where the single-before class is added to the <ul> element:

.single-before {
  list-style: none;
  padding: 0;
  margin: 0;

  li {
    padding-left: 1rem;
    text-indent: -0.7rem;
  }

  li::before {
    content: "🐻 ";
  }
}

In order to replicate the repeating pattern of three emoji bullet points from the counter-style example above, we need to use the :nth-child pseudo-class. For example, add the following .repeating-before class to a <ul>:

.repeating-before {
  list-style: none;
  padding: 0;
  margin: 0;

  li {
    padding-left: 1rem;
    text-indent: -0.7rem;
  }

  li:nth-child(3n+1)::before {
    content: "🐱 ";
  }

  li:nth-child(3n+2)::before {
    content: "🐶 ";
  }

  li:nth-child(3n)::before {
    content: "🦄 ";
  }
}

Although initially straightforward, this method can become more complex depending on the pattern of emoji to be implemented. However, this technique has the benefit of being well-supported across browsers.

Conclusion

The @counter-style at-rule provides a lot of flexibility when styling list counters, but its limited browser support makes it unsuitable for most production sites. Using pseudo-elements is reliable but cumbersome for more intricate layouts. However, if the style of list bullets is an optional design feature rather than a critical part of the page design, then consider combining @counter-style with the @supports at-rule and provide an acceptable fallback design, perhaps using pseudo-elements.

Emoji Bullet Point CodePen Example

My Misconceptions about the Universal Selector in CSS

Claire Parker-Jones — Sun, 21 Apr 2019 22:50:54 +0000

The asterisk * is known as the universal selector in CSS. It matches all elements of any type.

* {
    color: red;
}

This example would change the colour of all the text on the page to red (as long as there wasn't a more specific rule applied to the element).

I don't often use the universal selector, because I assumed that selecting everything would be bad for page performance and difficult to override. After some research, I proved wrong some misconceptions I had about both the universal selector and my understanding of CSS.

`*` has a specificity of 0

Misconception 1: the universal selector has a high specificity. ❌ Wrong! The specificity of * is zero. In fact, quoting MDN's article on specificity:

Universal selector (*), combinators (+, >, ~, ' ', ||) and negation pseudo-class (:not()) have no effect on specificity.

Therefore, a rule that only uses the universal selector, like * { color: red }, can be overridden by a single element, class or ID selector.

Estelle Weyl's specifishity page is a great visual guide to understanding CSS specificity.

`*` is inefficient in terms of performance

Misconception 2: the universal selector performs badly compared to other selectors. ✅ I was right about this one.

When talking about CSS selector performance, Steve Souder's work is often quoted, particularly his book Even Faster Websites and popular blog post about CSS selector performance both from 2009. He has a handy CSS test creator on his website for measuring the performance of CSS selectors. The universal selector is one of the worst performers, alongside attribute selectors (like [href="#"]) and pseudo-classes and pseudo-elements (like :hover). IDs and classes are the best for speedy performance. (Harry Roberts summarises the results in a list in this post about efficient CSS selectors from 2011.)

However, these results are for when you use a single selector alone, and not in combination with any others. You can still write inefficient CSS selectors without *. Using lots of child or descendent selectors is one way to achieve this, e.g. div > ul li > a { color: red; }

CSS selectors are read from right to left by the browser ⬅

Misconception 3: browsers process CSS selectors from left to right, in the same order that I would read them. ❌ I was wrong about this which surprised me!

One of these rules runs faster than the other:

/* A */
#id > *.

/* B */
* > #id {
    color: red;
}

The browser checks the rightmost selector first before moving left. Therefore, selector B is quicker, since the matching elements are narrowed down to those matching the ID, instead of every element in the document like in A.

Therefore, when writing selectors, it's best to put something performant like a class or ID at the end.

CSS Selector Performance matters

Misconception 4: it's important to focus on CSS selector efficiency for page performance. ❌ As I read more and more about this subject, the overriding opinion was that selector performance isn't something to worry about. Steve Souder even said as much in the first paragraph of the aforementioned blog on CSS selector performance. This was written 10 years ago, and since then our browsers have become much more powerful.

However, I still wouldn't recommend writing very overqualified selectors, e.g.

div a [type="text"] .foo #bar {
    color: red;
}

Not because of performance (although this will be inefficient) but because it implies that your DOM is structured badly, and CSS written like this will be hard to maintain and override. Instead, write selectors that match on ideally one class.

Would I use `*`?

The universal selector isn't one that I reach for often, but it can be useful. It's common to see browser-reset type selectors like:

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

The universal selector can also be useful to select all children of an element, or in cases where you don't have direct control over the structure of the page, e.g.

.class > * {
    color: red
}

Now I understand how it works more, I wouldn't be afraid to use *, particularly just for page performance concerns. In a world of weighty hero image PNGs, bloated JavaScript bundles and sluggish API calls, there are more strategic parts of a website to optimise for bigger performance gains.

Instead, if I did need to use the universal selector, I would evaluate the reason: could this CSS be written in a clearer more maintainable way? Or could the page structure could be refactored to make it easier to target the required elements?

Do you use the universal selector often or do you avoid it?

Header image by Jeremy Thomas on Unsplash.

Ignoring Prettier

Claire Parker-Jones — Sun, 14 Apr 2019 19:21:20 +0000

Prettier is an "opinionated code formatter". Quoting the docs:

It removes all original styling and ensures that all outputted code conforms to a consistent style.

It's commonly used in JavaScript projects, and also offers plugins that support other languages. Prettier can be run through its CLI, or even automatically through your code editor each time you hit save.

Allowing Prettier to be responsible for how your code is formatted is a huge timesaver, especially when working in teams where code reviews can turn into passive-aggressive discussions about indentation and line-length. Instead, you can focus on what your code does rather than what it looks like.

How to make Prettier ignore your code

However, there's always an edge-case: that one time you don't agree with how Prettier lays out your code. Is it possible to turn Prettier off in some cases?

Yes there is! There's an entire page of documentation that explains how.

Prettier can be turned off in several different ways. You can:

ignore single lines in a file
ignore several lines in a file
ignore whole files
- specific one-off files (e.g. my-template.html)
- entire file-types (e.g. *.html)

Depending on the issue, it may be solved by changing the configuration for Prettier instead of just ignoring sections of code. Preferences for trailing commas or double quotes can be changed via CLI and API options. However, Prettier purposely ships with minimal customisable options, since the rationale behind the package is to remove many of the discussions and choices around code style.

Should you use prettier ignore options?

One of the central reasons for using Prettier is to surrender any decisions on code style to it. After making the initial config decisions for semicolons, trailing commas, etc, Prettier handles everything else related to code formatting, even if you don't like the way the tool formats a couple of lines.

If you do setup Prettier to ignore a section of code in order to circumvent a particular formatting style, don't forget that you lose all of Prettier's powers on that code. There's no way to selectively tell Prettier to ignore the indentation for your nested ternary statements in this function, but still enforce the bracket spacing as per the rest of the file.

If you really want Prettier to ignore a line of code, I suggest leaving a comment in your code explaining why. For example, in the code below, Prettier will remove the brackets by default:

// Reason: more readable with brackets
// prettier-ignore
const totalThings = (widgets * 3) + (fizzbobs * 5);

It might not pass code review with the rest of your team, but at least you've given a reason!

Do you have any cases where you use prettier-ignore? Or do you go with the flow and let Prettier decide?

Header image by Markus Spiske on Unsplash.

Why my Hugo Archetypes didn't work

Claire Parker-Jones — Mon, 01 Apr 2019 13:12:27 +0000

A short story about Hugo template files and Markdown file extensions.

Brief overview of archetypes in Hugo

The current version of my personal blog is built with Hugo, a static site generator. Hugo has the concept of archetypes, which are template files used to create new content types with the hugo new command. It saves you having to copy and paste customised front matter (the YAML, TOML or JSON data at the top of the file) or other custom content every time you create a new post.

Each content type in your Hugo site can have its own archetype template. For example, on my site I create standard blog posts and also custom diary style posts, as content types blog and dev-diary. When I type the command hugo new dev-diary/example-post.md I want the file created to have different YAML fields than one created with hugo new blog/example-post.md

The previous version of my blog was built with Jekyll, and I built my own Yeoman generator in order to achieve the same result as Hugo's archetypes feature (plus it was a fun side-project). Archetypes have been a lot simpler to work with than a hand-made Yeoman generator, except for this one problem I was having.

The issue

I dutifully followed the instructions to create an archetype file from Hugo’s docs and added it in the archetypes directory of my site, so it looked like this:

archetypes
├── default.md
└── blog.md

I used the command hugo new blog/post.markdown but my new "blog" archetype wasn't being used. Instead, the new post used the "default" archetype. I was intermittently having success with it using different filenames but couldn’t work out why. I thought using the "-kind" flag helped but it turned out to be a red herring. I abandoned custom archetypes for a time, although still checked my broken attempts into my blog site repo (because why not?).

The facepalm moment 💡

I recently renamed one of my content types (interesting to dev-diary) and changed the format of my filenames and magically my archetypes began working! But why?

The markdown file extension of my new content file wasn’t matching the extension of the archetype 🤦‍♀️

By using the command hugo new blog/post.markdown, the blog archetype wasn't being invoked correctly, because it had a different file extension to the template file, i.e. archetypes/blog.md. The mismatch between ".markdown" and ".md" extensions caused the archetypes to fail.

Instead I needed to use hugo new blog/post.md and match the markdown file suffixes.

Both ".markdown" and ".md" are valid extensions for Markdown files and I use them interchangeably. Perhaps the ".markdown" extension isn't intended to work with archetypes as a conscious design choice from the Hugo team, but this definitely stumped me for a while!

Using email newsletters to stay up-to-date with frontend development

Claire Parker-Jones — Tue, 26 Mar 2019 14:57:54 +0000

Modern frontend web development can be a vast and overwhelming subject at times. New frameworks and best-practices come and go in quick succession. Keeping up with the latest trends, libraries and version updates can be exhausting and time-consuming. How can you stay ahead of the curve?

The most successful method for me is to subscribe to weekly round-up emails about development.

I receive several newsletters once a week, which contain topical links related to their subject, e.g. CSS, JavaScript or web accessibility. There are links to blog posts, GitHub repos, conference talk videos, code demos, etc. These weekly newsletters contain a digestible portion of information that helps me stay well-informed on the current state web development.

Current subscriptions

As of March 2019, I subscribe to:

Note that many of these are published by Cooper Press, who run even more newsletters #notsponsored.

My subscriptions have varied over the years depending on my current job or favourite technologies at the time. Not every email or subject area is directly relevant to my coding day-job responsibilities, but together this selection gives me a good overview of the areas I'm interested in as a frontend developer.

Why newsletters?

Newsletters provide me with a curated list of relevant information that I can consume at my own pace. A round-up email like this contains approximately 10 to 30 links. Just like I wouldn't open every Google search result, I don't click through every link, but instead skim-read the email and choose a few choice items to open. This way I get a good overview of what's happening that week, while learning about subjects that interest me in more detail. I normally do this on my laptop rather than my phone, which makes reading code snippets or exploring GitHub repos easier. It also means I can have several tabs open at a time with articles I want to read later!

Since I subscribe to a lot of mailing lists, their emails can pile up quickly in my inbox. It's important to make time to open them each week, but understand I don't have time to read about everything. Even using newsletters, the quantity of info can still be overwhelming, so it's important to learn to skim-read and not feel guilty about skipping some posts or deleting older emails to keep my inbox relatively empty.

If you don't already, I definitely recommend subscribing to a couple of weekly newsletters related to your current tech stack, to see if this format helps you. You might find Twitter or listening to podcasts works better for you, but round-up emails like this are another useful option in the never-ending quest to keep up-to-date with web development trends.

Let me know your own favourite dev-related mailing lists! 📨

The difference between dependencies and devDependencies in a JavaScript project

Claire Parker-Jones — Wed, 13 Mar 2019 09:12:07 +0000

When you use npm to install a package to your project with the command npm install <package-name>, the name and version of the package appears in the project's package.json file under the “dependencies” key. For example, npm install react will look write something like this to the file:

{
    ...
    "dependencies": {
        "react": "^16.8.4",
        ...
    }
    ...
}

The code for the package will be installed in the project's local "node_modules" folder.

(Note: with older versions of npm, the --save or -S flag was required in order to write the package to the "package.json". The latest version of npm at time of writing is 6.9.0).

The list of packages in "package.json" is used by npm when your app is installed from scratch. Alongside the "package-lock.json" file, it ensures that the packages used in your app are a consistent version.

It's also possible to add packages under the "devDependencies" key in "package.json". Instead, add the --save-dev or shorter equivalent -D flag when installing, for example:

npm i -D jest

What is the difference between devDependencies and dependencies?

dependencies

"dependencies" are packages required to run the application in a production-ready environment. Without these packages, your app won't work. A couple of general examples are:

frameworks: React, AngularJS, Vue.js
utility libraries: lodash, Ramda, date-fns, polished

devDependencies

"devDependencies" are required to develop and build your app, but are not needed to run the final version that customers will use. For example:

testing libraries: Jest, Mocha, Jasmine
linters: ESLint, Prettier
transpilers: webpack, Babel (since production-ready code is already transpiled and minified)

When you run npm install in the root of a project with a "package.json" file, all packages in both dependencies and devDependencies are installed. This is because you're working with the source code, so probably need the code in every package to develop it. However, if you only want to install the packages listed under the dependencies key, then use the —-production flag, like npm install --production.

In conclusion, when deciding where a package should sit in the "package.json" file, ask yourself whether the package is required for the app to work in the final, production-ready version. If it's not, add it to the devDependencies object, otherwise, it belongs in dependencies.

Do you have any other examples? Let me know!

For more information, see the official npm documentation page for the npm install command.

Equivalent Yarn commands

If you use yarn as your package manager instead of npm, the equivalent commands mentioned in this post are:

npm	yarn
npm install	yarn install
npm install react	yarn add react
npm i --save-dev react	yarn add --dev react
npm i -D react	yarn add -D react

How to prevent pasting into input fields

Claire Parker-Jones — Wed, 30 Jan 2019 22:00:34 +0000

Edit 01/02/19: I was frustrated by yet another web form that wouldn’t let me paste my password into the Confirm Password field, wondered how it was done and decided to write about it. My intention with this post was to remain unbiased about whether you should or should not do this, and to encourage you to make your own decision. However, I also strongly encourage you to read the discussion below this post, as it clearly shows how unwanted and unnecessary this feature is.

Thank you to the Dev community members for all of your comments and feedback and for making this site such a positive part of the internet!

In some forms, the “Confirm email address” or “Confirm password” fields don't allow users to paste text into them. The idea is to make users type their email or password twice to help catch any typos they might have made in those important "Email" and "Password" values.

How is this functionality achieved? How can you stop your users from pasting content into a HTML input field?

We can use JavaScript to target an input field’s paste event and change how it works:

<input type="text" id="no-paste" />

<script>
  const pasteBox = document.getElementById("no-paste");
  pasteBox.onpaste = e => {
    e.preventDefault();
    return false;
  };
</script>

This code cancels the default behaviour of the paste event (i.e. pasting the contents of the clipboard into the input element). When the user tries to paste content into the field, using either a keyboard shortcut or context menu, nothing will happen.

Try it out in the CodePen example below:

There are also events for the cut and copy action.

There is good support for the paste event in modern browsers. These events are part of the Clipboard API. The Clipboard API also includes accessing the contents of the clipboard, which has varying levels of support. See the caniuse table for the Clipboard API for more information.

Should you disable the paste function?

Now you know how to change the expected behaviour of the paste event in your webpage, the question is whether you should. The answers to this StackOverflow question about the paste event discourage developers from tampering with default browser behaviour. The posters argue against changing expected browser behaviour because it will confuse users. Additionally, if the user decides to copy and paste data into a form field at the risk of it containing typos, then we should allow them to do this.

Each website is different, so there is no definitive answer. It's a good idea to consider questions like this when building your site in order to provide the best experience for your users.

How to Create a Polka Dot Background with CSS

Claire Parker-Jones — Mon, 14 Jan 2019 21:59:47 +0000

TL;DR

This post explains how to produce this design using CSS:

It can be created with only a single HTML tag and these background-related CSS properties:



body {
  background-image: radial-gradient(#212121 20%, transparent 20%),
      radial-gradient(#fafafa 20%, transparent 20%);
  background-color: #e53935;
  background-position: 0 0, 50px 50px;
  background-size: 100px 100px;
}

Below is an explanation of how this works, or you can experiment with the code directly in this CodePen example:

Step 1 - make a circle

Let’s begin by using CSS to display a single circle.

Use a radial-gradient as a background-image to create a circle shape. Give the gradient with two colors with identical color-stop values. The color-stops create the sharp border between the two colors, instead of a faded gradient effect. A color-stop can be a percentage between 0% and 100%, where 0 is the centre of the gradient and 100% is the edge.

Give the container element equal height and width to make the circle display nicely. If the element isn’t a square then the circle will appear warped.

At this stage, the CSS will look like this:



body {
    background-image: radial-gradient(#212121 20%, #e53935 20%);
    height: 100px;
    width: 100px;
}

Result:

Note: I'm using the body tag to apply the styles to because it's the simplest tag to demonstrate the effect in a new webpage. This may not be suitable for your use-case, so replace body as necessary with another CSS selector - just don't forget to give it a height and width.

Step 2 - make the circle repeat

Position the circle image in the top left of the background with the background-position: 0 0 property. The two values represent the x and y coordinates in pixels. We can omit the px value, because in CSS, 0 pixels (or ems, or %, etc) is the same as saying 0.

Give the image a set size of 100px by 100px with the background-size property.

Set the height and width of the body container larger than the background-size so that we can see the repeating effect of our image. The CSS will now look like this:



body {
  background-image: radial-gradient(#212121 20%, #e53935 20%);
  background-position: 0 0;
  background-size: 100px 100px;
  height: 200px;
  width: 100%;
}

Result:

At this point you might ask, why is the image repeating? We haven't set any properties explicitly in the CSS to do this.

There's another background-related property called background-repeat. The default value for this property set by the browser is repeat, which makes the background-image automatically repeat along both the x and y axes without us having to set it. Since the containing element (the body tag) is now larger than the 100px by 100px circle background-image, the circle is duplicated in the remaining space.

If we wanted the circles to stop repeating, we could change the value to background-repeat: no-repeat.

Step 3 - add a diagonal row

Add a second radial gradient to the background-image property by separating them with commas. I've given the second gradient a different colour for the circle to make it stand out.

Change the second color of each gradient to transparent, and set the background-color of the element explicitly. This is in order to see the new row of dots - otherwise it would be hidden behind the first one.

Now we have two gradients, we can give them each different background-position values, again separated by commas. By giving the new row values that are half of the background size (50px), we create the diagonal spacing effect. The final CSS will look like this:



body {
  background-image: radial-gradient(#212121 20%, transparent 20%),
     radial-gradient(#fafafa 20%, transparent 20%);
  background-color: #e53935;
  background-position: 0 0, 50px 50px;
  background-size: 100px 100px;
  height: 200px;
  width: 100%;
}

Final result:

Voilà, polka dots in CSS. You could change the size of the circles, the colors, or even add another row at a different position to create more complex effects.

A note on `background` and shorthand

The background CSS property is shorthand for multiple background- prefixed properties. You may have used other CSS shorthands, such as font, margin or border. In this example, I've used individual properties such as background-image and background-color instead of the shorthand. This is because:

it's easier to see what's happening in the individual properties instead of trying to work out what each value means in background
when using shorthand, it's easy to accidentally overwrite other properties and cause bugs, since you don't explicitly declare properties (for this reason I always use background-color instead of background)
when setting multiple backgrounds it's easier and not always possible to do so with the shorthand

Sometimes a shorthand can be useful, like margin: 10px 30px 20px 5px, but with less-common ones like font and background, I recommend using individual properties so that you can be sure of what's happening in your code.

Making the Alt Key Work in iTerm2

Claire Parker-Jones — Mon, 15 Oct 2018 21:13:26 +0000

iTerm2 is a replacement for the default Terminal application on MacOS. It has many more handy features than Terminal, is free to download and is also open source 🎉.

However, on initial install, you can’t use the Option or Alt key (the one that looks like this: ⌥) as you would in other applications: it's not possible skip or jump over words by pressing Alt and the left or right keys. Instead you see sequences like [D or [C:

This can be changed by tweaking a couple of settings, which I'll explain below.

Note: I refer to the "Alt" key throughout this post, as this is the text written on the key of my old 2013 MacBook Pro keyboard, but this is normally called the "Option" key in MacOS.

Open the "Preferences" menu: either find it in the "iTerm2" dropdown menu along the top of the screen or press the Command and comma keys. ⌘ + ,

Choose the "Profiles" menu.

Select the "Keys" tab.

Within the "Key Mappings" pane, find the mapping for the Alt and left keys, which will look like this: ⌥←. Double click it.

Change the action from "Send Hex Code" to "Send Escape Sequence" (you might have to scroll a bit to find this).

In the "Esc +" field, type lowercase "b" and click "OK".

Open the same context menu for Alt plus right ⌥→ and again change the action to "Send Escape Sequence".

This time, in the "Esc +" field, type lowercase "f". Click "OK".

Close the Preferences menu. The changes take effect immediately. When you press ⌥ + → or ←, the cursor will jump over entire words as it does on other applications. You can now navigate the command line with more precision and speed.

Bonus shortcuts

Control + e will move the cursor to the end of the line.

Control + a will move the cursor to the beginning of the line.

Quickly Switching Between Two Branches in Git

Claire Parker-Jones — Fri, 08 Jun 2018 12:51:19 +0000

git checkout - checks out the last branch you were working on.

Do you find yourself needing to switch between the same two branches in git again and again? There's a shortcut for that in the terminal!

Instead of typing out the branch name manually each time, substitute the name with the hyphen character -.

Note: In the gif, I'm using the Bash shell in iTerm2 on a Mac.

If you can't see the gif, here's a text representation, where the line with the dollar $ represents the command prompt:

[~test-directory] | first-really-long-branch-name $ git checkout second-super-long-branch-name
Switched to branch 'second-super-long-branch-name'

[~/test-directory] | second-super-long-branch-name $ git checkout -
Switched to branch 'first-really-long-branch-name'

[~/test-directory] | first-really-long-branch-name $ git checkout -
Switched to branch 'second-super-long-branch-name'

[~/test-directory] | second-super-long-branch-name $

This shortcut can save keystrokes when toggling between two branches.

It can be helpful when you're working on branches with long names, or your branches have similar names, making autocomplete not as helpful as it could be (e.g. feature-1123, feature-1124).

P.S.

Speaking of autocomplete in git, here's how to install it for the Bash shell, if you don't already have it set up. This provides the ability to type a couple of characters and press tab to autocomplete the rest of the command (or see all possibilities if there's more than one match).

P.P.S.

The same trick can be used to navigate between two directories in the terminal. Try typing cd - at the command prompt and the current directory will change to the one you were in last:

[~/test-directory] | master $ cd /a/long/subdirectory/path

[~/test-directory/a/long/subdirectory/path] | master $ cd -

[~/test-directory] | master $