Subjects and lessons to explore.

Law

Web Development · Foundations

The Web Platform

10 min read 5 practice questions
8 key termsSourcesReport an error
Want it in plain words first? Jump to Eli explains — the same idea, no jargon.
On this page 9 sections
  1. In 30 seconds
  2. Why this matters
  3. The college version
  4. Eli explains
  5. Worked example
  6. Key takeaway
  7. Quick check
  8. Study tools
  9. Sources & references

In 30 seconds

The is the shared set of web standards and browser-provided capabilities used to build sites and web applications. HTML, CSS, and JavaScript are familiar parts of that environment, but browsers also expose Web APIs such as the . Specifications describe expected behavior; browser teams implement that behavior. A web developer therefore needs to distinguish the JavaScript language from the browser capabilities that JavaScript can call.

Why this matters

Calling everything “JavaScript” hides an important boundary. A language feature and a browser API have different specifications, availability, and fallback choices. In a course, that distinction makes it easier to read documentation and reason about why code works in a browser but not necessarily in another JavaScript environment. In practice, it helps teams select a capability deliberately, test for it when appropriate, and provide a useful baseline when it is unavailable.

The college version

A platform, not one library

The web platform is the environment in which a browser turns web resources into an interactive experience. It is not a package that a developer imports, and it is not another name for JavaScript. It includes interoperating technologies and the interfaces browsers make available to pages. HTML describes document markup; CSS describes presentation rules; JavaScript is a programming language used in many places, including browsers. In a browser, JavaScript can also call Web APIs. MDN describes Web APIs as interfaces available while developing a web app or site. The Document Object Model (DOM), for example, lets a script inspect and change the document that the browser has built. A page may use no JavaScript at all and still use the web platform through HTML and CSS. Conversely, JavaScript can run outside a browser, where a browser-specific object such as document may not exist. That difference is a useful diagnostic clue: ask whether a name belongs to the language itself or to the host environment. The platform is broad, but that does not mean every lesson must list every API. A sound mental model focuses on the boundary between specifications, browser implementations, and the particular capabilities a page chooses to use.

Standards describe behavior; browsers provide an implementation

Web standards are technical agreements written as specifications. They describe concepts, data, algorithms, and required behavior so independent implementations can aim for compatible results. WHATWG's HTML Standard, for instance, specifies HTML and describes HTML user agents such as web browsers parsing markup into a DOM. A is not itself the browser running on a person's device. Browser engines and surrounding browser software implement specifications, ship versions over time, and may expose a capability differently depending on version, settings, permissions, or context. This is why careful documentation distinguishes a standard from observed support. A developer should avoid saying that a feature works “everywhere” merely because it worked in one browser. Instead, check the relevant documentation and define what the application should do when the desired capability is unavailable. Standards make interoperability possible; testing and fallbacks make a real application more resilient. The goal is not to memorize standards organizations. It is to recognize that a browser API has a defined contract and an boundary, so requirements should be checked rather than guessed.

Interfaces are the bridge from code to browser capability

An API is an application programming interface: a defined way for code to request a service or work with an object. Web APIs are commonly exposed as objects, methods, events, and interfaces. is a standard language for describing such interfaces, which helps specifications state the names, inputs, outputs, and relationships that an implementation must provide. The DOM illustrates the arrangement. When a browser parses an HTML document, it creates a document representation; the DOM APIs expose that representation to scripts. A script can use document.querySelector in a browser because the browser provides document and the associated DOM interface. The method call uses JavaScript syntax, but the capability being invoked is supplied by the browser. Keeping those roles separate reduces confusion when reading error messages, documentation, or code examples. This lesson does not attempt to teach each API. Fetching data, handling events, storage, media, and accessibility each involve their own APIs and constraints. Here, the transferable skill is to locate the owning platform feature, read its contract, and decide whether it belongs in the application's supported baseline.

Use capabilities deliberately and detect them when a fallback exists

A capability check asks whether the current environment provides the particular feature code plans to use. It is more reliable than guessing from a browser name or version because it tests the capability directly. A small example is checking whether geolocation is present before offering a location-based option: if ('geolocation' in navigator) { /* offer the optional feature / } else { / keep a manual location choice */ }. The check does not grant permission, guarantee a useful location, or replace error handling; it only establishes whether that API is exposed. The fallback should preserve the core task rather than leaving the person stranded. For a manual location choice, that might mean allowing a person to enter a city or postal code. This approach is often called progressive enhancement: begin with a useful base experience, then add an optional enhancement where the platform supports it. It also makes requirements visible to reviewers. A team can document which path is essential, which is optional, and how each is tested. is not a reason to scatter checks everywhere or to avoid reading compatibility information. It is one tool for expressing an intentional boundary between the application and the capabilities supplied by the user's browser.

Eli, the EliExplains learning guide

Eli explains

The same idea, in plain words

Explain it like I’m 10

Think of a browser as a workshop that follows shared instruction books. HTML tells it about the page's pieces, CSS tells it how those pieces can look, and JavaScript lets code ask the workshop to do things. The workshop also provides special tools, called Web APIs. The DOM tool lets code look at the page the browser has built. Those special tools are not automatically part of JavaScript; they are tools the browser makes available. Different browser versions can have different tools or settings, so a careful page checks for an optional tool and still offers a useful basic path.

Picture it like this

The web platform is like a set of common building codes plus the equipment in a workshop. The code says how a door should fit; each workshop builds actual doors and supplies its own tools. A builder can use a tool only if that workshop has it.

Where the picture stops working

Browsers are software implementations rather than workshops, and web standards can specify detailed algorithms, not merely general suggestions. The analogy also does not mean every browser exposes exactly the same optional capability at every time or permission setting.

Worked example

A transit page has an optional “Use my location” button and a manual station search. The developer treats the manual search as the core path. Before enabling the optional button, the page checks whether the browser exposes navigator.geolocation. If it does, the button can request location through that Web API; if it does not, the button is hidden or explained while the station search remains usable. The check does not assume that the user will grant permission or that a location request will succeed, so the page still handles those outcomes. JavaScript supplies the if statement and property check; the browser supplies navigator and its geolocation capability. This separation tells the team where to find the correct documentation and why a fallback belongs in the design.

Key takeaway

The web platform combines standards with the capabilities browsers implement. Identify whether code relies on the JavaScript language or a Web API, then design a supported baseline and a deliberate optional path.

Quick check

3 questions here, of 5 in this lesson’s practice set. Answers stay hidden until you check.

Question 1 of 3foundational

In browser development, what is a Web API?

Choose an answer, then check it.
Question 2 of 3intermediate

A browser parses an HTML page and exposes document.querySelector(). Which pairing is accurate?

Choose an answer, then check it.
Question 3 of 3intermediate

Why is feature detection usually preferable to deciding behavior from a browser name?

Choose an answer, then check it.
Practice all 5

Keep learning

Ready to build on this? Continue to the next lesson.

Practice this lesson
Study tools & related lessonsYou’ll learn to · Common mistakes · Easily confused · Key vocabulary · Related

You’ll learn to

  • Define the web platform as standards plus browser-provided capabilities.
  • Distinguish JavaScript language features from Web APIs.
  • Explain the roles of a specification and a browser implementation.
  • Identify the DOM as a browser-provided interface created from a document.
  • Apply feature detection to choose a fallback path.

Common mistakes

  • Calling every browser capability “JavaScript.”

    Separate JavaScript language syntax from Web APIs exposed by the browser.

  • Treating a specification as proof that a feature is available in every current context.

    Use the specification to understand behavior and check support or capabilities for the environments you support.

  • Checking a browser name instead of the capability needed.

    When an optional feature has a fallback, test for that feature directly.

  • Making an optional API the only way to finish a core task.

    Provide a baseline path, then enhance it when the browser offers the capability.

Easily confused

JavaScript vs. Web API

JavaScript is a programming language; a Web API is a browser-provided interface that JavaScript can call.

Specification vs. Implementation

A specification defines expected behavior; an implementation is software that provides that behavior.

Feature detection vs. Browser sniffing

Feature detection checks the capability itself, while browser sniffing guesses from product identity or version.

Key vocabulary

web platform
The collection of web standards and browser capabilities used to create and run web pages and applications.
Web API
A browser-exposed interface that code in a web application can use to interact with a platform capability.
specification
A technical document that defines expected behavior and interfaces for an implementation.
implementation
A concrete browser or other program that provides behavior described by a specification.
user agent
Software, such as a web browser, that obtains and processes web content.
DOM
A browser-provided object representation of a document that scripts can access.
Web IDL
An interface definition language used by web specifications to describe programming interfaces.
feature detection
Testing whether a capability is available in the current environment before using it.

Sources & references

  1. Web APIs — MDN Web Docs
  2. HTML Standard — Introduction — WHATWG
  3. Web IDL Standard — WHATWG
  4. Feature detection — MDN Web Docs

EliExplains lessons are original prose written from the open, credible references above. See Copyright & Licensing.

Researched 2026-08-20

Educational content only. It is not medical, legal or professional advice. Found an error? Tell us.