7Website preliminaries


The base html file

OK I’m thirty seven thousand words in and I’m just now starting the website code—what the hell have I been playing at? I should be ashamed of myself.

First we need to open the folder structure (downloaded in § 7.1) in Brackets. Open Brackets, click file and select open folder. It will open a navigation dialogue box, navigate to the root folder (in my case it is 1001-website) and press select (Figure 7.2):

Figure 7.2 - Open a project (folder) in Brackets

Figure 7.2   Open a project (folder) in Brackets

You will end up with something that looks like Figure 7.3; I’ve expanded the folders at the side to show the three files: index.html, style.css and normalise.css.

Figure 7.3 - The website project open in Brackets

Figure 7.3   The website project open in Brackets

Open the index.html file by double clicking it in the sidebar (it’s at the bottom of the tree). It will look like this when you do (Figure 7.4):

Figure 7.4 - index.html in Brackets

Figure 7.4   index.html in Brackets

Yep, it’s an empty file.

Let’s add some code and create a basic HTML file, this will be a slightly more advance version of that in § 5.1 for the first-site, I’ve listed it in the code fragment below (Code 7.1). Here it is in Brackets (Figure 7.5):

Figure 7.5 - Basic index.html file

Figure 7.5   Basic index.html file

And here’s the code:

<!DOCTYPE html>                             <!-- HTML 5 file -->



PRACTICALSERIES: Practical Series of Publications
                 Website Development for Online Publications

************************************************************ -->

<html lang="en">      <!-- Declare language -->
    <head>            <!-- Start of head section -->
        <!-- Unicode characters (must be in first 1024 char) -->
        <meta charset="utf-8">           
        <!-- Make page follow browser width and reset zoom -->
<meta name="viewport" content="width=device-width, initial-scale=1.0">

<!-- ========================================================

<!-- ********************************************************
     ******************************************************** -->
<link rel="stylesheet" type="text/css" href="21-global/01-css/normalise.css">
<link rel="stylesheet" type="text/css" href="11-resources/01-css/style.css">

        <title>PracticalSeries: Web Development</title>


Code 7.1   index.html a

Now most of this you should recognise, there’s all the stuff I had in the first-site HTML file (§ 5 & § 6). It has the following:

  1. The document type <!DOCTYPE …>

  2. The HTML section <html>…</html>

  3. within the HTML section, the head <head>…</head>

  4. within the head section, the title <title>…</title>

  5. followed by the body <body>…</body>

There is some new stuff too:

  1. Meta tags <meta …>

Let’s go through it:



First thing <!DOCTYPE …>, just the standard HTML 5 DOCTYPE (§ 5.1.1)

<!DOCTYPE html>                             <!-- HTML 5 file -->

This should always be the first line of any HTML file.



Yep, I’m commenting this one, the comments are a cut down version of those on the website proper; it’s my (forlorn) attempt to try and keep each line of code on one line in the code fragments shown on this website, I also want to keep the code fragments a reasonable (and readable) length. I talk at length about comments in § 6.9.



This is the first difference from what was discussed before (§ 5.1.2)

<html lang="en">                    <!-- Declare language -->

I’ve added a lang attribute to the element. The lang attribute is used to tell browsers and search engines what language the website is written in, I’ve written this one in English and this has the value “en”. The two letter language code (en in this example) is defined in ISO 639‑1 Language Codes.

Using the lang attribute is not a requirement, but it is good practice; so I’ve used it.



The head section in the first-site website didn’t have much in it, just a title and a link to the style.css file. This one still has those, but it also has something new: meta tags.


Meta tags

Meta tags <meta …> hold metadata, metadata is data that gives information about other data—of course it is—(“higher data” is its literal translation). In this case, it summarises information about the web page that contains it. I’ve used two here, and I will use more later:

<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">

The first <meta charset="utf-8"> is used to tell browsers what character set the website uses (they pretty much all use utf-8†1). Again it is good practice to use this on all web pages.

The second meta tag is the viewport meta tag:
<meta name="viewport" content="width=device-width, initial-scale=1.0">

The viewport meta tag is used to tell browsers what to do when the website is being viewed on mobile devices and devices with generally smaller screens, this is part of making the website responsive.

The viewport is the visible area of a web page that can be seen by the user on a particular device. This web site is being designed for a maximum width of 1276 px and anyone looking at it on a PC will probably see the whole site. In the days before smart phones and tablets, this was fine, websites were static and did not resize their content to match the browser width—you just got scroll bars; it was how everyone viewed the internet.

When Apple introduced the iPhone (in 2007) it had a (portrait) screen width of 320 px and at the time most websites were designed for a width of 960 px, so rather than just showing part of the website, Apple did a neat bit of jiggery-pokery with the Safari mobile browser and had it think the screen width was actually 960 px. This meant the entire website would show on the phone (albeit possibly too small to see).

Nowadays we have responsive websites, and we don’t want the phone to lie to us about its apparent screen size, we want to know the proper size and then tailor our content to match i.e. we want the website to respond to the true width of the browser.

The first bit of the viewport meta tag does just that width=device-width it sets the width of the viewport to be the same as the width of the device, it overrules any false width the phone may be trying to report (on a PC, it returns the width of the browser window).

The second part initial-scale=1.0 sets the zoom factor when the page is first displayed to 1.0, i.e. there is no zoom applied.

These two viewport properties are standard on most responsive websites.

†1 UTF-8 is a Unicode character set that is backwards compatible with the old 7-bit ASCII characters that those of us of a certain age will remember. The 8 means it uses 8-bit blocks (bytes to most people, but octets in the Unicode standard) to represent characters, it can have up to 4 bytes and can represent all Unicode characters (there is a lot of them—‘bout a million).
UTF-8 is the standard character set for web pages and E-mail.
The meta tag specifying the character set must be within the first 1024 characters of the index.html file. I don’t know why, but the page will fail validation if it’s not.


<link …>

We used the link tag before to load the CSS file (§ 5.4) and this is exactly the same, except we are loading two CSS files:

<link rel="stylesheet" type="text/css" href="21-global/01-css/normalise.css">

This first link element loads the normalise.css file, it’s done in exactly the same way as it was in § 5.4, the only difference is that a path to the file is included:


The normalise.css file is not stored in the root area of the website, it is stored in the directory 21-global and subdirectory 01-css, see the folder structure in Figure 7.1; hence we need a pathname that points to that location.

When including the path, the path is given from the location of the current html file, in this case index.html and this is located in the top level (root) directory.

Moving up a directory level in path names

In the example just given, the path to another file is given from the folder containing the current file (i.e. the path can only link to sub-folders of the current folder).

Sometimes it is necessary to navigate to a higher level (parent) folder and this is done by inserting ../ at the start of the path name i.e.:


Would go up a directory level and then look for directory-1 from there

This ../ nomenclature is old command line stuff, it started with DOS and UNIX way back in the 60s—when I were nobbut a lad†2.

So this first link element loads the normailse.css file.

If you want to check it has worked open normalise.css in Brackets and add the line: background-color: #ff0000; to the html class in normalise.css:

html {
  font-family: serif; /* 1 */  /* changed from san-serif by MG */
  -ms-text-size-adjust: 100%; /* 2 */
  -webkit-text-size-adjust: 100%; /* 2 */
  background-color: #ff0000;

It will make the whole page bright red when viewed with live preview, click the Brackets icon button on the right hand sidebar of Brackets. If it’s worked it will look like this:

Figure 7.6 - Checking the normalise file has loaded

Figure 7.6   Checking the normalise file has loaded

Now delete it again, we don’t want it to look like that.

The next link element loads the style.css file (like we did in § 5.4):

<link rel="stylesheet" type="text/css" href="11-resources/01-css/style.css">

Again the only difference is the path to the file, this time its location is:

†2 “Nobbut” Yorkshire colloquialism—it means “nothing but”.
There is a story (probably apocryphal) about an Ordinance Survey cartographer drawing up the maps of Yorkshire. He stops a farmer and pointing to a hill says “What’s that called?”
The farmer replies “why, that’s nobbut top O’t’hill”.†3
The cartographer duly records “Nobut Topot Hill” on his map—it’s still there to this day.
†3 “Nothing but the top of the hill”.


<link …> file order and priority

The order in which the link elements occur in the HTML file is important; the file that is listed first in the HTML file will be executed first, followed by the next file and the next working down the HTML file.

Obvious you might think, and it is.

It’s the cascading thing I discussed in § 5.6.1—rules applied later have priority over those applied earlier.

This is why I link to normalise.css first; I want anything I put in my stylesheet (style.css) to take priority over the defaults applied by the normalise.css file.

If it were the other way around, if I called style.css before normalise.css then anything I did in style.css that had a counterpart in normalise.css (i.e. changing the h1 margin) would be overwritten by normalise.css, simply because it was called after style.css and so had a higher priority.

If you want to check that style.css has loaded, open it in Brackets and add the following:

html {
    background-color: #0000ff;

The whole site will this time go blue:

Figure 7.7 - Checking the style file has loaded

Figure 7.7   Checking the style file has loaded

  • If you left the red background-color: #ff0000 in normalise.css before adding the blue background-color: #0000ff to style.css, the red would change to blue; this is because both files are trying to change the background colour, but style.css is called last so it has priority and it wins, the background goes blue.

If you’ve tried these things, delete them—delete any background-color lines you may have added to normalise.css. Style.css should be completely empty. The website should be blank and have a white background.



I’ve given the page a title:

<title>PracticalSeries: Web Development</title>

Again this is just as § 5.1.3. The title is displayed in the browser tab for the web page; you can see it in Figure 7.6 and Figure 7.7.

The only additional thing to say about titles is that each page within the website should have a unique title, duplicate titles indicate duplicate pages to search engines and they don’t like duplicate pages.

The title is one of the most important elements for search engines and they should accurately reflect the web page with which they are associated.


Finally <body>…</body>

Well the <body> tag is there but it’s empty, I fill it in later.

End flourish image