What HTML, CSS, and JavaScript Each Do

Stop treating the trio as three slogans

A teammate reviews a small feature and says, “HTML is the content, CSS makes it pretty, and JavaScript is the logic.” That shortcut is memorable, but it fails as soon as the feature contains semantic structure, responsive layout, declarative interaction, browser APIs, or a server endpoint.

This lesson gives you a narrower and more useful question: what responsibility belongs in HTML, CSS, JavaScript, a combination of them, or outside this trio? You will record that decision in Web Technology Responsibility Map v1. The artifact is not a stack recommendation. It is evidence that you can separate responsibilities, justify mixed cases, preserve uncertainty, and avoid absorbing server/runtime concerns into a front-end slogan.

By the end, you should be able to classify a bounded page concern and explain both the placement and its limit.

Carry forward one boundary from WEBF-001

WEBF-001 is the hard prerequisite. Keep only its useful boundary: a browser-facing page sits inside a wider navigation/request/response system. This lesson begins after that orientation and asks what the three familiar web technologies are responsible for in the page-facing slice.

Do not turn this page into an implementation tutorial. Framework APIs, production accessibility implementation, performance tuning, and server architecture are downstream concerns. Also do not claim the whole WEB-000 mental model; WEBF-002 owns only HTML/CSS/JavaScript responsibility separation.

The responsibility model

Use four destinations rather than three slogans:

1. HTML — document structure and semantics. HTML is the markup layer for representing the document's content structure and meaning. It can also provide native/declarative behavior through standard elements; not every useful interaction starts with custom JavaScript. [S-MDN-WEB] [S-WHATWG-SCRIPT]
2. CSS — presentation and layout rules. CSS describes how a document is presented across media. That includes far more than color: layout, responsive conditions, transitions, animations, and other presentation rules belong here when CSS can express the requirement. [S-MDN-CSS]
3. JavaScript — page/browser-host programmed behavior in this map. In the page-facing responsibility map, the JavaScript destination means program behavior executed in the browser/page host, often through DOM/Web APIs. JavaScript as a language also runs in non-browser environments; those non-browser runtime responsibilities are outside the trio for this artifact, even when their implementation language is JavaScript. [S-MDN-JS]
4. Combination or outside the trio. Real features often cross layers. A form can have HTML semantics, CSS layout, browser-side JavaScript enhancement, and a server endpoint that is outside the page-facing trio regardless of the server implementation language. Correct classification is therefore not forced one-label-per-feature.

The durable skill is not naming a file extension. It is asking: What is the concern? Which layer owns the base responsibility? Which other layers participate? What remains outside this model?

Classify the concern, not the visible effect

For each concern, fill one row of the HTML/CSS/JavaScript Responsibility Matrix, which is the row-level table inside Web Technology Responsibility Map v1. It is not a second artifact.

Use these columns:

• Observed concern: the requirement or behavior actually given by the scenario.
• Primary responsibility: HTML, CSS, JavaScript, combination, or outside the trio.
• Rationale: why that placement follows from the concern rather than from a favorite stack.
• Boundary / uncertainty: what the placement does not prove.
• Next evidence: what you would inspect or ask before making a stronger architecture claim.

A useful test is to remove the technology name from the sentence. “Make it responsive” points first to presentation/layout, while “send the submitted data to a server process” points beyond the trio even if JavaScript participates in the browser-side interaction.

Why the boundaries are useful but not absolute

HTML is not “just text on the screen”

HTML represents a document using elements with structure and meaning. A heading, navigation region, label, button, list, or disclosure can carry semantics that are independent of visual styling. If you rebuild semantic structure only as generic containers plus script, you have collapsed document responsibility into behavior code.

CSS is not “just decoration”

CSS controls presentation. Presentation includes typography and color, but also layout, media-dependent rules, state styling, transitions, and animation. A responsive two-column/one-column arrangement can be a CSS responsibility even though it changes what the user sees as the viewport changes. [S-MDN-CSS]

JavaScript is not “the browser”

JavaScript is a programming language. In the browser it works with host-provided APIs, including DOM and other Web APIs; in non-browser environments, the available host APIs differ. That language fact does not change this artifact's location boundary: a server-side JavaScript authorization check is still OUTSIDE_TRIO here because the responsibility executes outside the page/browser-facing slice. Saying “JavaScript does the DOM” or “JavaScript language = JavaScript bucket everywhere” hides the difference between language identity, host environment, and responsibility location. [S-MDN-JS]

Interactivity does not automatically imply custom JavaScript

HTML includes standard interactive mechanisms, and the HTML Standard explicitly encourages declarative alternatives to scripting where they fit. That does not mean “avoid JavaScript”; it means classify the responsibility before adding code. [S-WHATWG-SCRIPT]

Mixed responsibility is normal

A single feature can legitimately span layers. The requirement “show a responsive profile card whose button updates data from an API” can involve semantic HTML, CSS layout, JavaScript behavior, and a remote service outside the trio. The map should show the split instead of forcing one owner.

Worked contrast cases

Case 1 — a product card heading

Requirement: the card has a product name that is a heading in the page structure. Primary responsibility: HTML semantics/structure. CSS may style it, but styling does not create the document relationship.

Case 2 — a grid changes with available width

Requirement: cards move from multiple columns to one column when space is limited. Primary responsibility: CSS presentation/layout. JavaScript might observe layout for another purpose, but the mere existence of a responsive presentation rule does not move the base responsibility into JavaScript. [S-MDN-CSS]

Case 3 — a local button updates a count in the document

Requirement: user input triggers program behavior that reads or changes document state. Primary responsibility: JavaScript behavior in the browser, using host APIs where needed. The DOM API is part of the host environment, not the JavaScript language itself. [S-MDN-JS]

Case 4 — data must be saved by a server

Requirement: a browser action eventually causes durable server-side processing. The browser-facing event may involve HTML and JavaScript, but server processing is outside this trio's responsibility model, including server processing implemented in JavaScript. Do not label the whole end-to-end feature “JavaScript” merely because JavaScript initiated a Request or because the server uses the same language.

These are classification examples, not a worked answer for the final form transfer task.

Two misconceptions that block the model

Failure 1 — “HTML is content, CSS is beauty, JavaScript is logic”

The problem is not that the sentence has zero teaching value; it is that the nouns are too broad. HTML carries structure/semantics, CSS expresses presentation rules including layout and responsive behavior, and JavaScript is a programming language that can participate in browser behavior through host APIs. A better explanation names the responsibility rather than a slogan.

Failure 2 — “If it is interactive, it must be JavaScript”

Some interactions have standard declarative HTML mechanisms. The scripting section of the HTML Standard even notes that declarative alternatives can be preferable when they fit. The repair is not “never use JavaScript”; it is “use custom JavaScript when the required behavior actually needs programming beyond the suitable declarative mechanism.” [S-WHATWG-SCRIPT]

If your answer cannot state what is outside the trio, the boundary is still collapsed.

Architecture-review language for experienced learners

Translate the beginner labels into responsibility + host + evidence:

• document semantics/structure → HTML responsibility;
• presentation/layout rule → CSS responsibility;
• page/browser-host program behavior → JavaScript responsibility in this map;
• DOM, Fetch, timers, storage, and similar capabilities → host/Web APIs available to JavaScript, not the core language itself;
• persistence, authentication authority, database work, or server business logic → outside this page-facing trio by responsibility location, including when that server/runtime code is itself written in JavaScript.

The review question becomes: What is the smallest responsibility boundary that satisfies the requirement without pretending one technology owns the entire feature?

Legitimate placements and trade-offs

Some concerns have more than one reasonable implementation, but that does not erase the base responsibility model.

A disclosure can use a native HTML mechanism when its behavior fits the requirement; that can reduce custom scripting and preserve a declarative base. A custom component can use JavaScript when the interaction contract genuinely exceeds the native mechanism. The decision depends on requirements, not on a rule that one technique is universally superior. [S-WHATWG-SCRIPT]

A responsive layout can be expressed through CSS. JavaScript may still participate when the application must react programmatically to state, but using JavaScript to reproduce a presentation rule is a design choice that should be justified rather than assumed.

A server-rendered page can still use HTML/CSS/JavaScript in the browser-facing result. “Where the HTML was generated” and “what responsibility the HTML carries in the document” are different questions.

Practice with fading support

Practice A — classify

Classify these concerns: page heading semantics, a responsive two-column layout, a button that updates local document state, a database write, and an element whose color changes on hover. Use one primary responsibility and note any participating layer.

Practice B — repair an overclaim

Rewrite this sentence: “CSS only decorates; real responsive behavior belongs in JavaScript.” Your repair must name the CSS responsibility and state a case where JavaScript could still legitimately participate.

Practice C — independent decision

A help panel must remain understandable before custom JavaScript runs, match the page's responsive layout, and gain optional keyboard-driven enhancement after script becomes available. Build the decision rows yourself; do not copy the worked examples. State what you would keep declarative and what, if anything, needs programmed enhancement.

Scaffolding fades in this order: filled example row → responsibility labels → source hints. The final transfer is independent.

Evidence: Web Technology Responsibility Map v1

Your final artifact contains the HTML/CSS/JavaScript Responsibility Matrix as its internal row table. It must include:

After the rows, add at least two explicit non-claims. At minimum, your record must not imply that HTML is only visual markup, CSS is merely decoration, JavaScript runs only in browsers, or this lesson completes all of WEB-000.

There is no executable coding Lab in this lesson. The construct under test is classification and bounded architecture reasoning; forcing a coding Lab here would pre-consume later implementation lessons.

Assessment and transfer

The five evidence types are:

1. Retrieval: name the core HTML, CSS, JavaScript, and outside-the-trio boundaries.
2. Application: classify a bounded feature concern and justify the primary owner plus any combination.
3. Diagnosis: find a category collapse in a plausible explanation and repair it.
4. Decision: choose a responsibility placement under constraints and state what would change the decision.
5. Transfer: classify a form containing semantic labels, responsive styling, client validation, and a server submission endpoint, including what lies outside the trio.

Diagnosis, decision, and transfer are blocking. A stack name by itself is not sufficient evidence. The answer must expose reasoning, limits, and handoff boundaries in Web Technology Responsibility Map v1.

Declared sources and freshness boundary

This lesson uses only the four sources declared in its frozen Bible:

• S-MDN-WEB — MDN, How the web works: high-level web file categories and browser interpretation context.
• S-MDN-CSS — MDN, CSS: CSS as the presentation language for documents, including layout and related presentation mechanisms.
• S-MDN-JS — MDN, JavaScript technologies overview: distinction among the JavaScript language, DOM/Web APIs, and non-browser host environments.
• S-WHATWG-SCRIPT — WHATWG HTML Standard, Scripting: scripting mechanisms and the caution that declarative alternatives can be appropriate.

The four official/spec sources were rechecked on 2026-09-10; their declared claim boundaries remain usable and the source set is unchanged. Review is due by 2026-12-31, or earlier if a source changes a claim used here.

Final boundary: this lesson does not recommend a universal stack, does not claim JavaScript is browser-only, and does not absorb server-side responsibilities into the page-facing HTML/CSS/JavaScript trio merely because the server/runtime implementation also uses JavaScript.