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.
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.
<!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>
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.
<!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>
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.