Course outline

HTML & CSS / Foundations / Lesson 1

Documents, browsers, and a reliable workflow

Understand how HTML content and CSS presentation become a usable document, then inspect the actual browser model rather than guessing from appearance.

About 4 min readContent reviewed
On this page

Lesson goals

  • Separate structure and presentation
  • Inspect a minimal meaningful page
  • Keep evidence reproducible

Separate structure and presentation

HTML describes document content and relationships; CSS controls presentation under the browser’s layout and painting rules. A heading communicates a section title even before its font is styled. JavaScript can add behavior, but it is not required for ordinary links or many form interactions. Treat these responsibilities as cooperating layers: a missing accessible name cannot be repaired by a brighter border. Begin with readable content and meaningful elements, then enhance spacing and layout. This order also makes failures easier to locate because the content remains inspectable when a stylesheet is absent or a network resource fails.

Use an explicit document shell

The doctype selects standards-mode behavior for modern HTML documents. The html element declares the document language, head holds metadata, and body holds presented content. A useful title distinguishes the page in tabs and history. Declare UTF-8 early so Arabic and other characters are decoded consistently. The viewport metadata lets mobile browsers use the device’s layout viewport appropriately; it does not make a fixed-width design responsive by itself. A local HTML file can demonstrate static content, while network-dependent features may require a local server. This course’s complete documents avoid external dependencies so they can be inspected without contacting a service.

Inspect a minimal meaningful page

The first example contains a main landmark, a page heading, and a paragraph. The source order is already a sensible reading order, and no styling is required to identify the topic. Save the whole document as an HTML file and inspect both source and the Elements or Inspector panel. The browser builds a DOM tree from source and may repair invalid nesting, so the live tree can differ from what was typed. Investigate that difference instead of assuming a visible page proves valid markup. Validation and browser inspection answer related but distinct questions about conformance and resulting behavior.

html Semantic document
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Semantic document</title>
</head>
<body>
<main>
<h1>Workshop notes</h1>
<p>Build structure before presentation.</p>
</main>
</body>
</html>
Expected output
A heading followed by an introductory paragraph.

The main landmark contains a single top-level heading followed by its introduction. Browser default styling remains sufficient to read the document.

Add a small visible style

The second example adds CSS in a style element, keeping the experiment self-contained. The selector matches the main element and declares a readable maximum line width plus automatic inline margins. Padding prevents content touching the viewport edge. Relative units follow the document’s sizing context rather than assuming one device’s pixel dimensions. The output description records relationships, not an identical screenshot across systems: fonts, default settings, and zoom can differ. Change one declaration at a time and use the computed-style panel to observe which property changed, whether the rule matched, and whether another declaration took precedence.

html Readable document
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Readable document</title>
<style>
main { max-inline-size: 60ch; margin-inline: auto; padding: 1rem; }
</style>
</head>
<body>
<main><h1>Readable notes</h1><p>A bounded reading area can still shrink on a narrow screen.</p></main>
</body>
</html>
Expected output
Content stays within a padded reading column.

The maximum limits long lines, while the block still uses available narrow space. Padding provides breathing room without fixing the viewport width.

Keep evidence reproducible

Record the document, browser version, viewport, zoom, and relevant user settings when reporting a rendering problem. The Console can show resource or parsing diagnostics, while Network explains whether a stylesheet actually arrived. A validator can identify structural problems but cannot determine whether alternative text conveys the right meaning or keyboard order fits the task. Test narrow and wide views early, and navigate with a keyboard before a complex component hides a basic issue. Keep examples local and synthetic; learning layout should not require submitting a real form or copying private content into an external checker.

Common errors and fixes

The page appears but has an unexpected tree

Why it happens
Invalid nesting triggered parser repair.
How to fix it
Inspect the DOM and correct the source structure.
Prevent it next time
Validate small documents before composing them.

Arabic text displays incorrectly

Why it happens
The document bytes and declared decoding disagree.
How to fix it
Save UTF-8 and declare its charset early.
Prevent it next time
Keep encoding explicit across editing and delivery.

A mobile page still requires horizontal scrolling

Why it happens
Viewport metadata accompanied fixed or oversized content.
How to fix it
Inspect content sizing and allow flexible layout.
Prevent it next time
Test actual narrow content rather than metadata alone.

Check your understanding

1. What should remain usable if the stylesheet fails to load?

Show worked solution

The heading, paragraph order, meaningful links, and native controls should still communicate the task. CSS may improve their arrangement, but content relationships must exist in HTML. Inspect the unstyled document to find dependencies that were accidentally carried only by color or position.

2. Design a minimal rendering report for a layout that breaks only after zooming.

Show worked solution

Include the complete reduced document, browser version, initial viewport, zoom level, expected relationship, and observed overflow. Retest with identical settings and inspect the first oversized box. A screenshot helps locate the issue but does not replace source or reproducible settings.

Key takeaways

  • HTML supplies meaning before CSS supplies presentation.
  • Inspect the resulting DOM and computed styles.
  • A working screenshot is insufficient evidence of usability.

Official references