No Time Dad

A blog about web development written by a busy dad

My HTML and CSS Starter Template and Process

Most of the pages I’ve been creating lately are some variation of the pancake stack. Containing a header and main section at a minimum, but sometimes having a footer too. I’ve found that there’s a routine I fall into when starting a new project like this, and I’m outlining that here. It does vary from project to project, but most of the time I do these same steps when starting to design something from scratch.

Folders and Files

The first thing I always do when starting a basic html project like this is to create a directory that’ll contain an index.html file and a styles.css file. I’ll name the directory my-new-project for this example, but a real project should have a more well thought out name. This is especially true since the directory name will also be the url slug. The structure will look like the below.

my-new-project
|   index.html
|   styles.css

The reason I create the directory and file structure like this is so I can load the page at http://<host url>/ny-new-project. This works because the browser knows to render the index.html file as the root path. If I didn’t use index.html I’d have to explicitly use the filename in the url path. For example, if I called the html file my-new-project.html instead of index.html I’d need to load the page in the browser at http://<host url>/my-new-project/my-new-project.html. Which is fine, but a shorter url is easier to remember and a better user experience.

HTML Starting Point

My primary code editor is VS Code, and I use Emmet abbreviations a lot in my workflow. Almost every html file I create starts out by typing ! as the very first character and letting Emmet create initial markup for me. It generates something like the below. The next change I usually make is to change the title from the auto-generated “Document” to something more relevant to the project, like “Clamped Hero”.

Below is an example of how the html generated by emmet will look (comments are my own). The nice thing about the emmet generated html is it adds a meta element for the viewport. This makes it possible to control the viewport size on all devices. It’s very important.

<!-- Auto-generated html by emmet -->
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
</head>
<body>

</body>
</html>
Loading the Stylesheet

Next I’ll add a link element for the stylesheet. Using emmet, I’ll start typing the word “link” between the last meta tag and the title tag in the head element. Once I start typing the word “link”, emmet will give me a list of options to choose from. I usually always pick link:css which adds a line to my html file that looks like this:

<link rel="stylesheet" href="style.css">

For whatever reason I like to name my stylesheets styles.css instead of style.css, so I always need to modify the auto-generated link element to match the name. Maybe one day I’ll switch to using style.css, but today is not that day.

Now my html file looks as follows:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <!-- Added link element with href for stylesheet in same directory -->
  <link rel="stylesheet" href="styles.css">
  <!-- Updated title -->
  <title>Clamped Hero</title>
</head>
<body>

</body>
</html>
Changing the Font

The next step is optional, but I think it’s a nice touch. And that is to change the font to a custom font. For that I usually head over to Google Fonts. I try to pick from the popular fonts, and I look for a font that has at least 6 styles. I almost never bring in italic styles, and I try to keep it to 4 or 5 weights.

The font I probably reach for the most is Roboto. I’ll grab Regular 400, Medium 500, Bold 700, and Bold 900 weights. Which covers more than enough styles for me. Admittedly, I’ll probably only use two of the weights, but I bring in more anyways.

Once I have the styles selected, I copy the <link> provided and add it to my head element just above the title element. The html will look as shown below.

<!DOCTYPE html>
<html lang="en">

<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <link rel="stylesheet" href="styles.css">
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
  <!-- Roboto font loaded -->
  <link href="https://fonts.googleapis.com/css2?family=Roboto:wght@400;500;700;900&display=swap" rel="stylesheet">
  <title>Clamped Hero</title>
</head>
<body>

</body>
</html>

Using custom fonts is a nice touch, but it’s not “free”. That is, I’ve added a link to download something (a font in this case) from a 3rd party resource. I’ve decreased the performance of my page in doing so. But, it’s a small decrease. Users are unlikely to notice, and assuming I don’t load tons of fonts and other resources the performance hit is worth it in my opinion.

Adding the link element for the font isn’t enough to change the font displayed to the user. It’s just downloading the font when the page loads. I’ll need to add the font to my stylesheet before the browser knows when and where to use it. Until then, the browser will use the system default font.

Basic HTML Structure

The tasks above are what I think of as “administrative” tasks when starting a new project. They don’t necessarily impact how the page looks, but they’re required later for the css and design implementation. I also find that I always perform these tasks before starting a project. Once they’re done I can start the actual page design, which is where each project starts to become unique.

When I start a new page design I like to build a skeleton structure containing the elements I think I’ll be using. I don’t too deep with the child elements at this point, I just try to focus on building an outline of what I think the page structure will be.

The process of building the skeleton structure is meant to get me going on building the project. I’ve found there is an odd phenomenom that happens when I start a new project where I can seeming not make any forward progress or get some basic elements on the page. I don’t know why this happens. But I’ve found that just throwing some elements into the html to form a basic outline is helpful for making progress.

With that being said, most page designs I work on contain header and main elements. The html below is almost always my starting point for any project.

<body>
  <header></header>
  <main></main>
</body>

If the header is going to have the a background-color set, then I know I need to deal with the inside problem. That is, I want the background-color to go edge to edge but I also want there to be space on the left and right of any content that’s in the header. If I apply the spacing to the parent header element, the background-color won’t go edge to edge.

The way I usually deal with the inside problem is to just add a child div for the header content. Then I can apply the background-color to the parent and not have to worry about it not going edge to edge. I will say that for some reason it annoys me every time I do this. I want it all to work with just the header, but I guess it’s not meant to be (without some trickery, anyways).

The html structure for the header I usually end up with is shown below. The header now contains a child div with a class called toolbar and a class called container applied. The latter is a utility class that I’ll use in many places to keep the spacing consistent throughout the page. The former I typically use to handle the spacing and alignment within the toolbar itself. The toolbar selector is a very common place for me to initialize a flexbox container.

<body>
  <header>
    <div class="toolbar container"></div>
  </header>
  <main></main>
</body>

CSS Starting Point

My primary css file for any given project is typically named styles.css. And it often contains a set of imports for resets, baseline styles, or color palette. I prefer using @import in my css files instead of adding additional link elements in my html as much as possible. There isn’t anything wrong with either approach, but I think using the import keeps the css more self-contained.

CSS Resets

Using a css reset file is a good idea. It helps deal with any inconsistencies between browsers and gives me a consistent foundation to work from on each project. I’ve used normalize.css a lot in the past, but I’ve recently switched over to using Andy Bell’s Modern CSS Reset.

Andy makes a good argument for using his slimmed down reset in the post linked above. Essentially he says that modern browsers are improving and we don’t need huge reset files anymore. I’ve found this to be true. His resets have a much smaller footprint than your typical reset, and I haven’t ran into any issues with it yet.

I like to keep the resets in their own css file that I usually call resets.css. I store that file in a central location or right alongside my styles.css file, depending on the size of the project. I then use @import to pull the resets into my styles.css file. It’ll usually look something like the below.

my-new-project
|   index.html
|   styles.css
|   resets.css
/* styles.css */
@import "resets.css";
...

I don’t think there’s anything wrong with pasting the resets directly into styles.css, but that file can get cluttered quickly. It might become difficult to search and find what you’re looking for. At the same time, keeping the resets in a separate file adds the overhead of having to look at two files to debug the css if there’s an issue. I’ve found that the latter is an easier problem for me to handle. This is especially true for when I’m using dev tools to debug a css issue, it’ll display all of the css in one place for me.

Color Palettes

Color palettes are an important part of front-end development that I think is not often given enough thought. A good color palette makes a big difference. It helps a project pop and stand out from other sites. The color palette should also help ensure the text is accessible and can be read. I try to pick palettes that have high contrast colors, well above the 4.0 ratio usually recommended.

I’m a big fan of the nord color palette. I’ve been using it almost exclusively on recent projects. It’s just a nice consistent palette with lots of color options and ranges. I also like how flat it is. This means that the user can focus on the content and not be distracted by bright colors.

I’ve also used coolors a lot to pick color palettes. There’s always an interesting palette to pick from in their trending palettes section. You just have to be careful to pick palettes that have a wide range of colors to ensure proper contrast ratio.

The color palettes I use are almost always defined in the :root selector as CSS custom properties. I’ve also dropped them into their own file and used the @import to bring them into my styles.css. This is especially true for the nord palette I mentioned above. I’ll put those into a file called nord.css which contains a :root selector. Which is nice because I can still extend the :root selector in my styles.css file as needed.

Defaults

There are a few default styles I often add to my baseline css for new projects. The most common one I write is for anchor (<a>...</a>) elements. And that style is just to remove the text-decoration and inherit the text color. It’ll usually look something like the below.

a {
  text-decoration: none;
  color: inherit;
}

Setting the anchor text-decoration to none simply removes the default underlink on the link. Setting the anchor color to inherit means that it’ll change to whatever color is set in the parent element. I like this approach because I usually set color values in the body or larger parent element, so the anchor will pick-up that color automatically and I don’t need to hardcode it.

Wrapping up

I should probably automate all of this or creating some sort of template. For now, I just write it all out by hand each time. I guess that reinforces everything for me. It does take a decent amount of time, though. But, I always get a consistent starting point for my project using the steps above, so I think it ends up saving me a lot of time in the long run.