Daily Tips & Tricks for Web Enthusiasts

Get new tips and tricks in your inbox every week!

You can also follow @CoreAssistance on Twitter (where I tweet about each day's tip), subscribe to the RSS feed, browse the archive, or start with the first tip.

How to Easily Open a Link in a New Tab

Most of the time, clicking a link on the web will take you somewhere new and leave the previous page behind. That’s not always ideal. Have you ever found yourself in one of these scenarios?

  • You’re shopping, and you want to open multiple products at the same time to compare them.
  • You’re reading an article and come across an interesting link, but you want to read it later without losing your place.
  • You’re doing research, and you’d like to open many search results separately.

You’re in luck: There’s a quick and easy way to open any link in a new tab whenever you want without messing around with settings or preferences!

  • On a Mac, hold the Command key when you click on a link to open it in a new tab.
  • On Windows or Linux, hold the Control key when you click on a link to open it in a new tab.
  • On iOS or Android, long-press on a link and a menu will appear with an option to open the link in a new tab. If you’re on an iOS device that supports force touch or 3D touch, make sure you don’t press too hard.

If you’re using a Mac, Windows, or Linux PC you can also right-click on a link which will present a menu allowing you to open it in a new tab, but using the keyboard is usually much easier and faster. One other thing: Clicking on links as described above may open them in new windows instead of tabs. If you’re getting one behavior and would prefer the other you should be able to adjust this behavior in your web browser’s settings.


DuckDuckGo explains itself thusly:

DuckDuckGo is an Internet privacy company that empowers you to seamlessly take control of your personal information online, without any tradeoffs. With our roots as the search engine that doesn’t track you, we’ve expanded what we do to protect you no matter where the Internet takes you.

DuckDuckGo’s search engine is pretty great, but they also do some great work in the online privacy space. If you want to learn more check out DuckDuckGo’s About page.

Simplify Your Forms

Here’s the thing; people hate filling out forms. The simpler you can make your forms, and the easier they are to use, the more people will fill them out.

Think about all the forms you currently have (or plan to create) and ask yourself: What is the bare minimum amount of information you need to ask for? The answer should line up with the fields your form has.

Have a bunch of optional fields? Get rid of as many as you can (and you can probably get rid of most of them). Make each optional field fight tooth and nail for its survival. Every form field, optional or not, makes your form that much more daunting and intimidating. If people see a form with ten fields they’re going to move on long before they realize eight of them are optional.

And if some of those optional fields make the cut, make sure they’re visually distinct from the required fields. It should be crystal clear to your visitors which fields they can skip. One of the most frustrating experiences on the web is spending the time to fill out a form and hitting submit only to be faced with an error message and a bunch of fields outlined in red.

Take a few minutes to put yourself in your visitor’s shoes and go fill out all of your existing forms from their perspective. Don’t use autofill or other fancy tools to fill out your forms; many people don’t use them or don’t even know they exist. Be honest with yourself: Do you find your forms frustrating? Do you find yourself getting bored while filling them out? Did the thought of doing this exercise sound like a drag? Imagine how your visitors feel! If you don’t care to fill out your own forms, why should anyone else?

The simpler and easier you can make your forms the better they’ll work, for both you and your visitors.

How to Avoid Confusing Code Hoisting Surprises

JavaScript does some things behind the scenes that you may not expect. One of these is called code hoisting, and it can cause some strange issues if you don’t know what’s going on behind the scenes.

The way code hoisting works applies to functions and variables a bit differently, so we’re going to examine each one individually.

Function Hoisting

Let’s start with this example:

function sayHello() {

sayHello(); // Hello!

That’s pretty straightforward. Running this will log Hello! to the console.

Let’s take a look at another version:

sayHello(); // Hello!

function sayHello() {

This code works in exactly the same way as the previous example, but how? We called the sayHello() function before we declared it, so why does this code work?

The answer is that the function declaration was hoisted to the top, effectively making both of these examples work as if they were written like the first example.

Whenever you declare and initialize a function with the function keyword, that function is hoisted to the top of the scope where you declared it at runtime. This allows you to call the function before declaring it.

Here’s a longer example that will make this clearer. Examine this code:


function piggyOne() {


function piggyTwo() {


function piggyThree() {

When this code is run the function declarations will be hoisted, which effectively makes the code run as if it was written like this:

function piggyOne() {

function piggyTwo() {

function piggyThree() {




That’s essentially how function hoisting works.

Variable Hoisting

Before we dive in to how variables are hoisted it’s important to understand the difference between declaring a variable and initializing a variable.

var theAnswer; // Declaration
theAnswer = 42; // Initialization

Declaring a variable is like saying, “this variable exists,” whereas initialization is like saying, “here’s what this variable contains.”

You can also declare and initialize a variable at the same time:

var theAnswer = 42; // Declaration & Initialization

Now that you know the difference between declaring and initializing a variable, let’s get back to code hoisting by explaining that JavaScript hoists variable declarations, but it does not hoist variable initializations.

Let’s look at some examples, starting with this code, which will throw an error:

console.log(theAnswer); // ReferenceError: theAnswer is not defined

We didn’t define theAnswer, so that error makes sense. Now let’s both define and initialize theAnswer before trying to log it:

var theAnswer = 42;

console.log(theAnswer); // 42

This example logs 42 to the console, as expected.

Now take a look at this:

console.log(theAnswer); // undefined

var theAnswer = 42;

This code logs undefined to the console, which is an interesting outcome.

Remember, JavaScript only hoists variable declarations, not initializations. That means the code above effectively executes like this at runtime:

var theAnswer; // Hoisted!

console.log(theAnswer); // undefined

theAnswer = 42;

The declaration of the variable was hoisted, but the initialization was not. JavaScript is essentially tearing the single line of code that declared and initialized theAnswer in half, and putting the declaration at the top. This prevents the console.log() line from throwing an error, but it because theAnswer hasn’t been initialized yet, the value inside is undefined.

What About Variables Containing Functions?

You might be wondering how code hoisting works in a scenario like this:


var sayHello = function() {

This code will actually throw an error: TypeError: sayHello is not a function. That’s because, in this case, sayHello is being declared as a variable with the var keyword, so only that variable declaration is hoisted to the top, effectively making the code run like this:

var sayHello; // Hoisted!

sayHello(); // TypeError: sayHello is not a function (execution stops here)

sayHello = function() {

One thing to note is that JavaScript isn’t actually rewriting your code when it hoists function and variable declarations to the top. What’s going on behind the scenes is a bit complicated, and has to do with JavaScript putting function and variable declarations in memory during the compile phase. The good news is that you don’t need to know the technical specifics of code hoisting to understand how it works and the impact it has on your code.

Now that you know how code hoisting works I recommend you work with it instead of against it. That is, declare your functions and variables first. JavaScript is going to do so anyway, and if your code matches what’s actually going on behind the scenes it will be easier to manage and debug, with fewer surprises.

HTML for Keyboard Shortcuts

If you’re writing technical instructions, documentation, or educational material that includes keyboard shortcuts, make sure you use the <kbd> element where appropriate.

Here’s what the HTML5 specification has this to say about the <kbd> element:

The <kbd> element represents user input (typically keyboard input, although it may also be used to represent other input, such as voice commands).

There are two things that make this element really great:

  1. It provides a clean, semantic way to define keyboard input.
  2. It makes it very easy to visually style keyboard input in a distinct way.

By default, text inside a <kbd> element is rendered with a monospace font, but it’s very easy to style this element to suit your own needs. Here on Core Assistance, for example, I often use the <kbd> element when I talk about keyboard shortcuts, so I wrote some CSS that makes <kbd> elements look like actual keyboard keys. Here’s an example: If you’re on a Mac, you can press Command + R to reload this page.

Here’s the CSS I use for <kbd> elements on Core Assistance. I’ve added some comments to explain what each declaration does. Feel free to use this CSS as-is on your own site or as a jumping-off point for your own <kbd> styles:

kbd {
    /* It all begins with a solid border. */
    border-style: solid;

    /* Make the border 1px thick on the top and both sides, but 3px thick on the bottom.  This gives these elements a nice raised appearance. */
    border-width: 1px 1px 3px;

    /* Round the corners a bit.  I'm using the em unit because I want the rounding of the corners to scale with the text. */
    border-radius: .25em;

    /* Use the same font-family as the surrounding text. */
    font-family: inherit;

    /* Give the text inside the borders a little breathing room. */
    padding: .1em .25em;

You may also need to adjust the line-height of your text so these styles don’t interfere with other text.

What Does Your Audience Want from Your Copy?

It’s important to take your readers’ motivations into account when you’re writing copy for your website. Think about their context as they browse your site and ask yourself: Is your copy giving them what they want when they want it?

If you’re selling an expensive product or service it’s more likely that your visitors are going to be more hesitant to buy. The higher the price, the more they need to make sure your solution is right for them. In this case, give them more details. Be verbose. Answer questions before they can think of them. Make sure they have enough information to make an informed choice.

On the other hand, if you’re selling something with a low price tag, it’s more important to keep your copy short and to the point to minimize distractions. You should still make sure you’re helping people make an informed buying decision, just keep your copy proportional to the situation. People spend less time thinking about a $30 purchase than a $300 one, and your copy should take that into account.

Regardless, don’t add sentences or paragraphs to increase the length of your copy without good cause, and don’t remove anything that needs to be there. Great copy has everything you need and nothing you don’t. Now, of course, different people need different things, which means you’re never going to write perfect copy that pleases everyone, and that’s okay. As long as most of your target audience is getting what they need with minimal distraction your copy is doing its job.

Great Design Serves the Audience

Imagine you made a thing, and that thing is blue. Sometimes the person writing the checks will say something like this when you show it to them:

It’s good, but can you make it green? I like green.

They like green. Okay. They’re paying you to design this thing for them, so it’s your job to make it green, right?


In fact, there are two wrongs here.

The first thing that’s wrong has to do with who you’re designing for. Most of the time you are not designing for the person writing the checks. They are paying you, yes, but your design isn’t for them. Your design is for the target audience, and the person writing the checks is usually not a member of the target audience.

The second thing that’s wrong pertains to your job. As a designer, your job is to communicate well, solve problems, and accomplish goals. If you’re good at your job you made the thing blue for a good reason, not an arbitrary one. Does the person writing the checks have an objective reason for wanting it to be green? A good reason that will have a positive impact on the outcome of the project? Or is it just an arbitrary choice defined by their personal preferences?

It’s probably the latter. That means it’s your job, as the designer, to do two things:

  1. Say no.
  2. Explain why blue is, objectively, the best choice.

Do not be afraid to say no. As a designer it is often your job to say no and explain, politely, why no is the best answer. No is powerful. No can protect the integrity and efficacy of your work. No is critical component of great design.

Remember, design is not about personal preference, what looks nice, or what people who aren’t in the target audience would like to see. Design is about creating something that works, and works well.

If it works better blue, don’t make it green.