Northeast Mississippi Community CollegeCourse Notes

Web Development · Lesson 2

HTML5 Coding

Create semantic, valid, readable HTML documents with a predictable skeleton, meaningful elements, safe comments, and a validation workflow.

  • html5
  • semantic-html
  • validation
  • accessibility

Lesson purpose

Lesson 2 moves students from recognizing web technologies to writing a complete HTML document. The main goal is to create markup that communicates structure clearly to browsers, assistive technology, validators, other developers, and the student who will maintain the page later.

A successful student should leave the lesson able to create a valid page skeleton, organize content with appropriate elements, document the source with safe comments, and test the page instead of assuming that browser output proves the markup is correct.

Learning objectives

Students should be able to:

  • use HTML elements and tags to format paragraphs and text
  • add comments that document page or site creation
  • explain why a site should follow one HTML standard consistently
  • validate a page against technical and audience requirements
  • create a webpage using modern HTML
  • test and validate web documents

1. HTML documents and consistent standards

Main idea

An HTML document is a collection of elements that represent content and structure. A user agent, usually a browser, interprets those elements and presents the page. The home page is the default entry page for a website.

Talking points

  • HTML provides meaning and structure. CSS will control most presentation.
  • Browsers can recover from many mistakes, but browser recovery may differ and can hide invalid markup.
  • Choose one current standard and apply it consistently throughout the page and site.
  • Consistent syntax improves validation, maintenance, and predictable rendering.
  • The lesson uses modern HTML. Older HTML and XHTML examples help explain why current syntax is simpler.

Check for understanding

  • What does a browser do with an HTML document?
  • Why can a page appear correct even when the markup contains errors?
  • What problems can occur when developers mix conventions from different standards?

2. Elements, tags, content, attributes, and values

Element anatomy

<p class="intro">Plan before you build.</p>

Talking points for each part

  • Element: p identifies a paragraph.
  • Start tag: <p class="intro"> begins the element.
  • Attribute: class adds information supported by the element.
  • Value: "intro" gives the attribute its setting. Quotation marks make the boundary clear.
  • Content: Plan before you build. is the text contained by the element.
  • End tag: </p> closes the paragraph. The slash appears before the element name.

Container elements and void elements

Container elements use a start tag and an end tag:

<strong>Important information</strong>

Void elements do not wrap content and do not have HTML end tags:

<meta charset="utf-8">
<br>

Instructor emphasis

  • Students should identify the element before discussing how it looks.
  • Close every container element.
  • Use lowercase element and attribute names for consistency.
  • Put quotation marks around attribute values.
  • A missing quotation mark can cause the browser to treat later markup as part of the value.
  • The textbook sometimes shows <br/>. The PowerPoint uses the modern <br> form. Both may render, but the class should use one convention consistently.

3. The HTML document skeleton

Complete example

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="description" content="Description of the page">
  <meta name="author" content="Author Name">
  <title>Page Title</title>
</head>
<body>
  <h1>Page Title</h1>
  <p>Visible page content goes here.</p>
</body>
</html>

<!doctype html>

  • Place the doctype first.
  • It tells the browser to interpret the document using modern standards.
  • The modern declaration is short and does not point to a separate Document Type Definition.
  • A validator uses the declared document type when it checks the markup.
  • The declaration is case insensitive. The class may use lowercase consistently with the PowerPoint examples.

<html lang="en">

  • The html element is the root container.
  • It contains the head and body.
  • The lang attribute identifies the document’s primary language.
  • Language information helps browsers, search tools, translation tools, and assistive technology interpret content correctly.
  • All document content except the doctype belongs inside the root element.
  • The head describes the document.
  • It contains metadata, the page title, and relationships to resources such as stylesheets.
  • Head content normally does not appear as the visible page body.

Metadata

  • <meta charset="utf-8"> declares the character encoding.
  • Description and author metadata can document the page’s purpose and ownership.
  • Include metadata when it serves a clear purpose.
  • The book demonstrates keywords and description metadata. The PowerPoint reinforces purpose-driven metadata.

<title>

  • The title names the document.
  • Browsers use it for the tab or window title.
  • History and bookmark interfaces can also use it.
  • The title should identify the specific page rather than use a vague label such as “Home.”

A stylesheet relationship belongs in the head:

<link rel="stylesheet" href="styles/site.css">

Lesson 2 introduces the role and placement of link. CSS details come later. The reference should use a portable relative path rather than a path tied to one computer.

<body>

  • The body contains the page experience.
  • Headings, paragraphs, lists, links, images, media, forms, and controls belong here.
  • HTML should communicate the content’s meaning before CSS changes its appearance.
  • Avoid obsolete body attributes for presentation. Later lessons will use CSS.

Teaching question

Which lines help the browser understand the document, and which lines produce visible content?

4. Website files and development environment

File organization

A simple starting structure might be:

project-name/
├── index.html
├── styles/
├── images/
└── scripts/

Talking points

  • Keep each website inside a clearly named project folder.
  • Use stable, meaningful, lowercase filenames.
  • Display file extensions so students can distinguish .html, .css, and .txt.
  • Save HTML as plain text. Word processors can add formatting that does not belong in source code.
  • Use relative references so the site can move to another computer or server.
  • Separate styles, images, and scripts into logical folders as the project grows.
  • Test in multiple browsers because the course treats browser testing as part of development.
  • Developer tools can help students inspect the DOM, network requests, and browser errors.

Common setup mistake

A file named index.html.txt remains a text file even if the student expected a webpage. Confirm the full filename before debugging the HTML.

5. Paragraphs and line breaks

Example

<p>First complete thought.</p>
<p>
  Second paragraph with a line break<br>
  inside the same thought.
</p>

p

  • A paragraph is a block-level element.
  • It represents a complete paragraph or related block of text.
  • Browsers place paragraphs in the normal block flow.
  • Use separate paragraphs when the meaning calls for separate thoughts.

br

  • A line break moves following content to a new line without creating a new paragraph.
  • It is a void element and has no end tag.
  • Use it when the line break is meaningful within one block, such as an address or short verse.
  • Do not repeat br elements to create visual spacing. CSS will control spacing later.

Teaching question

Would the content still represent one thought after the break? If not, a new paragraph is probably more appropriate.

6. Heading hierarchy

Example

<h1>Student Resume</h1>

<h2>Education</h2>
<h3>Northeast Mississippi Community College</h3>

<h2>Experience</h2>
<h3>Job Title</h3>

Talking points

  • h1 names the primary topic of the page.
  • h2 introduces a major section under that topic.
  • h3 through h6 represent deeper levels when the content hierarchy needs them.
  • Choose heading levels by structure rather than default font size.
  • CSS can change appearance later without changing the hierarchy.
  • A second item inside the same section usually repeats the appropriate lower-level heading rather than creating another major section.

7. Proper nesting

Correct

<h2><em>Important update</em></h2>

Incorrect

<h2><em>Broken boundaries</h2></em>

Talking points

  • The outer element opens first.
  • The inner element opens second.
  • The inner element closes first.
  • The outer element closes last.
  • A browser may repair crossed tags in its DOM, but the original source remains invalid and unreliable.
  • Indentation should make the nesting visible.

Quick activity

Ask students to draw brackets around the outer and inner elements before they run the validator.

8. Preformatted text, indentation, and alignment

pre

The pre element preserves line breaks and runs of spaces:

<pre>
Name: Student Name
Role: Web Developer
</pre>

Use pre only when whitespace carries meaning, such as code, an ASCII diagram, or genuinely preformatted text. Do not use it as a general page-layout tool.

Indentation and alignment

  • Indent nested source code so the document tree is easy to follow.
  • Source indentation improves readability but does not replace semantic structure.
  • CSS properties such as text-align, margins, and padding control presentation.
  • blockquote represents a quoted section. It should not serve as a centering or indentation shortcut.
  • HTML carries meaning. CSS carries visual presentation.

9. Block-level and text-level elements

Block-level role

Paragraphs, headings, and lists establish larger regions in the normal document flow.

Text-level role

Text-level or phrasing elements add meaning within a line or paragraph without automatically creating a new block.

Teaching comparison

Ask students to predict whether content following p begins a new block and whether content following strong remains in the same line of text.

10. Semantic emphasis and visual styling

Example

<p>
  Submit the form by <strong>Friday</strong>.
  The deadline is <em>this week</em>.
</p>

strong and em

  • strong communicates strong importance.
  • em communicates stress emphasis that can affect meaning.
  • Browsers often render them as bold and italic, but their purpose is semantic.
  • Assistive technology and other user agents can interpret meaning even when no visual styling appears.

b and i

  • b draws attention without adding the same importance as strong.
  • i can mark alternate voice or text convention without adding the same stress emphasis as em.
  • CSS controls the final font weight, style, and appearance.

Teaching question

If all CSS and default bold or italic styling disappeared, would the selected element still describe the intended meaning?

11. Technical text elements

Examples

<p>Use the <code>title</code> element in the head.</p>
<p>Press <kbd>Command</kbd> + <kbd>S</kbd> to save.</p>
<p>The program displays <samp>Validation complete</samp>.</p>
<p>The variable <var>x</var> stores the current value.</p>

Talking points

  • code identifies a fragment of computer code.
  • kbd identifies input the user types or keys the user presses.
  • samp identifies sample program output.
  • var identifies a variable.
  • dfn can mark the defining instance of a term.
  • Browsers often display several of these in a monospace or italic style, but the elements communicate different meanings.
  • Students do not need to memorize every phrasing element. They should understand why meaningful markup helps browsers and developers distinguish content.

12. Lists

Unordered list

Use an unordered list when order does not affect meaning:

<h2>Skills</h2>
<ul>
  <li>HTML structure</li>
  <li>Problem solving</li>
  <li>Communication</li>
</ul>

Ordered list

Use an ordered list when sequence or rank matters:

<h2>Validation Process</h2>
<ol>
  <li>Open the validator.</li>
  <li>Check the document.</li>
  <li>Correct the first useful error.</li>
  <li>Validate again.</li>
</ol>

Talking points

  • ul groups related items without implying a required order.
  • ol communicates that sequence or rank matters.
  • Each item belongs inside an li.
  • Close every list item even where a browser might infer the ending.
  • Do not place loose item text directly inside ul or ol.
  • A description list uses dl, dt, and dd when terms need associated descriptions.

Teaching question

Would numbering the items change their meaning? If yes, use ol. If no, use ul.

13. Good coding practice

Forward compatibility

Write markup that is easier to maintain as standards and browsers change:

  • close container elements
  • use lowercase element and attribute names
  • quote attribute values
  • use current, supported elements
  • avoid depending on browser error recovery

Universal markup and consistency

  • Follow one standard consistently.
  • Understand the requirements of the selected standard.
  • Avoid mixing outdated habits into otherwise modern markup.
  • Test the page in the browsers and environments the audience will use.

Readability

  • Put logical elements on separate lines.
  • Indent nested elements consistently.
  • Use meaningful filenames, class names, and identifiers.
  • Keep related content together.
  • Verify that formatting changes to the source do not change the rendered result unexpectedly.

14. HTML comments

Syntax

<!-- Explain why this content or decision exists. -->

Appropriate uses

  • document the reason for a temporary decision
  • help another developer understand an important section
  • remind the author why a change was made
  • temporarily comment out markup while testing
  • identify authorship or validation status when required by the assignment

Safety boundary

Comments do not appear in the rendered page, but users can still view them in the page source. Never put passwords, access tokens, private contact information, or other secrets in client-side comments.

Commenting out a block

<!--
<p>Temporary announcement</p>
<ul>
  <li>First item</li>
  <li>Second item</li>
</ul>
-->

After adding or removing comments, validate again. Comment boundaries can hide needed tags or interrupt a nesting sequence.

15. Validation and browser testing

Validation loop

  1. Validate: Run the current document through a markup checker.
  2. Locate: Read the first meaningful error and inspect its context.
  3. Repair: Correct the source problem rather than each later symptom.
  4. Retest: Validate again and open the page in supported browsers.

Talking points

  • A clean validator result provides evidence that the markup follows the standard.
  • Validation does not prove that the page is usable, accessible, accurate, or visually successful.
  • Browser output does not prove that the source is valid.
  • One missing quotation mark or end tag can produce several later errors.
  • Fix the earliest useful error first because later messages may disappear.
  • Recheck after content, code, or browser changes.

Suggested classroom routine

  • Save the file.
  • Refresh the browser.
  • Read the page for content mistakes.
  • Validate the source.
  • Inspect the first error.
  • Correct and repeat.
  • Open the page in a second browser.

16. Responsive design foundation

Main idea

Responsive pages adapt to changing screen sizes. Lesson 2 introduces the idea before students build the full CSS implementation.

Talking points

  • Available space changes across phones, tablets, laptops, and larger displays.
  • HTML content should remain understandable when a future layout changes or columns collapse.
  • Semantic order matters because CSS may rearrange the visual presentation.
  • Flexible images and media queries will become part of later styling work.
  • HTML preserves meaning while CSS adapts presentation.

Discussion prompt

If all columns collapsed into one vertical flow, would the content still appear in a sensible reading order?

17. Classroom application

Mark, trace, predict, verify

  1. Mark: Label elements, start tags, end tags, attributes, values, and content.
  2. Trace: Sketch the document tree and nesting.
  3. Predict: State what the browser should render.
  4. Verify: Open the page, inspect it, validate it, and explain any difference.

Lesson 2 application project

Students should:

  • create the project folder and index.html
  • add the document skeleton
  • create a meaningful heading hierarchy
  • add paragraphs and appropriate emphasis
  • use at least one correctly structured list
  • add one purposeful and safe comment
  • format the source for readability
  • validate the document
  • test it in at least two browsers

Related semester project: [[IST 1433 Resume Website - Lesson 2: HTML Foundation]]

18. Knowledge check and corrections

Problem 1

A heading begins inside em, but the heading closes before em.

Correction: Close the inner element before the outer element.

<h2><em>Correctly nested heading</em></h2>

Problem 2

A stylesheet link appears inside body.

Correction: Place the stylesheet relationship in head.

Problem 3

A list contains text that is not inside an li.

Correction: Put each list item inside li, and keep each li inside ol or ul.

Problem 4

A comment contains a production password.

Correction: Remove the password immediately. Client-side comments are delivered to users and cannot protect secrets.

Common misconceptions

  • “If the page displays, the HTML is correct.” Browsers repair many errors. Validate the source.
  • “A heading level controls font size.” Heading levels communicate hierarchy. CSS controls appearance.
  • “Bold and strong mean exactly the same thing.” They may look alike, but strong communicates importance.
  • “A line break creates a paragraph.” br stays within the same block. p represents a paragraph.
  • “Comments are private.” Anyone who receives the page can inspect its source.
  • “Indentation changes the layout.” Source indentation mainly helps people read the markup.
  • “A numbered list always looks more professional.” Use numbering only when order or rank matters.
  • “The browser will close my tags for me.” Browser recovery does not make the source dependable.

Lesson summary

Students should be able to explain the role of every line in a basic HTML document. Good markup uses a predictable skeleton, represents content with meaningful elements, keeps nesting visible, documents intent safely, and survives validation and browser testing.

The next lesson adds CSS and graphics. Students should preserve the HTML structure and improve presentation without rewriting the content around visual effects.