FS26
Ctrl K
Foundation F01 · Lesson 02

Lab — Semantic HTML for Application Interfaces

≈ 3 min · beginner prerequisite
Objectives

By the end

  • Implement the concept without copying a full solution.
  • Compare prediction with actual runtime evidence.
  • Diagnose one intentionally introduced failure.

Lab: Semantic HTML for Application Interfaces

Purpose This lab converts the previous explanation into a small piece of evidence you created yourself. Do not begin by copying the finished example. Start with the behavior you expect, then make the computer prove or disprove your model.

Your task Build the smallest runnable example for “Semantic HTML for Application Interfaces”, predict its output, change one assumption, and explain the difference using concrete evidence.

Working method 1. Create the smallest clean starting point. 2. Predict the first result in writing. 3. Implement only enough to test that prediction. 4. Run it and capture the result. 5. Add one intentional failure or changed assumption. 6. Diagnose from evidence before editing randomly. 7. Restore the correct behavior. 8. Close the reference and reproduce the important part from memory.

Why this is separate from the concept lesson Reading can create familiarity without recall. The separate lab forces retrieval, execution, and debugging. Those three abilities are what later framework lessons assume when the codebase becomes larger.

Definition of done You have a runnable example, one recorded prediction, one successful result, one controlled failure with diagnosis, and a short explain-back in your own words.

Hands-on foundation studio

Predict → build → run → break → explain

Objectives

  • Use Semantic HTML for Application Interfaces in a runnable example rather than only describing it.
  • Predict a result before execution and compare prediction with evidence.
  • Introduce one safe failure and diagnose the cause systematically.

Setup

  1. Create or reuse a disposable practice folder so experiments do not pollute the production TaskFlow tree.
  2. Open the terminal and editor side-by-side. Keep browser DevTools visible for browser work.
  3. Write the expected behavior in one sentence before adding code.

Do the work

  1. 01

    Build the smallest runnable example for “Semantic HTML for Application Interfaces”, predict its output, change one assumption, and explain the difference using concrete evidence.

  2. 02

    Run the smallest version first. Capture exact terminal/browser/database output before adding a second concept.

  3. 03

    Change one input, ordering, state transition, or configuration assumption. Predict the new output, then run it.

  4. 04

    Explain the result in terms of runtime behavior, data flow, identity, or ownership—not “the framework did it”.

  5. 05

    Rebuild the example once without looking at the completed version.

htmlIndependent lab: Build a semantic TaskFlow shell
<main>
  <header><h1>My Tasks</h1></header>
  <form aria-label="Create task">
    <label for="title">Task title</label>
    <input id="title" name="title" required />
    <button>Create task</button>
  </form>
  <ul aria-label="Tasks"></ul>
</main>

Type it, predict it, run it, then change one assumption. The goal is not finishing the snippet; the goal is being able to explain the result.

Expected evidence

  • The example runs from a documented command or browser action.
  • Observed output matches a prediction you wrote before execution.
  • The controlled failure produces a specific, explainable symptom.
  • After the fix, the original reproduction passes again.

Intentional failure

Deliberately violate one assumption relevant to “Semantic HTML for Application Interfaces”. Keep the failure small enough that you can identify a single causal change.

Explain it back

  1. What is the simplest accurate explanation of Semantic HTML for Application Interfaces?
  2. Which input/state is the source of truth?
  3. What exact evidence distinguishes success from accidental success?
  4. What failure did you reproduce and how did you isolate it?
Checkpoint

You can continue when you can reproduce the core behavior of “Semantic HTML for Application Interfaces” from a blank file or clean state and explain one failure without reopening the finished solution.

Practice before completion

Small experiment, intentional failure, explain-back

Build the smallest example that demonstrates this lesson. Then break one relevant assumption and diagnose it using terminal/DevTools evidence. Finally explain the concept without using a framework name.

← Semantic HTML for Application InterfacesCSS Cascade, Box Model, and Specificity →