Introduction to HTML

HTML stands for HyperText Markup Language, and the useful half of that name is the last word. It is a markup language: you take content that already exists - words, pictures, numbers - and you mark it up, labelling each piece with what it is. This is a heading. This is a paragraph. This is a link to another document. This is a table of sales figures, and these cells are its column headers.

It is not a programming language, and the distinction is not pedantry. HTML has no variables, no arithmetic, no conditions and no loops. You cannot write "if the user is logged in" in HTML. What you can do is describe a document so precisely that a browser, a search engine, a screen reader and a future maintainer all reach the same conclusions about it.

That sounds modest. It is the foundation everything else is built on.

The first page

Save this as index.html, open it in a browser, and you have shipped a web page.

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>My first page</title>
  </head>
  <body>
    <h1>Hello, HTML</h1>
    <p>This page is nine lines long and completely valid.</p>
  </body>
</html>

Press Try yourself! underneath it. The example opens in the playground, where you can edit it on the left and watch the result on the right. Change Hello, HTML to your own name and the heading changes. Nothing is being compiled; the browser is reading your markup and building a document out of it as you type.

What the three languages each own

Almost every page you will ever build uses three languages, and the reason to keep them separate is that they answer different questions.

HTML answers "what is this?" A heading is a heading because it is in an h1, not because it is large and bold.

CSS answers "what should it look like?" Colour, spacing, layout, typography, what happens on a narrow screen.

JavaScript answers "what should it do?" Respond to a click, fetch more data, validate something the browser cannot validate on its own.

You can put a little CSS directly in the markup to see the division:

<h1 style="color: teal">Still a heading</h1>
<p>The colour changed. What the element <em>means</em> did not.</p>

The style attribute is a shortcut, useful for a one-off demonstration and a poor habit in a real page - a stylesheet keeps the answer to "what should it look like" in one place instead of scattered through the document. But it makes the point: the h1 was a heading before the colour was applied and remains one after. CSS changed the presentation and touched nothing about the meaning.

That separation is why HTML repays attention. CSS can make any element look like any other. A page built entirely from meaningless div elements can be styled to look flawless, and it will still be unusable with a keyboard, unreadable aloud, and invisible to the thing that decides whether anyone finds it. The markup is the layer that carries meaning, and nothing above it can put the meaning back.

What happens when a page loads

It is worth knowing the sequence, because most confusing bugs sit somewhere in it.

1. The browser fetches the HTML document - over the network, or straight off disk when you open a local file.
2. It parses the markup from the top, building a tree of objects called the DOM: the html element with a head and a body inside it, and everything else nested underneath.
3. As it meets references to other files - stylesheets, scripts, images, fonts - it requests those too. A stylesheet blocks the first paint, because rendering without it would flash unstyled content. A plain script blocks parsing, because it might write into the document.
4. It renders: works out the position and size of every box, paints them, and shows you the result.

The parser never refuses. This is the single most surprising thing about HTML and the reason for most of the advice in this course. Hand a browser markup with a tag left open or elements nested in an impossible order, and it does not show you an error. It repairs the markup, silently, according to rules written down in the specification, and shows you a document. Often the repaired document is what you meant. Sometimes it is not, and then you are looking at a page that is wrong in a way the source does not explain.

HTML5, and what "the living standard" means

You will see HTML5 everywhere, and it is now slightly misleading. There is no HTML6 coming. HTML is maintained as a living standard: it is amended continuously rather than published in numbered editions, so the right question about an element is not which version introduced it but whether browsers support it today.

What that means in practice is that a handful of old presentational tags are obsolete. They still render, because browsers do not break the past, but they put presentation back into the markup layer where it does not belong.

<p><font color="red" size="5">Obsolete: presentation in the markup.</font></p>
<center>Obsolete: layout in the markup.</center>
<p><strong>Modern: the markup says this matters.</strong> CSS decides how that looks.</p>

That second line is written without a paragraph around it on purpose, and it is worth knowing why: center is a block-level element, and a paragraph cannot contain one. Write <p><center>…</center></p> and the browser closes the paragraph, puts the center after it, and leaves you with an empty paragraph as well. Three elements where you wrote two, and nothing in the source says so.

font and center are the famous ones. The rule behind them generalises: if an element or attribute exists only to change an appearance, there is a CSS property that does it better.

What you need to start

A text editor and a browser. That is genuinely the whole toolchain. There is no build step, no package to install and no server to run - a file on your disk, opened in a browser, is a working web page.

Two habits are worth forming on day one:

Give the file a .html extension. The browser decides how to treat a file by its name.

Open the developer tools. Press F12, or right-click any element and choose Inspect. The Elements panel shows you the tree the browser actually built - which, as above, is not always the tree you wrote. The Console shows errors. The Network panel shows every file the page requested and how long each took.

Get used to comparing the Elements panel against your source. When a page behaves strangely, the difference between the two is very often the whole explanation. Note that edits you make in the inspector are temporary: they change the live document, not your file, and vanish on reload.

The tree, and why it is worth looking at

Everything above describes the browser building a tree. It is worth seeing one, because the tree - not your file - is what CSS styles, what JavaScript queries and what a screen reader reads.

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>A small tree</title>
  </head>
  <body>
    <h1>Courses</h1>
    <ul>
      <li><a href="/html">HTML</a></li>
      <li><a href="/css">CSS</a></li>
    </ul>
  </body>
</html>

Open that in the playground, then open the Elements panel. The nesting you see there is the nesting you wrote: html contains head and body; body contains an h1 and a ul; the ul contains two li elements, each containing an a. Click the ul and the browser highlights it on the page, because a box on screen and a node in the tree are the same object seen two ways.

Now try breaking it. Delete the </li> from the first list item and reload. The page looks unchanged - but the Elements panel still shows two separate list items, because the parser inferred the missing end tag. That is the repair behaviour, doing what you meant. Later lessons cover the cases where it does not.

Practice task

Build a one-page introduction to yourself. Give it a title, one h1, two or three paragraphs, and a line of text you have marked as important. Open it, then open the Elements panel and find each element you wrote. Change one word in the inspector, watch the page update, then reload and watch your change disappear - that is the difference between the document and the file, and it catches everyone once.