Comments

Course 1 · Ch 10

Comments, Whitespace, and Validation

Writing HTML that's clean, well-documented where it needs to be, and genuinely valid — not just "happens to render correctly"

Browsers are remarkably forgiving of invalid HTML — they'll often render something reasonable-looking even when the underlying markup is technically broken. That forgiveness is also exactly why bugs in HTML structure can go unnoticed for a long time. This chapter covers comments, whitespace conventions, and how to actually verify a document is valid rather than just "looks fine in one browser."

HTML Comments

<!-- This is a comment — never shown to visitors, only visible in the source -->
<p>This text IS visible.</p>

<!-- TODO: replace this placeholder image before launch -->
<img src="placeholder.jpg" alt="Placeholder">

Useful for:

Marking section boundaries in a long file —  after a long closing block.
Leaving notes for future maintainers (including future you) about why something is structured a particular way.
Temporarily disabling a block during development, without deleting it outright.

Comments are visible to anyone who views the page source

Unlike a comment in a compiled programming language, an HTML comment is sent to the browser exactly as written and visible to anyone who opens DevTools or "View Source." Never leave sensitive information, internal notes about security weaknesses, or anything not meant for public eyes in an HTML comment.

Whitespace — Why It (Mostly) Doesn't Matter, and When It Does

Browsers collapse multiple consecutive whitespace characters (spaces, tabs, newlines) into a single space when rendering text content — this is why indentation and line breaks in the source code are purely for human readability, not something the browser preserves visually by default.

<p>This    has     extra     spaces
    and a line break
    in the source.</p>
// Renders as: "This has extra spaces and a line break in the source."

The one common exception: the <pre> element preserves whitespace and line breaks exactly as written — used for displaying code samples or any text where exact formatting genuinely matters.

Consistent Indentation — A Convention, Not a Rule

Chapter 1 already introduced the idea that browsers don't require indentation at all, but consistent indentation makes nested structure genuinely readable to a human. Most projects pick either 2 or 4 spaces and apply it consistently — the specific number matters far less than actually being consistent throughout a project.

Why "It Works in My Browser" Isn't the Same as Valid

Browsers' forgiving error-recovery behaviour means genuinely broken HTML — an unclosed tag, a missing required attribute, improperly nested elements — often still renders something acceptable-looking, hiding the underlying problem until it causes a real issue (often in a different browser, or after a future edit makes the existing error finally matter).

Using the W3C Validator

The W3C Markup Validation Service checks a page (by URL or pasted code) against the official HTML specification and reports every actual error and warning, with line numbers.

Example validator output

Error, Line 12

Element <div> not allowed as child of element <p> in this context

Error, Line 27

Attribute "src" without an attribute value (img element missing required value)

Warning, Line 1

The character encoding was not declared, defaulting to UTF-8

Common Validation Mistakes

Unclosed tags

A <p> or <div> never closed — browsers often guess where it should end, but not always where you actually intended.

Improper nesting

A block element like <div> placed inside a <p> — technically invalid, since <p> is only meant to contain inline content.

Missing required attributes

An <img> with no alt (Chapter 5), a <label> with no for, an <a> with no href.

Duplicate IDs

The same id attribute used on more than one element — IDs must be genuinely unique within a page (Chapter 1).

Running the validator occasionally during development catches problems early

Validating only at the very end of a project means discovering a long list of accumulated issues all at once. Running it periodically during development — especially after adding any genuinely new structure, not just text content — catches problems while the relevant code is still fresh and easy to fix.

Chapter 10 Quick Reference

 — never visible to visitors, but visible in page source; never put sensitive info here
Whitespace collapses to a single space when rendered, except inside <pre>
Consistent indentation is purely for human readability — pick 2 or 4 spaces, apply consistently
Browsers' error tolerance hides real bugs — "renders fine" isn't the same as "valid"
W3C Markup Validation Service — checks real specification compliance, with line numbers
Common errors: unclosed tags, improper nesting, missing required attributes, duplicate IDs
Validate periodically during development, not just once at the end
Next chapter: special characters & entities