HTML: Documents, Tables and Forms — SE371 Slide Breakdown

Orientation

What this chapter is really for

Another merged deck. Part 1 (slides 1–33) is HTML documents and content elements; Part 2 (slides 34–71) is tables, forms and validation. The title slide even admits it covers three chapters of the textbook.

The whole chapter reduces to three skeletons you should be able to type from memory, plus a vocabulary of elements you recognise on sight. Learn the skeletons first — every lab, every later chapter and most exam questions start by writing one of them.

The one idea that ties it together

Semantic markup. HTML describes what content is, never how it looks. Appearance is CSS’s job (chapter 3). This is why you pick <h3> because it is a third-level heading, not because you want bold 16pt text, and why HTML5 gave you <header>, <nav>, <main> and friends to replace anonymous <div>s.

Where it connects

Nesting on slide 14 is literally called the DOM — that is chapter 5. GET vs POST on slides 45–46 is chapter 1’s HTTP methods. The action attribute points at a server-side resource, which you write in chapter 6. Validation on slides 64–69 splits into HTML5, JavaScript (chapter 5) and server-side (chapters 6–7).

Navigation

All 73 slides, weighted

Slides	Topic	Weight	What to do with it
1–3	Title, objectives, what HTML is	Skim	One definition worth keeping: a markup language annotates a document so the annotations stay distinct from the text.
4–5	Tags, attributes, empty elements	Memorize	An attribute is a `name="value"` pair. An empty element has no text content — it instructs the browser. In HTML5 the trailing slash is optional.
6	Semantic markup	Memorize	The single most quotable slide in the chapter. Structure in HTML, presentation in CSS.
7–13	Document skeleton: DOCTYPE, html, head, body, title/SEO	Write it	Type the skeleton from memory until it is automatic. DOCTYPE says what type of document, not which HTML version.
14–15	Nesting, parent/child/ancestor/descendant, correct nesting	Memorize	The vocabulary here is reused all through chapter 5. The rule: a child’s closing tag comes before its parent’s.
16–18	Quick tour of the ten element groups	Skim	A checklist, not new material. Use it to test yourself on what each element is for.
19–20	Headings, paragraphs, divisions, horizontal rule	Write it	Six heading levels. Pick by meaning, not by appearance. `<div>` has no intrinsic semantic value — that is the point of it.
21–22	Hyperlinks and the eight kinds of link	Write it	A link has two parts: destination and label. Know `#fragment`, `mailto:`, `tel:` and `javascript:` forms.
23	Class task — build a basic page	Write it	Do it. This is the exact shape of the practical exam question.
24–25	Absolute vs relative URLs, all six relative forms	Memorize	Same directory / child / descendant / parent (`../`) / sibling / root (`/`). Guaranteed to appear.
26	Inline text elements	Memorize	Inline elements do not break the flow of text. Know `<span>` as the inline twin of `<div>`.
27–28	Images and character entities	Memorize	`src` and `alt` are the key attributes; `title`, `width`, `height` are optional. Learn six entities by name and number.
29	Ordered, unordered and description lists	Write it	Three list types, three tag families. `<dl>/<dt>/<dd>` is the one people forget.
30–33	HTML5 semantic structure elements, figure/figcaption	Write it	Nine semantic elements. The `<figure>` rule: content that could move elsewhere on the page and the document would still make sense.
34–35	Part 2 title and objectives	Skim	Transition slides.
36–38	Tables: table/tr/td, thead/tbody/tfoot, basic structure	Write it	All content must sit inside `<td>` or `<th>`. Type the full skeleton from memory.
39–40	colspan and rowspan	Write it	The classic exam question is "draw the table this markup produces" or the reverse. Practise both directions.
41–43	Forms: why they exist, structure, action and method	Memorize	`action` = URL of the server-side resource. `method` = how the data travels. HTML forms only support GET and POST.
44–46	Query strings, GET vs POST	Memorize	Four bullets each. Note the explicit warning: POST is not sufficient from a security standpoint.
47	The eleven form control elements	Memorize	Know one line for each of button, datalist, fieldset, form, input, label, legend, optgroup, option, output, select, textarea.
48–54	Text inputs, select lists, radio buttons, checkboxes	Write it	The attribute details are the marks: `multiple`, `selected`, `checked`, and what happens when `value` is omitted.
55–58	Button controls and the revision checklist	Write it	Slide 58 is the instructor telling you exactly what to revise. Treat it as the spec for this half of the chapter.
59–62	number, range, color, date and time controls	Memorize	Learn the six date/time types and their formats — `yyyy-mm-dd`, `HH:MM:SS`, `yyyy-mm`, `yyyy-W##`.
63	Associating labels with inputs	Write it	Small slide, real marks. Accessibility is in the chapter objectives.
64–69	Validation: where, what types, how to notify, how to reduce errors	Memorize	Three levels, six validation types, three notification questions. The line to quote: server-side validation is the only validation guaranteed to run.
70–71	Color models and RGB	Skim	Feeds straight into chapter 3. RGB are additive colours; they combine to white.
73	Live Server tip	Skim	Practical: if Live Server does not open, go to `http://127.0.0.1:PORT` manually.

Write From Memory

The three skeletons

If you learn nothing else this chapter, learn these three by hand. Type them into a blank file until you stop thinking about them.

1. The document

index.htmlSlides 7–13[ RUN IT → ]

<!DOCTYPE html>                        <!-- what TYPE of document, not which HTML version -->
<html lang="en">                     <!-- root element; lang is optional but tells the browser the language -->
<head>                                <!-- DESCRIBES the document: nothing here is displayed -->
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Riyadh Sewing Supplies</title>   <!-- matters for SEO -->
    <meta name="description" content="Get everything you need to sew your next garment.
                 Open Saturday-Thursday, located in Al Olaya District, Riyadh.">
    <link rel="stylesheet" href="css/styles.css">
</head>
<body>                                <!-- CONTAINS what the browser displays -->
    <h1>Hello</h1>
</body>
</html>

Slide 8 gives Google’s own rule for a title: unique to the page, clear, concise, accurately describing the contents. The slides contrast a bad and a good meta description — “Sewing supplies, sewing machines, bobbins, needles” (a keyword dump) against a sentence that tells a human what the page offers and where the shop is. Expect to be asked to improve a bad one.

2. The table

tables.htmlSlides 36–38[ RUN IT → ]

<table>
  <thead>                        <!-- header rows -->
    <tr>
      <th>Month</th>              <!-- th = header cell -->
      <th>Savings</th>
    </tr>
  </thead>
  <tbody>                        <!-- the data -->
    <tr>
      <td>January</td>            <!-- ALL content must be inside td or th -->
      <td>100 SAR</td>
    </tr>
    <tr>
      <td>February</td>
      <td>180 SAR</td>
    </tr>
  </tbody>
  <tfoot>                        <!-- summary rows -->
    <tr>
      <td>Total</td>
      <td>280 SAR</td>
    </tr>
  </tfoot>
</table>

3. The form

<!-- action = URL of the server-side resource that PROCESSES the data
     method = how the data is TRANSMITTED. HTML forms allow only get or post. -->
<form action="action-page.html" method="get">

  <!-- for="" must match the input's id="" — this is what makes the label clickable -->
  <label for="firstname">First name:</label>
  <input type="text" id="firstname" name="fname"><br><br>

  <label for="lastname">Last name:</label>
  <input type="text" id="lastname" name="lname"><br><br>

  <input type="submit" value="Submit">
</form>

<!-- Submitting sends:  action-page.html?fname=Shoug&lname=Alomran
     name=  becomes the KEY in the query string. No name attribute = not sent. -->

The attribute that gets forgotten: name. id is for the label and for CSS/JavaScript. name is what becomes the key in the query string. An input without a name is simply never submitted — and this is the single most common reason a lab form “does nothing”.

Slides 14–33

Content elements: links, lists, images, semantics

Nesting and the family vocabulary

Slide 14 introduces terms you will use constantly in chapter 5, and names the concept outright: this hierarchy is the Document Object Model.

nesting.htmlSlide 14–15[ RUN IT → ]

<body>                              ← ancestor of everything below
  <article>                        ← child of body, parent of h1 and p
    <h1>Title</h1>                 ← child of article, descendant of body
    <p>Text with <strong>emphasis</strong></p>
  </article>
</body>

RULE: a child's closing tag must come BEFORE its parent's.
  ✓  <p><strong>hi</strong></p>      correct
  ✗  <p><strong>hi</p></strong>      overlapping — invalid

Links — all eight kinds on one slide

hyperlinks.htmlSlides 21–22 + the slide 33 home task[ RUN IT → ]

<!-- destination = href, label = the text between the tags -->
<a href="https://google.com">external site</a>
<a href="about.html">another page on this site</a>
<a href="#links">a place on THIS page</a>
<a href="https://google.com/#links">a place on ANOTHER page</a>
<a href="mailto:[email protected]">open the email program</a>
<a href="javascript:runProgram()">run a JavaScript function</a>
<a href="tel:0521212121">make a phone call</a>
<a href="http://m.me/PAGE_USERNAME">open another program</a>

<!-- the target of a #fragment is any element with a matching id -->
<h2 id="links">Links section</h2>

<!-- an image can be the label — this is the "clickable image" home task -->
<a href="gallery.html"><img src="trulli.jpg" alt="Trulli houses"></a>

Relative URLs — all six forms

Absolute means the full URL: protocol, domain, path, filename. It is required when the resource is on another site. Relative means the browser asks the current server, and comes in exactly six shapes:

Form	Written as	Meaning
1. Same directory	`page.html`	Just the file name.
2. Child directory	`images/photo.jpg`	Subdirectory name, slash, file name.
3. Grandchild / descendant	`assets/img/icons/x.svg`	Each subdirectory name in turn, separated by slashes.
4. Parent / ancestor	`../styles.css` · `../../a.html`	`../` goes up one level; string several together to go higher.
5. Sibling	`../css/styles.css`	Up with `../`, then down like a child directory.
6. Root reference	`/images/logo.png`	Leading `/` starts from the server root, then down as normal.

Root vs relative, the practical difference: a root reference (/css/styles.css) keeps working no matter how deep the page is, which is why it is safer for a shared stylesheet. A same-directory reference breaks the moment you move the file into a subfolder.

Lists — three kinds

lists.htmlSlide 29

<!-- 1. ORDERED: items with a set order. type = I, A, a, i -->
<ol type="I">
  <li>First</li>
  <li>Second</li>
</ol>

<!-- 2. UNORDERED: no particular order -->
<ul style="list-style-type:square">   <!-- disc | circle | square -->
  <li>Chrome</li>
  <li>Firefox</li>
</ul>

<!-- 3. DESCRIPTION: name + description pairs. dt = term, dd = definition -->
<dl>
  <dt>HTTP</dt>
  <dd>The protocol used for web communication.</dd>
  <dt>DNS</dt>
  <dd>Resolves domain names to IP addresses.</dd>
</dl>

Images and character entities

images-entities.htmlSlides 27–28

<!-- img is an EMPTY element: no closing tag, no text content.
     src and alt are the key attributes; title/width/height are optional. -->
<img src="trulli.jpg" alt="Trulli houses in Puglia" width="500" height="333">

<!-- Entities: characters you cannot type, or that HTML has reserved.
     Use the NAME or the NUMBER — both work. -->
   &nbsp;   &#160;    non-breaking space
   &lt;     &#60;     <   ← reserved: HTML would read it as a tag
   &gt;     &#62;     >
   &copy;   &#169;    ©
   &euro;   &#8364;   €
   &trade;  &#8482;   ™

<p>To write a tag in text: <code>&lt;div&gt;</code> renders as <div></p>

Inline elements — do not break the flow of text

Element	Use
`<a>`	Anchor, used for hyperlinks.
`<abbr>`	An abbreviation.
`<br>`	Line break.
`<cite>`	A citation — a reference to another work.
`<code>`	Displaying markup or programming code.
`<em>`	Emphasis.
`<small>`	Fine print — nonvital text such as copyright or legal notices.
`<span>`	The inline equivalent of `<div>`; marks text for CSS.
`<strong>`	Content that is strongly important.
`<time>`	Time and date data.

HTML5 semantic structure

semantic-page.htmlSlides 30–32[ RUN IT → ]

<body>
  <header>                        <!-- intro content for the page or a section -->
    <nav>                          <!-- a block of navigation links -->
      <a href="pagehtml.html">HTML</a> |
      <a href="pagecss.html">CSS</a> |
      <a href="pagejs.html">JavaScript</a>
    </nav>
  </header>

  <main>                          <!-- the dominant content. Only ONE per page. -->
    <h1>Survey</h1>
    <section>                     <!-- a thematic grouping, usually with a heading -->
      <h2>Most Popular Browsers</h2>
      <article>                   <!-- self-contained: makes sense on its own -->
        <h3>Google Chrome</h3>
        <p>Released by Google in 2008.</p>
      </article>
    </section>

    <figure>                      <!-- content that could MOVE and the document still makes sense -->
      <img src="chart.png" alt="Browser market share">
      <figcaption>Fig 1. Market share, 2026.</figcaption>
    </figure>
  </main>

  <aside>Related links</aside>       <!-- tangential content -->
  <footer>&copy; 2026 Shoug</footer>
</body>

The <figure> test, stated exactly as the slide does: could this content be moved to a different place in the document and the rest still make sense? If yes, it is a figure — and it need not be an image.

Slides 41–63

Every form control, with the attributes that carry the marks

GET vs POST, as this chapter states it

GET	POST
Data is clearly visible in the address bar — helpful in development, a problem in production.	Data can contain binary data.
Data remains in browser history and cache — a security risk on public computers.	Data is hidden from the user (though visible in the DevTools Network/Payload tab).
Data can be bookmarked.	Submitted data is not stored in cache, history or bookmarks.
There is a limit on the number of characters returned.	No comparable character limit.

The slides add two warnings worth quoting back in an exam. First: HTML forms accept only get or post — DELETE and UPDATE have to be sent with JavaScript. Second, verbatim: “while the POST method hides form data, any user could easily inspect the HTTP header. As a result, the POST method is NOT sufficient from a security standpoint.”

Text input controls

text-controls.htmlSlide 48[ RUN IT → ]

<input type="text"     name="fname"  placeholder="Shoug">
<input type="password" name="pwd"    required>      <!-- required = HTML5 built-in validation -->
<input type="email"    name="mail">                 <!-- browser checks the @ format -->
<input type="tel"      name="phone">
<input type="search"   name="q">
<input type="url"      name="site">
<input type="hidden"   name="id" value="42">     <!-- sent, but not shown -->

<!-- multiline text: a CONTAINER, not an empty element -->
<textarea name="bio" rows="5" cols="40"></textarea>

Choice controls: select, radio, checkbox

select.htmlSlides 50–51[ RUN IT → ]

<!-- SELECT: a drop-down list -->
<label for="cars">Choose a car:</label>
<select name="cars" id="cars">
  <option value="volvo">Volvo</option>
  <option value="saab" selected>Saab</option>   <!-- selected = the DEFAULT -->
  <option value="audi">Audi</option>
</select>

<!-- multiple = more than one item can be chosen.
     No value attribute? The text inside the container is sent instead. -->
<select name="mult_cars_var" id="multipl_cars" multiple>
  <option>Volvo</option>        <!-- sends cars=Volvo -->
  <option>Saab</option>
</select>

<!-- optgroup groups related options -->
<select name="cars_optg_var" multiple>
  <optgroup label="Swedish Cars">
    <option value="volvo">Volvo</option>
    <option value="saab">Saab</option>
  </optgroup>
  <optgroup label="German Cars">
    <option value="audi">Audi</option>
  </optgroup>
</select>

radio-checkbox.htmlSlides 53–54[ RUN IT → ]

<!-- RADIO: pick ONE from a small, visible list.
     The SHARED name is what makes them mutually exclusive.
     value is what gets sent:  city=1  if Riyadh is selected. -->
<input type="radio" id="riyadh" name="city" value="1" checked>
<label for="riyadh">Riyadh</label>
<input type="radio" id="jeddah" name="city" value="2">
<label for="jeddah">Jeddah</label>

<!-- CHECKBOX: a yes/no, on/off answer. Each CHECKED box sends its value.
     Different names = independent answers. -->
<input type="checkbox" id="news" name="news" value="yes" checked>
<label for="news">Send me the newsletter</label>

radio vs checkbox in one line: radios share a name so only one can win; checkboxes each keep their own name so each answers independently. Both use checked for the default.

Buttons — five ways, three behaviours

buttons.htmlSlides 55–57[ RUN IT → ]

<input type="submit" value="Send">    <!-- submits the form data to the server -->
<input type="reset"  value="Clear">   <!-- clears data the user already entered -->
<input type="button" value="Count">   <!-- does NOTHING without JavaScript -->
<input type="image"  src="go.png" alt="Go"> <!-- a submit button drawn as an image -->

<!-- <button> is a CONTAINER, so it allows far more customisation:
     you can put markup, icons and images inside it. -->
<button type="submit"><strong>Send</strong> <img src="plane.png" alt=""></button>

<!-- WARNING from slide 57: type="submit" is the DEFAULT for <button>.
     A <button> with no type inside a form will submit it. -->
<button type="button" onclick="doSomething()">Safe</button>

HTML5 numeric, colour, date and time controls

html5-controls.htmlSlides 59–60[ RUN IT → ]

<!-- number and range reduce the need for client-side numeric validation.
     You still validate on the SERVER for security. -->
<input type="number" name="qty"  min="1" max="10" step="1">
<input type="range"  name="vol"  min="0" max="100" value="50">
<input type="color"  name="theme" value="#b829ea">

Type	What it collects	Format
`date`	A general date.	`yyyy-mm-dd`
`time`	A time.	`HH:MM:SS`
`datetime`	A date and time.	—
`datetime-local`	A date and time with no time zone.	—
`month`	A month within a year.	`yyyy-mm`
`week`	A week within a year.	`yyyy-W##`

The live example for these is 6-date.html.

Labels, properly

labels.htmlSlide 63

<!-- Method 1: for= matches id=. The two elements can be anywhere. -->
<label for="email">Email address</label>
<input type="email" id="email" name="email">

<!-- Method 2: wrap the input. No for/id needed. -->
<label>Email address <input type="email" name="email"></label>

Why it matters (it is in the chapter objectives — "improve accessibility"):
  • screen readers announce the label when the field is focused
  • clicking the label focuses the field — a much larger click target
  • it is the accessible way to label a radio button or checkbox

<!-- fieldset + legend group related controls, e.g. a set of radio buttons -->
<fieldset>
  <legend>Choose your city</legend>
  <!-- radios here -->
</fieldset>

Slides 64–69

Validation — the concept that spans the whole course

Slide 64 opens with the line to remember: user input must never be trusted. It may be missing, wrongly formatted, or contain JavaScript or SQL intended as an attack.

The three levels

Level	What it is	Why it is not enough
1. HTML5 client	The browser performs basic validation from attributes like `required`, `type="email"`, `min`/`max` and `pattern`.	Free, but trivially bypassed — the user can edit the markup in DevTools.
2. JavaScript client	Dramatically improves the user experience of data-entry forms; the slides call it an essential feature of any real-world site that uses forms. This is chapter 5.	Explicitly stated on the slide: not sufficient. The user can disable JavaScript or send the request directly.
3. Server-side server	Arguably the most important, because it is the only validation guaranteed to run. This is chapters 6 and 7.	— Develop server-side functionality as if no client-side validation happened at all.

Say this sentence in the exam: “Client-side validation exists for the user’s convenience; server-side validation exists for correctness and security, because it is the only one guaranteed to run.” It answers most validation questions on its own.

The six types of validation

Type	Example
Required information	Some fields simply cannot be left empty.
Correct data type	Numbers and dates must obey their type’s rules.
Correct format	Postal codes, credit card numbers and ID numbers follow pattern rules.
Comparison	A value judged against another value — confirm password, or end date after start date.
Range check	A number that must fall between a minimum and a maximum.
Custom	Any rule specific to the application.

Notifying the user — three questions the message must answer

What is the problem? Users will not read a lengthy message to work out what to change.
Where is the problem? The indication belongs near the field that caused it.
How do I fix it? Do not just say the date is wrong — say what format you expect.

Five ways to reduce errors before they happen

Put textual hints on the form itself.
Use tool tips or pop-overs for context-sensitive help — via CSS or the title attribute.
Provide a JavaScript input mask, e.g. (999)-999-9999.
Choose good default values for text fields.
Pick a better input type than text. A type="date" field cannot be given a badly formatted date in the first place.

validation-by-attribute.htmlSlides 64–69 as code

<!-- Level 1 in practice: every one of these is a validation rule the
     browser enforces for free, before a single line of JavaScript. -->
<input type="text"   name="user"  required
       minlength="3" maxlength="20">              ← required + length

<input type="email"  name="mail"  required>          ← correct data type

<input type="number" name="age"   min="18" max="99">   ← range check

<input type="tel"    name="phone"
       pattern="05[0-9]{8}"                        ← correct format
       title="Saudi mobile: 05 followed by 8 digits">  ← "how do I fix it?"

<!-- Turn the browser's checks off to test your own:  <form novalidate> -->

Colour models (slides 70–71)

Three ways to describe colour: names, RGB and HSL (hue, saturation, lightness). RGB works because the visible spectrum can be reproduced by combining red, green and blue light, and each pixel is made of tiny red, green and blue subpixels. Because the three combine to produce white, they are called additive colours. Chapter 3 picks this up on its colour-values slide.

Marks Lost Here

The seven things people get wrong

Using id where the form needs name

An input with an id but no name is styled fine, selectable from JavaScript, and never submitted. The query string simply will not contain it.

Fix: name is for the server. id is for the label, CSS and JavaScript. Real forms usually need both.

Radio buttons that do not deselect each other

If each radio has a different name, the browser treats them as unrelated single-option groups, so all of them can be selected at once.

Fix: Radios in one group must share the same name. Different value, same name.

A <button> that reloads the page

You add <button onclick="calc()"> inside a form and the page flashes and resets. The default type for <button> is submit, so it submitted the form.

Fix: Write <button type="button"> for anything that is not meant to submit. Slide 57 says this explicitly.

Choosing heading levels for their size

Picking <h3> because you want smaller bold text is exactly the anti-example on slide 19. It breaks the document outline and the semantic-markup principle from slide 6.

Fix: Choose the level that is semantically right, then resize it in CSS.

Mixing up colspan and rowspan

colspan makes a cell wider — it eats cells to its right. rowspan makes it taller — it eats cells below. People reliably swap them under pressure.

Fix: Read them as instructions: span this many columns = horizontal; span this many rows = vertical. And remember the spanned-over cells must be deleted from the following rows, or the table grows extra columns.

Believing POST is secure

It appears again here because the slides warn about it twice. POST hides data from the address bar, not from the user — the Network/Payload tab in DevTools shows it in full.

Fix: POST controls where the data travels. HTTPS controls whether anyone else can read it. Server-side validation controls whether you can trust it.

Assuming required is enough

HTML5 validation runs in the browser, and the browser belongs to the user. Deleting the attribute in DevTools, or sending the request with curl, skips it entirely.

Fix: Treat every client-side check as a convenience. Re-validate everything on the server — the only validation guaranteed to run.

One Screen

Chapter 2 on a single screen

Document

<!DOCTYPE html> — type, not version
<html lang="en"> — root element
<head> — describes the document
<body> — what is displayed
<meta charset>, <title>, <meta name="description">

Semantic HTML5

header nav main section
article aside footer
figure + figcaption
Use these instead of anonymous divs

Tables

table > thead/tbody/tfoot > tr > th/td
All content lives in td or th
colspan="2" — wider, eats cells to the right
rowspan="2" — taller, eats cells below
Delete the cells that got spanned over

Form basics

action — URL that processes the data
method — get or post only
name — becomes the query-string key
id — for label for=, CSS, JS
Query string: ?k=v&k=v, URL-encoded

Controls

input: text, password, email, tel, url, search, hidden
input: number, range, color, date, time, month, week
textarea — multiline, a container
select + option + optgroup
multiple · selected · checked · required

Buttons

submit — sends the form
reset — clears entered data
button — needs JavaScript
image — submit drawn as an image
<button> — container, defaults to submit

Relative URLs

page.html — same directory
img/x.jpg — child
../x.css — parent
../css/x.css — sibling
/css/x.css — from the server root

Entities

    non-breaking space
< < > >
™ ™

Validation

1. HTML5 — free, bypassable
2. JavaScript — good UX, not sufficient
3. Server — the only one guaranteed to run
Types: required, data type, format, comparison, range, custom

Type It Blind

Open a blank file and type these without looking

This chapter is graded on production, not recognition. Reading the slides again will not help; typing will. Work through the list in a blank .html file with Live Server running.

The full HTML5 document skeleton, including charset, viewport, title and a meta description.
A table with thead, tbody and tfoot, three columns and three data rows.
The same table, but with the first cell of row 2 spanning two columns — and remember to delete the displaced cell.
A table where the first column spans three rows.
A registration form with text, email, password, a date, a number with min/max and a submit button — every field labelled.
A select list with an optgroup, a default selected option, and one option with no value.
A group of three radio buttons that actually behave as a group, with the second one checked by default.
Two checkboxes that answer independently, with one checked by default.
A page using all nine HTML5 semantic elements at least once.
A figure with a figcaption, and a one-line justification of why that content qualifies as a figure.
Six links: external, internal page, same-page fragment, mailto, tel, and an image used as the link label.
A description list defining four terms from chapter 1.
The same stylesheet referenced four ways: same directory, child, parent and root reference.
A form that demonstrates all six validation types using HTML5 attributes only.
Write out what query string ? the browser builds when your registration form is submitted with GET, then check it in the address bar.

Two printable cheat sheets already sit in your study material: HTML cheat sheet Q1 and HTML cheat sheet 2.

Self-Check