## Introduction

Why does typing a URL in your browser show a webpage? The web works because of a few core technologies that coordinate to deliver content from servers to your screen.

The web is a system of interconnected documents and resources accessed over the internet using standardized protocols. Understanding how these pieces fit together helps you build better applications, debug issues faster, and make informed decisions about web technologies.

Understanding web fundamentals matters because every web application relies on these core concepts. Knowing why the web works the way it does helps you write code that performs well, debug network issues efficiently, and avoid common pitfalls that cause security vulnerabilities or poor user experiences.

**What this is (and isn't):** This article explains the web's core principles and design decisions, focusing on *why* the web works and how fundamental technologies fit together. It doesn't teach you to build your first website or cover advanced topics like WebAssembly or progressive web apps.

**Why web fundamentals matter:**

* **Faster debugging** - Understanding HTTP and browser behavior helps diagnose network and rendering issues quickly.
* **Better performance** - Knowing how browsers render pages guides optimization decisions.
* **Security awareness** - Understanding protocols and origins helps prevent common vulnerabilities.
* **Informed technology choices** - Knowing when to use web technologies versus native applications.

This article outlines core concepts every web developer encounters:

1. **HTTP and URLs** – how browsers request and receive content
2. **HTML structure** – how documents are organized
3. **CSS styling** – how visual presentation works
4. **JavaScript execution** – how interactivity is added
5. **Browser rendering** – how pages appear on screen
6. **Web standards** – how compatibility is maintained
7. **Security fundamentals** – how the web stays safe
8. **Common patterns** – web development best practices

> Type: **Explanation** (understanding-oriented).  
> Primary audience: **beginner to intermediate** developers learning web development or transitioning from other platforms

### Prerequisites & Audience

**Prerequisites:** Basic computer knowledge, including understanding files, folders, and using a web browser. No programming experience required, though familiarity with any programming language helps.

**Primary audience:** Developers new to web development or those with experience in other platforms who need to understand how the web works fundamentally.

**Jump to:** [HTTP & URLs](#section-1-http-and-urls--how-browsers-request-content) • [HTML](#section-2-html-structure--organizing-content) • [CSS](#section-3-css-styling--visual-presentation) • [JavaScript](#section-4-javascript-execution--adding-interactivity) • [Rendering](#section-5-browser-rendering--from-code-to-screen) • [Standards](#section-6-web-standards--ensuring-compatibility) • [Security](#section-7-security-fundamentals--staying-safe) • [Mistakes](#section-8-common-web-mistakes--what-to-avoid) • [Glossary](#glossary)

If you're brand new to web development, read Section 1 first to understand HTTP, then jump to Section 2 for HTML. If you're coming from native app development, start with Section 5 to see how browser rendering differs from native rendering.

**Escape routes:** If you need practical examples, read Section 8 on common mistakes, then return to earlier sections for context.

### TL;DR – Web Fundamentals in One Pass

If you only remember one thing, make it this:

* **HTTP is stateless**, so each request is independent, and servers don't remember previous requests
* **HTML structures content**, CSS styles it, and JavaScript adds behavior
* **Browsers render incrementally**, building the page as resources arrive
* **The same-origin policy** prevents scripts from accessing other sites' data

**The Web Request Workflow:**

```mermaid
graph TD
    A[Type URL] --> B[Resolve domain]
    B --> C[Send HTTP request]
    C --> D[Receive HTML]
    D --> E[Parse HTML]
    E --> F[Load assets]
    F --> G[Render page]
    G --> H[Run JavaScript]
```

### Learning Outcomes

By the end of this article, you will be able to:

* Explain **why** HTTP is stateless and how that affects web application design.
* Explain **why** HTML, CSS, and JavaScript are separate languages and how they work together.
* Explain **why** browsers render incrementally and how that affects page load performance.
* Learn how the same-origin policy works and when to use CORS (Cross-Origin Resource Sharing).
* Describe how URLs are structured and why each component matters.
* Explain how browser caching works and when it helps or hurts performance.

## Section 1: HTTP and URLs – How Browsers Request Content

HTTP (Hypertext Transfer Protocol) is the foundation of web communication. When you type a URL in your browser, HTTP defines how your browser requests content from a server and how the server responds.

### What is HTTP?

HTTP is a request-response protocol. Your browser sends a request, and the server responds. Each request is independent, meaning the server doesn't remember previous requests unless you use cookies or sessions.

Think of HTTP like ordering at a restaurant where the waiter doesn't remember you. Each order is separate, and if you want the server to remember your preferences, you write them on a card (a cookie) that you bring each time.

**Why this matters:** HTTP's statelessness makes servers scalable and straightforward, but it means web applications need mechanisms like cookies or tokens to maintain user sessions. For server-side implementation details, see [Fundamentals of Backend Engineering](/blog/2025/10/14/fundamentals-of-backend-engineering).

### URL Structure

A URL (Uniform Resource Locator) tells the browser where to find a resource. Every URL has these components:

```text
https://example.com:443/path/to/page?query=value#fragment
│      │            │   │            │            │
│      │            │   │            │            └─ Fragment (scrolls to section)
│      │            │   │            └─ Query string (parameters)
│      │            │   └─ Path (resource location)
│      │            └─ Port (usually omitted, defaults to 80 or 443)
│      └─ Domain (server address)
└─ Protocol (http or https)
```

**Protocol** (`https://`) tells the browser which protocol to use. HTTPS adds encryption.

**Domain** (`example.com`) is the server's address. The browser uses DNS (Domain Name System) to convert the domain name to an IP address. For deeper networking concepts, see [Fundamentals of Networking](/blog/2025/12/13/fundamentals-of-networking).

**Port** (`:443`) specifies which service on the server. Port 80 is HTTP, 443 is HTTPS. Browsers hide default ports.

**Path** (`/path/to/page`) identifies the specific resource on the server.

**Query string** (`?query=value`) passes parameters to the server.

**Fragment** (`#fragment`) tells the browser to scroll to a specific section after loading.

**Why this matters:** Understanding URL structure helps you debug routing issues, understand how search parameters work, and build clean URLs for your applications.

### HTTP Methods

HTTP defines methods that indicate what action the client wants to perform:

* **GET** - Retrieve a resource. Safe and idempotent (repeated invocations have no side effects).
* **POST** - Submit data to create or update a resource. Not idempotent.
* **PUT** - Replace a resource entirely. Idempotent.
* **PATCH** - Partially update a resource. Not always idempotent.
* **DELETE** - Remove a resource. Idempotent.

Most web browsing uses GET requests. Forms and API calls use POST, PUT, PATCH, or DELETE.

**Why this matters:** Using the correct HTTP method helps with caching, browser behavior, and API design. GET requests can be cached and bookmarked safely, while POST requests trigger browser warnings if you try to refresh. For comprehensive API design guidance, see [Fundamentals of API Design and Contracts](/blog/2026/01/16/fundamentals-of-api-design-and-contracts/).

### HTTP Status Codes

Servers respond with status codes that indicate what happened:

* **2xx Success** - Request succeeded (200 OK, 201 Created, 204 No Content)
* **3xx Redirection** - Resource moved (301 Moved Permanently, 302 Found, 304 Not Modified)
* **4xx Client Error** - Request was invalid (400 Bad Request, 401 Unauthorized, 404 Not Found)
* **5xx Server Error** - Server failed (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable)

**Why this matters:** Status codes help debug issues. A 404 means the resource doesn't exist, while a 500 means the server has a problem. Browsers and tools use status codes to determine caching behavior and error handling.

### HTTPS and Security

HTTPS adds encryption to HTTP using TLS (Transport Layer Security). The browser and server establish an encrypted connection before sending any data.

**Why this matters:** HTTPS prevents attackers from reading or modifying data in transit. Modern browsers mark HTTP sites as insecure, and many web features only work over HTTPS.

### Quick Check: HTTP and URLs

Before moving on, test your understanding:

* What happens when you type a URL in your browser?
* Why is HTTP stateless, and how do web applications maintain state?
* What's the difference between HTTP and HTTPS?

**Answer guidance:** **Ideal result:** You can explain that typing a URL triggers a DNS lookup, then an HTTP request to the server, which responds with content. HTTP is stateless for scalability, so applications use cookies or tokens to maintain state. HTTPS adds encryption using TLS.

If any answer feels unclear, reread the relevant section and try explaining it out loud.

## Section 2: HTML Structure – Organizing Content

HTML (Hypertext Markup Language) structures web content. It defines what content exists and how it's organized, not how it looks.

### What is HTML?

HTML uses tags to mark up content. Tags create elements that browsers interpret to build a document structure.

```html
<!DOCTYPE html>
<html lang="en">
<head>
    <title>Page Title</title>
    <meta charset="UTF-8">
</head>
<body>
    <h1>Main Heading</h1>
    <p>This is a paragraph.</p>
    <a href="/page">Link text</a>
</body>
</html>
```

**Why this matters:** HTML separates structure from presentation. The same HTML can look completely different with different CSS, and screen readers use HTML structure to navigate pages.

### Semantic HTML

Semantic HTML uses tags that describe meaning rather than just appearance. Use `<article>` for articles, `<nav>` for navigation, `<header>` for headers, not just `<div>` everywhere.

```html
<article>
    <header>
        <h1>Article Title</h1>
        <p>Published on <time datetime="2026-01-05">January 5, 2026</time></p>
    </header>
    <p>Article content goes here.</p>
</article>
```

**Why this matters:** Semantic HTML improves accessibility, SEO, and maintainability. Screen readers understand the page structure, search engines understand content hierarchy, and developers can style elements based on meaning. For comprehensive accessibility guidance, see [Fundamentals of Software Accessibility](/blog/2025/11/30/fundamentals-of-software-accessibility).

### HTML Elements

Common HTML elements include:

* **Headings** (`<h1>` through `<h6>`) - Create a document outline
* **Paragraphs** (`<p>`) - Block-level text content
* **Links** (`<a>`) - Navigate to other pages or resources
* **Images** (`<img>`) - Embed images (always include `alt` text)
* **Lists** (`<ul>`, `<ol>`, `<li>`) - Create bulleted or numbered lists
* **Forms** (`<form>`, `<input>`, `<button>`) - Collect user input
* **Sections** (`<section>`, `<article>`, `<nav>`, `<header>`, `<footer>`) - Organize content

**Why this matters:** Using the right element for the job improves accessibility and makes CSS styling easier. A button should be `<button>`, not a styled `<div>`, because buttons have built-in keyboard and screen reader support. For broader frontend engineering concepts, see [Fundamentals of Frontend Engineering](/blog/2025/11/26/fundamentals-of-frontend-engineering).

### Document Object Model (DOM)

When a browser parses HTML, it builds a DOM (Document Object Model), a tree structure representing the page. JavaScript can read and modify the DOM to change what users see.

```html
<div id="container">
    <p>Hello</p>
</div>
```

This creates a DOM tree:

```text
html
└── body
    └── div#container
        └── p
            └── "Hello"
```

**Why this matters:** Understanding the DOM helps you debug JavaScript issues and understand how frameworks like React work. The DOM is what JavaScript manipulates, not the HTML source.

### Quick Check: HTML Structure

Before moving on, test your understanding:

* What's the difference between HTML structure and visual appearance?
* Why use semantic HTML instead of generic `<div>` elements?
* What is the DOM, and how does it relate to HTML?

**Answer guidance:** **Ideal result:** You can explain that HTML defines structure, CSS defines appearance. Semantic HTML improves accessibility and SEO. The DOM is the browser's tree representation of HTML that JavaScript can manipulate.

If any answer feels unclear, reread the relevant section and try explaining it out loud.

## Section 3: CSS Styling – Visual Presentation

CSS (Cascading Style Sheets) controls how HTML elements look. It separates presentation from structure, allowing the same HTML to have different visual designs.

### What is CSS?

CSS uses selectors to target HTML elements and properties to style them:

```css
h1 {
    color: blue;
    font-size: 2em;
    margin-bottom: 1rem;
}
```

This targets all `<h1>` elements, makes them blue and larger, and adds spacing below.

**Why this matters:** Separating CSS from HTML means you can change a site's entire design by swapping stylesheets. It also makes HTML cleaner and easier to maintain.

### The Cascade

CSS stands for "Cascading Style Sheets." The cascade determines which styles apply when multiple rules target the same element:

1. **Specificity** - More specific selectors win over less specific ones
2. **Source order** - Later rules override earlier ones when specificity is equal
3. **Importance** - `!important` declarations override standard rules

```css
p { color: black; }           /* Less specific */
.content p { color: blue; }   /* More specific, wins */
p { color: red !important; }  /* Important, wins over everything */
```

**Why this matters:** Understanding the cascade helps you debug why styles aren't applying and write CSS that's maintainable. Specificity conflicts are a common source of CSS bugs. For color and contrast considerations in design, see [Fundamentals of Color and Contrast](/blog/2025/12/05/fundamentals-of-color-and-contrast).

### Box Model

Every HTML element is a box with content, padding, border, and margin:

```text
┌─────────────────────────┐
│      margin             │
│  ┌───────────────────┐  │
│  │     border        │  │
│  │  ┌─────────────┐  │  │
│  │  │   padding   │  │  │
│  │  │  ┌───────┐  │  │  │
│  │  │  │content│  │  │  │
│  │  │  └───────┘  │  │  │
│  │  └─────────────┘  │  │
│  └───────────────────┘  │
└─────────────────────────┘
```

**Why this matters:** Understanding the box model helps you predict element sizes and spacing. Many layout issues stem from a misunderstanding of how padding, borders, and margins interact.

### Layout Methods

CSS provides several layout methods:

* **Normal flow** - Default block and inline behavior
* **Flexbox** - One-dimensional layouts (rows or columns)
* **Grid** - Two-dimensional layouts (rows and columns)
* **Positioning** - Absolute, relative, fixed positioning

```css
.container {
    display: flex;
    justify-content: space-between;
    align-items: center;
}
```

**Why this matters:** Each layout method solves different problems. Flexbox is great for navigation bars and card layouts. Grid excels at page layouts. Understanding when to use each prevents layout struggles.

### Responsive Design

Responsive design makes pages work on different screen sizes using media queries:

```css
.container {
    width: 100%;
}

@media (min-width: 768px) {
    .container {
        width: 750px;
        margin: 0 auto;
    }
}
```

**Why this matters:** Most web traffic comes from mobile devices. Responsive design ensures your site works on phones, tablets, and desktops without separate codebases. For comprehensive frontend engineering practices, see [Fundamentals of Frontend Engineering](/blog/2025/11/26/fundamentals-of-frontend-engineering).

### Quick Check: CSS Styling

Before moving on, test your understanding:

* How does CSS separate presentation from structure?
* What determines which CSS rule wins when multiple rules target the same element?
* What are the components of the CSS box model?

**Answer guidance:** **Ideal result:** You can explain that CSS is separate from HTML, allowing design changes without HTML changes. Specificity, source order, and importance determine which rules win. The box model includes content, padding, border, and margin.

If any answer feels unclear, reread the relevant section and try explaining it out loud.

## Section 4: JavaScript Execution – Adding Interactivity

JavaScript adds behavior to web pages. It can read and modify the DOM, respond to user events, and communicate with servers.

### What is JavaScript?

JavaScript is a programming language that runs in browsers. It's the only language that runs natively in browsers, though WebAssembly now allows other languages to compile for the web.

```javascript
const button = document.querySelector('button');
button.addEventListener('click', () => {
    alert('Button clicked!');
});
```

This code finds a button and shows an alert when clicked.

**Why this matters:** JavaScript is essential for interactive web applications. Understanding how it works helps you build features and debug issues.

### How JavaScript Runs

Browsers include JavaScript engines (like V8 in Chrome) that parse and execute JavaScript code. When a browser encounters a `<script>` tag, it downloads and executes the JavaScript.

```html
<script src="app.js"></script>
```

The browser pauses HTML parsing to execute JavaScript by default, though you can use `async` or `defer` attributes to change this behavior.

**Why this matters:** JavaScript execution blocks HTML parsing, which can slow page loads. Understanding execution order helps you optimize performance and avoid timing bugs.

### The Event Loop

JavaScript uses an event loop to handle asynchronous operations. The event loop processes a queue of tasks, running each in turn.

```javascript
console.log('1');
setTimeout(() => console.log('2'), 0);
console.log('3');
// Output: 1, 3, 2
```

Even though the timeout is 0 milliseconds, it runs after the current code finishes because it's added to the event queue.

**Why this matters:** Understanding the event loop helps you write correct asynchronous code and debug timing issues. Many JavaScript bugs stem from misunderstandings about how code executes.

### DOM Manipulation

JavaScript can read and modify the DOM to change what users see:

```javascript
const element = document.getElementById('message');
element.textContent = 'Hello, World!';
element.style.color = 'blue';
```

**Why this matters:** DOM manipulation is how JavaScript makes pages interactive. Understanding it helps you use frameworks effectively, since frameworks ultimately manipulate the DOM.

### Fetch API

The Fetch API lets JavaScript request data from servers:

```javascript
fetch('/api/data')
    .then(response => response.json())
    .then(data => console.log(data))
    .catch(error => console.error(error));
```

**Why this matters:** Fetch enables dynamic content loading without page refreshes. Understanding it helps you build single-page applications and integrate with APIs. For API design best practices, see [Fundamentals of API Design and Contracts](/blog/2026/01/16/fundamentals-of-api-design-and-contracts/).

### Quick Check: JavaScript Execution

Before moving on, test your understanding:

* How does JavaScript add interactivity to web pages?
* What is the event loop, and why does it matter?
* How does JavaScript communicate with servers?

**Answer guidance:** **Ideal result:** You can explain that JavaScript runs in the browser, manipulates the DOM for interactivity, uses an event loop for asynchronous operations, and uses the Fetch API to request server data.

If any answer feels unclear, reread the relevant section and try explaining it out loud.

## Section 5: Browser Rendering – From Code to Screen

Browsers convert HTML, CSS, and JavaScript into pixels on your screen through a multi-step rendering process.

### The Rendering Pipeline

When a browser receives HTML, it goes through these steps:

1. **Parse HTML** - Build the DOM tree
2. **Parse CSS** - Build the CSSOM (CSS Object Model)
3. **Combine** - Merge DOM and CSSOM into a render tree
4. **Layout** - Calculate element positions and sizes
5. **Paint** - Fill in pixels for each element
6. **Composite** - Layer elements for display

**Why this matters:** Understanding the rendering pipeline helps you optimize performance. Each step takes time, and blocking any step delays when users see content. For comprehensive performance optimization strategies, see [Fundamentals of Software Performance](/blog/2025/12/16/fundamentals-of-software-performance).

### Critical Rendering Path

The critical rendering path is the sequence of steps needed to render the initial view. Optimizing it makes pages feel faster.

**Why this matters:** Users notice when pages load slowly. Optimizing the critical rendering path reduces perceived load time, even if total load time is the same.

### Reflow and Repaint

When JavaScript changes the DOM or CSS, the browser may need to recalculate layout (reflow) or redraw pixels (repaint). Both are expensive operations.

```javascript
// Causes reflow (layout recalculation)
element.style.width = '200px';

// Causes repaint (redraw)
element.style.color = 'red';
```

**Why this matters:** Frequent reflows and repaints cause janky animations and slow interactions. Understanding when they occur helps you write performant JavaScript. For performance optimization techniques, see [Fundamentals of Software Performance](/blog/2025/12/16/fundamentals-of-software-performance).

### Incremental Rendering

Browsers render incrementally, showing content as it arrives rather than waiting for everything to load. This is why you sometimes see unstyled content flash before CSS loads.

**Why this matters:** Incremental rendering means users see content faster, but it requires careful CSS and JavaScript organization to avoid layout shifts and visual glitches.

### Quick Check: Browser Rendering

Before moving on, test your understanding:

* What steps does a browser take to render a webpage?
* What's the difference between reflow and repaint?
* Why do browsers render incrementally?

**Answer guidance:** **Ideal result:** You can explain that browsers parse HTML/CSS, build render trees, calculate layout, paint pixels, and composite layers. Reflow recalculates layout, repaint redraws pixels. Incremental rendering shows content faster as it arrives.

If any answer feels unclear, reread the relevant section and try explaining it out loud.

## Section 6: Web Standards – Ensuring Compatibility

Web standards are specifications that define how web technologies should work. They ensure browsers implement features consistently.

### What are Web Standards?

Web standards are created by organizations such as the W3C (World Wide Web Consortium) and the WHATWG (Web Hypertext Application Technology Working Group). They define HTML, CSS, JavaScript APIs, and other web technologies.

**Why this matters:** Standards ensure websites work across different browsers and devices. Without standards, each browser would implement features differently, making web development much harder.

### Browser Compatibility

Different browsers implement standards at various speeds. Some features work in one browser but not another, or work differently in each.

**Why this matters:** Understanding browser compatibility helps you decide which features to use and when to provide fallbacks. Tools like Can I Use help you check feature support.

### Progressive Enhancement

Progressive enhancement means building a basic version that works everywhere, then adding enhancements for browsers that support them.

```html
<video controls>
    <source src="video.mp4" type="video/mp4">
    <p>Your browser doesn't support video. <a href="video.mp4">Download it</a>.</p>
</video>
```

**Why this matters:** Progressive enhancement ensures your site works for all users, regardless of browser capabilities. It's more inclusive than requiring specific browser features.

### Quick Check: Web Standards

Before moving on, test your understanding:

* Why do web standards exist?
* What is progressive enhancement, and why use it?
* How do you handle browser compatibility differences?

**Answer guidance:** **Ideal result:** You can explain that standards ensure consistent browser behavior, progressive enhancement provides fallbacks for older browsers, and you check compatibility and provide alternatives when needed.

If any answer feels unclear, reread the relevant section and try explaining it out loud.

## Section 7: Security Fundamentals – Staying Safe

Web security protects users and applications from attacks. Understanding basic security concepts helps you build safer applications.

### Same-Origin Policy

The same-origin policy prevents JavaScript from one site from accessing data on another site. Two pages have the same origin if they share protocol, domain, and port.

```text
https://example.com/page1  ← Same origin
https://example.com/page2  ← Same origin

https://example.com/page1  ← Different origin
http://example.com/page2   ← Different protocol

https://example.com/page1  ← Different origin
https://other.com/page2    ← Different domain
```

**Why this matters:** The same-origin policy prevents malicious sites from stealing your data from other sites. It's a fundamental security boundary.

### CORS

CORS (Cross-Origin Resource Sharing) allows servers to specify which origins can access their resources. It relaxes the same-origin policy in controlled ways.

```http
Access-Control-Allow-Origin: https://example.com
```

**Why this matters:** CORS enables legitimate cross-origin requests (like APIs serving multiple sites) while maintaining security. Misconfigured CORS can create security vulnerabilities.

### HTTPS

HTTPS encrypts data in transit, preventing attackers from reading or modifying it. Modern browsers require HTTPS for many features.

**Why this matters:** HTTPS protects user data and prevents man-in-the-middle attacks. It's essential for any site handling sensitive information. For comprehensive security guidance, see [Fundamentals of Software Security](/blog/2025/12/02/fundamentals-of-software-security).

### Content Security Policy

CSP (Content Security Policy) tells browsers which sources are allowed for scripts, styles, images, and other resources. It helps prevent cross-site scripting (XSS)) attacks.

```http
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'
```

**Why this matters:** CSP reduces the impact of XSS attacks by limiting where scripts can load from. It's a defense-in-depth security measure. For broader security practices, see [Fundamentals of Software Security](/blog/2025/12/02/fundamentals-of-software-security).

### Quick Check: Security Fundamentals

Before moving on, test your understanding:

* What is the same-origin policy, and why does it exist?
* How does CORS relate to the same-origin policy?
* Why is HTTPS important for web security?

**Answer guidance:** **Ideal result:** You can explain that the same-origin policy prevents cross-site data access, CORS allows controlled cross-origin access, and HTTPS encrypts data in transit.

If any answer feels unclear, reread the relevant section and try explaining it out loud.

## Section 8: Common Web Mistakes – What to Avoid

Common mistakes create security vulnerabilities, performance problems, and accessibility issues. Understanding these mistakes helps you avoid them.

### Mistake 1: Blocking the Critical Rendering Path

Loading JavaScript that blocks HTML parsing delays when users see content. For performance optimization strategies, see [Fundamentals of Software Performance](/blog/2025/12/16/fundamentals-of-software-performance).

**Incorrect:**

```html
<script src="heavy-library.js"></script>
```

**Correct:**

```html
<script src="heavy-library.js" defer></script>
<!-- or -->
<script src="heavy-library.js" async></script>
```

Use `defer` for scripts that need to run in order, `async` for independent scripts.

### Mistake 2: Missing Alt Text on Images

Images without alt text hurt accessibility and SEO. For comprehensive accessibility guidance, see [Fundamentals of Software Accessibility](/blog/2025/11/30/fundamentals-of-software-accessibility).

**Incorrect:**

```html
<img src="photo.jpg">
```

**Correct:**

```html
<img src="photo.jpg" alt="A person reading a book in a library">
```

Always provide descriptive alt text unless the image is purely decorative (use `alt=""` then).

### Mistake 3: Inline Styles Over CSS

Inline styles make maintenance harder and prevent CSS caching.

**Incorrect:**

```html
<div style="color: blue; font-size: 16px;">Text</div>
```

**Correct:**

```html
<div class="highlight">Text</div>
```

```css
.highlight {
    color: blue;
    font-size: 16px;
}
```

### Mistake 4: Not Using Semantic HTML

Generic `<div>` elements everywhere hurt accessibility and SEO. For detailed guidance on semantic HTML and accessibility, see [Fundamentals of Software Accessibility](/blog/2025/11/30/fundamentals-of-software-accessibility).

**Incorrect:**

```html
<div class="header">
    <div class="nav">
        <div class="link">Home</div>
    </div>
</div>
```

**Correct:**

```html
<header>
    <nav>
        <a href="/">Home</a>
    </nav>
</header>
```

### Mistake 5: Ignoring Mobile Users

Not testing on mobile devices creates poor experiences for most users.

**Incorrect:**

```css
.container {
    width: 1200px; /* Fixed width breaks on mobile */
}
```

**Correct:**

```css
.container {
    width: 100%;
    max-width: 1200px;
}

@media (min-width: 768px) {
    .container {
        padding: 2rem;
    }
}
```

### Quick Check: Common Mistakes

Test your understanding:

* Why should you avoid blocking the critical rendering path?
* What happens when images lack alt text?
* Why use semantic HTML instead of generic divs?

**Answer guidance:** **Ideal result:** You can explain that blocking rendering delays content visibility, missing alt text hurts accessibility, and semantic HTML improves SEO and screen reader support.

If any answer feels unclear, reread the relevant section and try explaining it out loud.

## Section 9: Common Misconceptions

Common misconceptions about the web include:

* **"JavaScript and Java are related."** They're completely different languages with different purposes. JavaScript was named for marketing reasons when Java was popular.

* **"The web and the internet are the same thing."** The Internet is the network infrastructure. The web is one application that runs on the internet, along with email, file transfer, and other services.

* **"HTML is a programming language."** HTML is a markup language that structures content. It doesn't have variables, loops, or logic like programming languages.

* **"CSS can't do that."** Modern CSS is powerful. Many things that people think require JavaScript can be done with CSS alone, like animations, layouts, and even some interactions.

* **"All browsers work the same way."** Browsers have different engines, implement standards at various speeds, and have unique quirks. Always test in multiple browsers.

## Section 10: When NOT to Use Web Technologies

Web technologies aren't always the right choice. Understanding when to skip them helps you focus effort where it matters.

**Native performance requirements** - Applications that require maximum performance (such as games or video editing) may require native code rather than web technologies.

**Offline-first applications** - While service workers enable offline functionality, applications that must work completely offline without an internet connection may be better suited as native apps.

**System integration** - Web applications have limited access to system features. Applications that require deep OS integration may require native code.

**Specialized hardware** - Applications that require direct hardware access (such as) device drivers) can't run in browsers.

**Regulatory compliance** - Some industries have regulations that are easier to meet with native applications that have more control over data storage and transmission.

Even when you skip web technologies for the core application, they remain valuable for admin interfaces, documentation, and supporting tools.

## Building Web Applications

Understanding web fundamentals helps you build applications that perform well, are secure, and work across devices.

### Summary

* **HTTP is stateless** - Each request is independent, so applications need mechanisms like cookies for state.
* **HTML structures, CSS styles, JavaScript adds behavior** - Keeping these separate makes code maintainable.
* **Browsers render incrementally** - Optimize the critical rendering path for faster perceived performance.
* **Security boundaries matter** - Same-origin policy and HTTPS protect users and data.
* **Standards enable compatibility** - Following web standards ensures your site works across browsers.

### How These Concepts Connect

HTTP delivers HTML, CSS, and JavaScript to browsers. Browsers parse HTML into a DOM, apply CSS for styling, and execute JavaScript for interactivity. The rendering pipeline converts this into pixels on screen. Web standards ensure this works consistently across browsers, while security policies protect users.

### Getting Started with Web Development

If you're new to web development, start with a simple workflow:

1. **Write semantic HTML** for your content structure
2. **Add CSS** to style the content
3. **Add JavaScript** for interactivity
4. **Test in multiple browsers** to ensure compatibility
5. **Optimize performance** by checking the critical rendering path

Once this feels routine, expand to responsive design, accessibility, and security best practices.

### Next Steps

**Immediate actions:**

* Open browser developer tools and inspect a webpage's HTML, CSS, and network requests
* Read the HTML source of a simple website to see the structure
* Check a site's security by looking for HTTPS and examining security headers

**Learning path:**

* Learn HTML semantics and accessibility
* Master CSS layout methods (Flexbox and Grid)
* Understand JavaScript fundamentals (variables, functions, DOM manipulation)
* Study HTTP and how browsers request resources
* Explore browser developer tools for debugging

**Practice exercises:**

* Build a simple static website with HTML and CSS
* Add JavaScript interactivity to a page
* Inspect and modify a live webpage using developer tools
* Analyze a website's performance using browser dev tools
* Test a website's accessibility using browser extensions

**Questions for reflection:**

* How does typing a URL result in a webpage appearing?
* Why are HTML, CSS, and JavaScript separate languages?
* What happens in the browser between receiving HTML and displaying pixels?

### The Web Request Workflow: A Quick Reminder

Before concluding, here's the core workflow one more time:

```mermaid
graph TD
    A[User types URL] --> B[DNS lookup]
    B --> C[HTTP request]
    C --> D[Server responds]
    D --> E[Browser parses HTML]
    E --> F[Requests CSS/JS/images]
    F --> G[Renders page]
    G --> H[JavaScript executes]
```

Understanding each step helps you debug issues and optimize performance at every stage.

### Final Quick Check

Before you move on, see if you can answer these out loud:

1. What happens when you type a URL in your browser?
2. How do HTML, CSS, and JavaScript work together?
3. Why is HTTP stateless, and how do web applications maintain state?
4. What is the same-origin policy, and why does it exist?
5. How do browsers convert code into pixels on screen?

If any answer feels fuzzy, revisit the matching section and skim the examples again.

### Self-Assessment – Can You Explain These in Your Own Words?

Before moving on, see if you can explain these concepts in your own words:

* How HTTP requests and responses work
* Why HTML, CSS, and JavaScript are separate
* How browsers render webpages
* What the same-origin policy does

If you can explain these clearly, you've internalized the fundamentals.

## Future Trends & Evolving Standards

Web standards and practices continue to evolve. Understanding upcoming changes helps you prepare for the future.

### WebAssembly

WebAssembly (WASM) allows languages like Rust, C++, and Go to compile for the web, enabling near-native performance for computationally intensive tasks.

**What this means:** WebAssembly expands what's possible on the web, from games to video editing to scientific computing.

**How to prepare:** Learn when WebAssembly makes sense versus JavaScript. Most web applications don't need it, but it's valuable for performance-critical code.

### Progressive Web Apps

PWAs combine web and native app features, work offline, and install like native apps while remaining web-based.

**What this means:** PWAs blur the line between web and native applications, offering app-like experiences without app store distribution.

**How to prepare:** Understand service workers for offline functionality and web app manifests for installability.

### Enhanced Privacy

Browsers are implementing stricter privacy controls, limiting tracking and third-party cookies.

**What this means:** Web applications need to adapt to privacy-focused defaults, using first-party data and explicit user consent.

**How to prepare:** Understand privacy regulations and design applications that work with privacy-focused browsers.

## Limitations & When to Involve Specialists

Web fundamentals provide a strong foundation, but some situations require specialist expertise.

### When Fundamentals Aren't Enough

Some web development challenges go beyond the fundamentals covered in this article.

**Complex state management:** Applications with complex data flows may need specialized state management libraries or architectures.

**Advanced performance optimization:** Applications needing sub-100ms interactions may require performance specialists familiar with browser internals.

**Security-critical applications:** Applications that handle sensitive data require security experts to review their architecture and implementation.

### When Not to DIY Web Development

There are situations where fundamentals alone aren't enough:

* **Large-scale applications** requiring architecture decisions and team coordination
* **Security-critical systems** handling financial or medical data
* **Performance-critical applications** where every millisecond matters

### When to Involve Web Specialists

Consider involving specialists when:

* You need to optimize for specific browser engines
* You're building accessibility features for users with disabilities
* You're implementing complex animations or interactions
* You need to integrate with legacy systems or unusual protocols

**How to find specialists:** Look for developers with experience in your specific needs, whether that's performance, accessibility, security, or a particular framework.

### Working with Specialists

When working with specialists:

* Clearly communicate your goals and constraints
* Provide access to code, designs, and requirements
* Ask questions to understand their recommendations
* Review their work to learn for future projects

## Glossary

## References

### Industry Standards

* [HTML Living Standard](https://html.spec.whatwg.org/): The official HTML specification maintained by WHATWG.
* [CSS Specifications](https://www.w3.org/Style/CSS/specs.en.html): W3C CSS standards and specifications.
* [HTTP/1.1 Specification](https://httpwg.org/specs/rfc9112.html): The official HTTP/1.1 protocol specification.
* [ECMAScript Language Specification](https://tc39.es/ecma262/): The official JavaScript language specification.

### Tools & Resources

* [MDN Web Docs](https://developer.mozilla.org/): Comprehensive web technology documentation and tutorials.
* [Can I Use](https://caniuse.com/): Browser compatibility tables for web features.
* [Web.dev](https://web.dev/): Guides and best practices for modern web development.

### Community Resources

* [Web Standards](https://www.w3.org/standards/): Information about web standards and the standards process.
* [WHATWG](https://whatwg.org/): The organization that maintains HTML and related standards.

### Note on Verification

Web standards and best practices evolve rapidly. Verify current information using official specifications and test with actual browsers to ensure your web applications work correctly across different environments.