Comments and checking your work

A browser will show you a page that looks right. It will not tell you the page is correct, because those are different questions. This lesson is about the gap between them, and the free tool that closes it.

Comments

A comment is a note in your HTML that the browser ignores:

<!-- The prices come from the printed menu, updated each Monday -->
<p class="price">Biryani — 350 rupees</p>

It starts with . Everything between is skipped when the page renders.

Use them for the things the markup cannot say for itself — why something is the way it is:

<!-- Two nav elements on purpose: one for the top bar, one for the footer,
     so a screen reader user can skip the second -->

Not for restating what is plainly visible:

<!-- This is a heading -->
<h1>Lahore Canteen</h1>

The heading already says it is a heading. That comment adds nothing and now has to be maintained.

Comments are also useful for temporarily removing something without deleting it:

<!-- <p>Card machine now working</p> -->

One warning, and it matters: comments are not private. Anyone can view the page source and read them. Never put anything in a comment you would not put on the page — no passwords, no internal notes about people, no "TODO: fix this before anyone notices".

They also cannot nest. A --> inside a comment ends it early, and the rest spills onto the page.

Browsers repair broken HTML, and that is the problem

Forget a closing tag and a browser does not stop. It patches the document and carries on:

<p>The canteen opens at eight.
<p>It closes at six.</p>

The first paragraph is never closed. The page looks completely normal, because the browser inferred where it ended.

This forgiveness is why the web works — a single typo taking down a page would have made the early web unusable. But it means looking right is not evidence of being right. The browser is quietly correcting you, and:

Different browsers repair differently, so a page can look fine in one and wrong in another.
Errors accumulate invisibly until one finally produces visible damage, and by then the real cause is fifty lines away.
Screen readers and search engines may read the repaired structure differently from how you intended.

The validator

The W3C runs a free checker at validator.w3.org. Paste your HTML, or upload the file, and it reports every problem.

It catches the things your eyes will not:

Unclosed elements
Elements nested where they are not allowed
Duplicate id values — exactly the silent bug from the last lesson
Missing required attributes, such as alt on an image
Stray characters that should have been entities

Make it a habit at the end of a page, not something you do only when stuck. It takes ten seconds.

Reading what it tells you

Validator messages are terse and describe the symptom, which is usually a little after the cause. A worked example:

<p>Practice starts at <strong>5pm</p></strong>

The validator says something close to:

End tag p seen, but there were open elements.

Read it as: I reached </p>, but <strong> was still open inside it. The error is reported at the </p>, but the mistake is that the two closing tags are in the wrong order. Fix:

<p>Practice starts at <strong>5pm</strong></p>

Two habits make the messages far easier to use. Fix the first error first, then re-check — one unclosed element often generates a dozen downstream complaints that vanish together. And read the line number as a starting point, not a verdict; the cause is often just above it.

Distinguish errors from warnings. Errors are genuine breaches — fix them. Warnings are advisory, and some are fine to leave.

The Elements panel

Your browser has a second tool: right-click anything on a page and choose Inspect. The Elements panel opens, showing the document as the browser actually built it.

This is the repaired version, not your file — which is precisely what makes it useful. Compare the two and you can see what the browser did to your markup.

<p>The canteen opens at eight.
<p>It closes at six.</p>

In Elements you will find a closing tag on that first paragraph that you never wrote. That is the repair, made visible.

It works on any site. Inspecting pages you admire is one of the fastest ways to learn how real pages are put together.

A page worth checking

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Lahore Canteen — menu and hours</title>
  </head>
  <body>
    <!-- Prices updated every Monday from the printed menu -->
    <h1>Lahore Canteen</h1>

    <section id="todays-menu">
      <h2>Today's menu</h2>
      <p class="price">Biryani — 350 rupees</p>
    </section>

    <img src="canteen.jpg" alt="The canteen counter at lunchtime">
  </body>
</html>

Doctype present, lang set, charset first, one <h1>, one unique id, every attribute quoted, alt describing the image. Run it through the validator and it passes — and now you know that because it was checked, not because it looked fine.

That is the end of Your first pages. You can write a valid HTML document, structure it with headings, mark text honestly, attach attributes, and check your work rather than trusting your eyes.

Worth going back over: headings, because the outline is the part most often got wrong, and attributes for the id-versus-class split that the validator will otherwise catch for you.