Daily Tips & Tricks for Web Enthusiasts


Don’t Use Inline Styles

You can add CSS to a specific HTML element using the style attribute, like this:

<h3 style="font-size: 1.5em; font-weight: normal; color: green;">I'm a Header!</h3>

CSS rules specified in a style attribute like this are referred to as inline styles, because the style information is inline with the HTML.

You should avoid using inline styles at all costs.

Inline Styles are Harder to Maintain

The example above makes three changes to a single h3 element. What if you want to make those same changes to another element? If you use inline styles you’ll need to copy and paste all or part of that style attribute to the other element.

Now what if you want to change the color? You’ve got to remember to change it in two places. Or was it three? Or fourteeen?

Inline Styles are the Enemy of Consistency

When you use inline styles it’s incredibly easy to forget to apply them to an element, or overlook changing the styles on another element. Using a seperate CSS file allows you to keep all your style information in one place, ensuring that the edits you make there will be applied uniformly across your site.

Inline Styles Aren’t Cached Seperately & Add Bloat

Of the following two options, which do you think is faster and better?

Option One

Download this CSS once and cache it:

h3 {
    font-size: 1.5em;
    font-weight: normal;
    color: green;

Then load five pages, each with one of these:

<h3>I'm a Header!</h3>
<h3>I'm a Header!</h3>
<h3>I'm a Header!</h3>
<h3>I'm a Header!</h3>
<h3>I'm a Header!</h3>
Option Two

Download this, seperately, for each of the five page loads:

<h3 style="font-size: 1.5em; font-weight: normal; color: green;">I'm a Header!</h3>
<h3 style="font-size: 1.5em; font-weight: normal; color: green;">I'm a Header!</h3>
<h3 style="font-size: 1.5em; font-weight: normal; color: green;">I'm a Header!</h3>
<h3 style="font-size: 1.5em; font-weight: normal; color: green;">I'm a Header!</h3>
<h3 style="font-size: 1.5em; font-weight: normal; color: green;">I'm a Header!</h3>

Inline Styles Break Seperation of Concerns

HTML is for content, CSS is for presentation. There are some exceptions, but inline styles should not be one of them.

Keeping a clear boundary between content and presentation is one of the best ways to keep your code maintainable and understandable. When you start mixing these you’ll end up with a tangled mess that no one wants to deal with.

Is it Ever Okay to Use Inline Styles?

There are some specific situations where use of inline styles cannot be avoided.

Sometimes inline styles must be used out of necessity, with the most common example being HTML emails. Many email clients are woefully out of date when it comes to supporting technologies we’ve been enjoying on the web for years and years, and many of them simply don’t understand CSS that isn’t inline.

Another example is JavaScript, which is used to alter the appearance of an element using inline styles (although modifying other attributes, like classes, are usually a better option).

Inline styles can also be convinent for quick prototypes or experiments, but they should never be used in a production environment.

Specify Automatic Form Functionality

Form fields have four attributes that give you control over their automatic behavior: autocomplete, spellcheck, autocapitalize, and autocorrect. The first two included in the HTML spec, while the other two are non-standard but still worth implementing.


The autocomplete attribute tells the browser if it should provide autocomplete functionality for a form field. Aside from the basic choices of on and off for the value of this attribute, there are a wide variety of choices to specify what, exactly, the browser should put in a given form field. Here are some examples:

  • name
  • username
  • new-password
  • current-password
  • email
  • address-line1
  • postal-code

That’s just a sample. There are a bunch of other possible values covering things like payment details, personal information, and more. You can find a complete list with details for each possible value, along with a handy table, in the WHATWG Standard.

Adding the autocomplete attribute to form fields when appropriate can make filling your form out a lot easier for everyone, especially people using mobile devices that are difficult to type on.


Just what it says on the tin: the spellcheck attribute controls the automatic spell check functionality of a form field. Possible values are true, false, and default. This attribute comes in handy if you have a text field that’s going to accept something like a special token (like a coupon code), URL, or programming code.


As I mentioned above, the autocapitalize attribute is non-standard. It’s only supported in Safari on iOS and Chrome. Possible values are sentences, words, characters, and none.

Despite being non-standard this attribute can still help a ton of people and make your form a lot easier to fill out, and including it has no negative impact. Browsers that don’t support it will simply ignore it.


The autocorrect attribute is also non-standard, and this attribute is only supported in Safari on iOS. Possible values are on and off.

Again, this has the potential to help people have a better experience filling out your forms, and there’s no downside to including it.

These four attributes, when used wisely, can make the difference between a frustrating form experience and a pleasant one. Implementing these usually only takes a few minutes. This is time I’m sure your visitors will consider well-spent.

HTML Terminology

Elements, tags, attributes… there are a lot of terms used to describe the various bits of HTML. Understanding the most common of these terms will help you understand and discuss HTML with confidence, so in this tip I’m going to describe all the terms that apply to this snippet of HTML:

<a href="https://coreassistance.com/">Core Assistance</a>

That entire thing, the entire link from start to finish, is called an element. Specifically, this is an anchor element (the a stands for anchor).

This anchor element is made up of several components, the first of which is the opening tag, which is this part:

<a href="https://coreassistance.com/">

This opening tag contains an attribute:


Attributes are made up of name-value pairs. In this example, the name of this attribute is href and the value of the attribute is https://coreassistance.com/.

That’s the opening tag. Next comes the content of the element, also commonly called the text content:

Core Assistance

Finally, we have the closing tag:


So, to recap, here’s the entire element:

<a href="https://coreassistance.com/">Core Assistance</a>

This element has:

  • An opening tag:
    <a href="https://coreassistance.com/">
    • Containing an attribute:
  • Some text content:
    Core Assistance
  • A closing tag:

There are, of course, a couple of exceptions worth pointing out.

Some HTML elements do not have both opening and closing tags, and contain no text content. Take the image element, for example:

<img src="..." alt="...">

In this case the code above is still referred to as an element, but instead of calling this an opening or closing tag, it’s simply referred to as a tag.

This can lead to a bit of confusion. Most of the time an HTML element has both a start tag and an end tag, with neither tag representing the whole element, but rather being part of it. With some elements, however, that have no content, only a single tag is used, and that single tag represents the entire element.

Another exception applies to attributes. Most of the time an attribute consists of a name and a value, but some attributes have no value. The checked attribute is a good example of this:

<input type="checkbox" checked>

This input element contains two attributes. The first has a name (type) and value (checkbox), but the second attribute just has a name: checked. The mere presence of this attribute is enough to indicate the state of the checkbox, so no value is required.

Now you know the most common terms used in HTML!

Watch Out for Trailing Commas in CSS

When writing code there are a lot of situations where you need to provide a comma-separated list of things. Here’s how you create an array in JavaScript, for example:

var array = [foo, bar, baz];

This array contains foo, bar, and baz.

Some people, for clarity or just preference, will write that same code across several lines, like this:

var array = [

In JavaScript, the order of the items in an array matters. If you wanted to move baz up to the second position in the array you couldn’t just move that line up, because the commas wouldn’t be in the right places anymore.

In order to avoid this comma problem, and make it both easier and less error-prone to move things around, many people add a trailing comma to the last item, even though there’s nothing that comes after it, like this:

var array = [

That makes it easy to move the items in the array around just by moving lines up and down. This is a common practice in many programming languages, and many people have developed a habit of placing a trailing comma after the last item in a comma-separated list like this.

Now, in CSS, you’ll also run into comma-separated lists of things. One of the most common things you’ll see is a list of selectors separated with commas, like this:

h1, h2, h3 {
    color: blue;

If you’ve picked up the habit of adding a trailing comma after the last item from another programming language you might be tempted to write something like the following (or you might see this in some CSS someone else wrote):

    color: blue;

Unfortunately, this CSS won’t work. Adding a comma after the last selector in CSS is not allowed, so adding the comma after the h3 selector will invalidate this selector list.

Furthermore, one of the interesting things about CSS is that any invalid selector in a list of selectors invalidates all of them. Thus, the comma placed after the h3 selector above will prevent the entire ruleset from working, so color: blue; won’t be applied to anything.

So, if you have some CSS that’s not working and you can’t figure out why, make sure you don’t have a trailing comma after the last selector!

Smart Line Height

The line-height property has some unexpected inheritance behavior when used with a length or percentage. Take this CSS, for example:

div.example {
    font-size: 20px;
    line-height: 1.5em;

div.example h2 {
    font-size: 40px;

With this CSS you might expect the line height of h2 elements inside div.example elements to be 60px, but that’s not the case. No, with this CSS, everything inside div.example elements will get the same 30px of line height regardless of their own font size, including those h2 elements.

Why is this? When you provide a length or percentage value for the line-height property the line-height calculation is made at that point, and that calculated value is used going forward. The em unit specifies a length, so we get the 30px of line height calculated immediately and used everywhere.

The good news is that there’s an easy way around this problem: Never provide a length or percentage value when using line-height. Instead use a number with no unit, like this:

div.example {
    font-size: 20px;
    line-height: 1.5;

div.example h2 {
    font-size: 40px;

Now the line height will be calculated by multiplying the font size of whichever element the line height is being applied to. This results in 30px of line height inside div.example elements by default, and 60px of line height on the h2 elements inside them, just as expected.

Set a Character Set

It’s important to define a character set for your HTML pages. The character set tells the web browser how the characters (letters, numbers, punctuation, etc.) are encoded, and doing so is a bigger deal than you might think.

The most common character set issue is special characters (including emoji) and other content not showing up properly. That’s annoying, but it gets worse. An incorrect or missing character set can actually be a significant security issue that opens the door to cross-site scripting attacks.

The good news is that defining a character set is easy. You just need to add a single <meta> element with a charset attribute as the first thing in your page’s <head>, like this:

<meta charset="UTF-8">

There are a few things you need to pay attention to when setting your character set:

  • The UTF-8 character set is highly recommended for pretty much all use cases these days.
  • Make sure the character set you define in your <meta> element matches the character encoding of the actual source files you’re using. You can usually select the character encoding in the preferences of your text editor, or when saving your files.
  • Make sure your character set <meta> element is the first thing in your <head>, as some web browsers will only look at the first 1024 bytes of a file before choosing a character encoding for the entire page.
  • Note that if the web server serving your page sets a Content-Type header, the character set defined in that header will override your <meta> element (but that doesn’t mean you shouldn’t set one in your HTML anyway).

Easy Layout Debugging with Outlines

When I’m working on a layout problem one of my favorite tricks to figure out what’s going on is applying outline: solid red 1px to the elements I’m working with. This works much better than borders because outlines do not affect layout, so my debugging outlines won’t get in my way or cause further problems.

This trick can easily be expanded for more complex debugging sessions too, just use different styles and colors on different elements. Here are some of my favorites:

.troublesomeElement {
    outline: solid red 1px;

.whatIsHappening {
    outline: dashed blue 1px;

.seriouslyWTF {
    outline: dotted orange 1px;

You can also combine this trick with some fancy selectors to make sure you remember to do certain things, like fill in blank links:

a[href=''] {
    outline: solid red 1px;