Document structure

What does a complete minimal page contain?

Every page you publish should start from the same skeleton. It has a doctype, a root <html> element with a lang attribute, a <head> holding information about the page, and a <body> holding everything people see. The character encoding, viewport and title lines are small, and leaving any of them out causes real, visible bugs.

Here is the skeleton for a bakery's home page. Copy it as your starting point for any new file and change the language, title and description.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Corner Bakery | Fresh bread in Leeds</title>
</head>
<body>
  <h1>Corner Bakery</h1>
  <p>Sourdough, rye and pastries baked every morning.</p>
</body>
</html>

What does the doctype switch on?

The line <!doctype html> tells the browser to render in standards mode. Without it, browsers fall back to quirks mode, which imitates bugs from browsers of the late 1990s so that very old pages keep working. In quirks mode the box model changes for some elements, table cells ignore inherited font sizes, and percentage heights behave differently. Your CSS will seem to break for no visible reason.

The doctype must be the very first thing in the file. A comment above it is allowed, but a blank PHP include that outputs text, or a byte order mark followed by stray characters, can push it down and trigger quirks mode. The long doctypes from HTML 4 and XHTML 1.0 still work but carry nothing useful; the short form is the current standard.

To check which mode you are in, open the DevTools console and type document.compatMode. You want "CSS1Compat". The value "BackCompat" means quirks mode.

document.compatMode
// "CSS1Compat"  standards mode
// "BackCompat"  quirks mode

What does the lang attribute change?

The lang attribute on <html> declares the main language of the page. Screen readers use it to pick a voice and pronunciation rules; a French page without lang="fr" read by an English voice is close to unintelligible. Browsers use it to offer translation, choose hyphenation rules for hyphens: auto, and pick the right quotation marks for the <q> element.

Use a BCP 47 tag. Plain en, fr or cy covers most sites. Add a region such as en-GB or pt-BR when spelling or vocabulary differs and you want that reflected. Avoid inventing codes like english or uk; the latter is actually Ukrainian.

When a passage switches language, mark it on the nearest element so it is pronounced correctly.

<html lang="en-GB">
...
<p>Our house loaf is a <span lang="fr">pain de campagne</span>.</p>

Which elements belong in head and which in body?

The <head> holds metadata: the title, character encoding, viewport, links to stylesheets and icons, scripts, and <meta> tags for descriptions and social previews. Nothing in it is displayed in the page area, although the title appears on the browser tab.

The <body> holds content: headings, text, images, navigation, forms, footers. If you put a visible element such as <h1> or <img> in the head, the parser closes the head at that point and starts the body early. Any <meta> or <link> that follows ends up in the body, where some of them still work and others are ignored.

Inside the body, a typical page uses landmark elements so assistive tech can jump between regions: <header> for the site banner, <nav> for main navigation, <main> for the unique content (one per page), and <footer> for contact details and legal links.

<body>
  <header>...</header>
  <nav aria-label="Main">...</nav>
  <main>
    <h1>Today's bread</h1>
  </main>
  <footer>...</footer>
</body>

Are the html, head and body tags optional?

The start and end tags for <html>, <head> and <body> can technically be omitted, and the parser creates the elements anyway. Google's style guide once recommended omitting them to save bytes. In practice you lose more than you save: you need the <html> start tag to set lang, and explicit tags make it obvious where metadata ends and content begins.

Write all three. Compression removes any meaningful size difference, and the next person reading the file, or an AI tool editing it, will have an easier structure to work with.

How do HTML comments behave?

A comment starts with <!-- and ends at the first -->. Browsers hide it on screen and still send it to every visitor. Anyone can read comments with View Source, so never leave passwords, API keys, internal URLs or rude notes about clients in them.

Comments cannot be nested. In the example below, the first --> closes the comment and the rest leaks onto the page as visible text. To disable a block that already contains comments, delete it or move it into version control history.

Use comments for short notes that explain why, such as marking the end of a long section or explaining a workaround. Build tools often strip them for production.

<!-- Outer start
  <!-- inner note -->
  This text now appears on the page.
-->

Why do my spaces and line breaks disappear?

In normal text, HTML collapses any run of spaces, tabs and newlines into a single space. That is why you can indent your source freely. It also means pressing Enter in your editor does nothing visible.

Use separate <p> elements for paragraphs and <br> only for line breaks that are part of the content, such as an address or a poem. For code samples or ASCII art, <pre> preserves whitespace exactly. For extra spacing between blocks, use CSS margin; stacked <br> tags and runs of   break on narrow screens and confuse screen readers.

Whitespace between inline elements can still matter. Two <img> or inline-block elements separated by a newline in your source get a small gap between them, which is the collapsed space. Flexbox or grid layout removes that gap.

<address>
Corner Bakery<br>
12 Mill Street<br>
Leeds LS1 4AB
</address>

How do you check a page's structure quickly?

Run the file through the Nu HTML Checker and fix anything about stray start tags or elements not allowed in the head. In DevTools, collapse the tree in the Elements panel and confirm <head> contains only metadata and <body> contains the content. Type document.compatMode and document.documentElement.lang in the console to confirm standards mode and the right language.

When reviewing AI-generated pages, check three things first. Look for a missing or wrong lang, which AI tools often leave as en on non-English content. Look for the charset meta appearing after the title or after a large inline style block; it must sit within the first 1,024 bytes. And look for more than one <main> element or a <main> wrapped inside <article>, both of which break landmark navigation.

Field notes

• A doctype line at the very top turns on standards mode.
• The <html> element should carry a lang attribute naming the page language.
• The <head> holds information about the page, and <body> holds what people see.
• Screen readers use the lang value to choose the right voice.

Easy to get wrong

Without the doctype the page renders in quirks mode, and without lang assistive tech has to guess the language.

Visible content belongs in the body. The parser will close head early and move the heading, which can break your structure.

Comments are delivered to every visitor and can be read with View Source.

The value must be a valid BCP 47 language tag. Screen readers do not recognise made-up values and fall back to the user's default voice.

Stacked br tags create spacing that cannot adapt to screen size and add empty lines for screen reader users. Spacing is a CSS job.

Questions people ask

Is <!DOCTYPE html> case-sensitive?

No. <!doctype html>, <!DOCTYPE html> and mixed case all trigger standards mode.

Do I need the html, head and body tags?

The parser adds them if missing, so the page still works. Include them anyway for clarity, and because you need the html tag to set lang.

What lang value should I use?

Use a BCP 47 language tag. A bare code like en or de is usually enough; add a region such as en-GB only when spelling or wording differs by region.

Can comments be nested in HTML?

No. The first --> ends the comment, so any inner comment breaks the outer one.

Does it matter where the charset meta goes?

Yes. Put it as the first child of head. The browser only looks for it in the first 1,024 bytes, and anything decoded before it may come out garbled.