Web design (HTML)

Edit in Notepad or Notepad++ only. A word processor will corrupt the file. View the result by refreshing the page in a browser.

A word processor like Word saves "rich text" formatting as hidden binary or XML structure wrapped around your words — opening and re-saving an .html file in Word injects huge amounts of that extra markup (and can silently change the file's encoding), which corrupts the plain-text HTML a browser expects. A plain text editor saves exactly the characters you typed and nothing else, which is why Notepad/Notepad++ is the only safe tool for this question. Because the browser and the text editor are two separate programs looking at the same file, there's no "preview" button to click after an edit — you save in the editor, then switch to the browser and refresh (F5) to see the result, every single time.

Minimum structure

<html>
  <head>
    <title>Page title</title>
  </head>
  <body>
    ...visible content...
  </body>
</html>

<html>
  <head>
    <title>Page title</title>
  </head>
  <body>
    ...visible content...
  </body>
</html>

• Every opening tag needs a matching closing tag, and tags close in reverse order (nesting): <b><i>text</i></b>.
• Self-closing: <br/>, <hr/>, <img .../>. Note </br> is wrong.
• Put attribute values in quotes: src="pic.png".

This skeleton is the minimum a browser needs to treat the file as a valid, well-formed page, and each piece has a distinct job: <html> tells the browser "everything between here is HTML," <head> holds information about the page rather than visible content (the <title> is the one required piece, shown in the browser tab — without text inside it, the mark for "title with text" isn't earned even if the <title> tags exist), and <body> holds everything the visitor actually sees. A browser is remarkably forgiving about missing tags — it will usually still render something — which is exactly why exam marking checks the raw source code rather than just the rendered page: a page that "looks right" by accident, with a tag quietly missing, still loses the mark.

Nesting matters because tags describe containers, and containers can sit inside one another but can never partially overlap. <b><i>text</i></b> is valid (the italic is entirely inside the bold); <b><i>text</b></i> is not, because the bold container closes while the italic container is still technically open — browsers try to recover from this, but the result is undefined and it's always marked wrong. Self-closing tags (<br/>, <hr/>, <img/>) exist because some elements have no content to wrap — a line break has nothing to put "inside" it — so instead of an opening and a separate closing tag, a single tag ending in /> does the whole job; writing a separate </br> closing tag is a common and consistently marked-wrong mistake, because <br> was never opened as a container in the first place.

Tables

<table border="1" cellpadding="3">
  <tr><th>Head 1</th><th>Head 2</th></tr>
  <tr><td>Cell</td><td>Cell</td></tr>
  <tr><td colspan="2">Spans both columns</td></tr>
</table>

<table border="1" cellpadding="3">
  <tr><th>Head 1</th><th>Head 2</th></tr>
  <tr><td>Cell</td><td>Cell</td></tr>
  <tr><td colspan="2">Spans both columns</td></tr>
</table>

Text must live inside <td> or <th>, never loose inside <tr>. <th> = bold, centred header cell.

An HTML table is built from three nested levels, each with one job: <table> is the whole grid, <tr> ("table row") is one horizontal row within it, and <td>/<th> ("table data" / "table header") are the individual cells within a row. A <tr> on its own has no visual box of its own to hold text in — it exists purely to group cells — so text typed directly inside a <tr>, outside any <td>, either renders in an unpredictable place or not at all, and is one of the most common "spot the fault" mistakes (see the TechnoGeek practice items). <th> is functionally identical to <td> except for its default appearance (bold, centred) and its meaning (a header describing the column or row below/beside it) — using <th> for the title row is both the correct styling shortcut and the semantically correct choice. colspan (and the less common rowspan) let a single cell visually stretch across multiple columns or rows, which is how a "merged" bottom row spanning the whole table width is built — there's no separate merge command in raw HTML, you simply give one cell a wider colspan and provide fewer <td>s on that row to match.

Links and images

• <a href="page.html">Link text</a>; e-mail: href="mailto:name@site.org".
• <img src="pic.png" width="320" alt="Describe the picture"/>. Alt text appears when the image fails or on hover. It should describe the image meaningfully.
• Centre an image: <p align="center"><img src="pic.png"/></p> or <center>…</center>.

<a> ("anchor") is the one tag responsible for every kind of hyperlink — an ordinary page link, an email link, or a jump to a named point in the same page — and it's always the href attribute, not the tag name, that decides which kind it is: a normal path (page.html) navigates there, mailto: opens the visitor's email program with that address pre-filled, and #name jumps to an element with a matching name or id elsewhere on the page. The visible link text between <a> and </a> is completely independent of the destination — exactly like Word's hyperlink model — so "Press & Media Kit" can be the readable label while the href silently points anywhere.

alt text exists for two real, practical reasons rather than as a formality: it's what displays in place of the picture if the image file fails to load or the path is wrong, and it's what a screen reader speaks aloud for a visually impaired visitor, since they can't see the image at all. "Meaningful" alt text describes what the image shows or represents ("Youth Innovate SA logo"), not a generic placeholder like "image" or "picture1.jpg" — a screen-reader user hearing "image" has learned nothing about what they've missed.

Text formatting

<h1> largest to <h6> smallest. <font face="Arial Black" color="white" size="5"> sets font, colour and size (1–7). Use & to show an ampersand safely.

The six heading levels (<h1>–<h6>) exist to describe document structure, not just to make text big — <h1> is meant to be the one main title of the page, with <h2>–<h6> representing progressively more minor sub-headings beneath it, which is exactly why a question asking for a "sub-heading under the main heading" expects a numerically higher heading tag (a smaller, nested level) immediately after the <h1>, rather than another <h1> or an arbitrarily chosen size. The <font> tag is an older, purely presentational tag (long superseded by CSS in modern web development, but still exactly what this style of exam paper and its tag sheet teach) whose three attributes are independent of each other: face picks the typeface, color the text colour, and size a relative scale from 1 to 7 — not a pixel or point value, which is why size="10" is invalid and gets flagged as a fault rather than just "very large text."

& is one of a small family of character entities that let you safely display a character HTML would otherwise try to interpret as markup — a literal & in the source can be mistaken for the start of another entity, so & is the safe, guaranteed way to render a plain ampersand. The same family includes < and > for literal < and > signs, and © for a © symbol, all following the identical logic: a reserved character gets replaced by its named entity so the browser displays the symbol instead of trying to parse it as code.

Useful tools for this paper

A couple of tools outside Notepad itself make spotting and fixing HTML faults far faster:

• View Page Source (Ctrl+U in most browsers, or right-click → View Page Source): opens the exact HTML the browser received, in a read-only tab — different from "Inspect," which can show a browser's cleaned-up, auto-corrected version of broken markup. Since marking is based on your actual source file, View Page Source is the more honest check: if something looks fine when inspected but wrong in View Source, the source is what counts.
• Browser DevTools / Inspect (F12, or right-click → Inspect): lets you click on any rendered element and see exactly which tag produced it, which is a fast way to confirm which piece of markup is responsible for something looking wrong, before you go and find it in Notepad. Useful for diagnosing, but remember any edits made directly in DevTools are temporary and never saved back to your file — the actual fix still has to be typed into Notepad and saved.
• Notepad++'s syntax highlighting and line numbers (if available over plain Notepad): colour-codes tag names, attributes and attribute values differently, which makes a missing closing quote or a misspelled tag name visibly jump out, and line numbers make it far easier to describe or relocate a specific fault than counting lines by eye in plain Notepad.
• Browser Find (Ctrl+F) on the rendered page: confirms whether specific text is actually visible on the page at all — a fast first check before diving into the source when something seems to be missing, since it immediately tells you whether the problem is "the text isn't there" versus "the text is there but wrongly formatted or positioned."
• Refresh (F5 or Ctrl+R): the browser never re-reads the file on its own — every single change made and saved in Notepad needs an explicit refresh in the browser tab before it becomes visible, which is worth building into a save → switch → refresh habit for every edit rather than only remembering it occasionally.