← Learn

What Is a 3D Spatial Web Interface?

Software 4 Senses LLC · Last updated 2026-10-01

A 3D Spatial Web Interface is a web application whose user interface lives inside a real-time 3D scene without giving up the structure of a document. The scene's elements — solids, lights, groups, text — nest in a tree, carry stable addresses, receive events, can be laid out by the browser's own CSS engine, and save and load as a document, while a GPU renderer draws them as lit objects in space. The term names a checkable architecture, not a visual style: five concrete properties separate it from a canvas animation with text painted on.

The model that gives 3D elements this structure is the Scene Document Model, which has its own definition page.

What is a 3D Spatial Web Interface?

A 3D Spatial Web Interface is an architecture in which the interface itself — text, controls, cards, navigation — occupies a three-dimensional scene while still behaving as a document. The renderer decides how things look; the scene document decides what things are: elements with parents, addresses, state, and definitions that save.

The definition is deliberately a conjunction: an interface qualifies only when all five properties below hold at once, which keeps the term from collapsing into "any page with a canvas on it."

The gap it narrows: document model vs. render target

The architecture exists because web developers who wanted spatial interfaces previously faced an either/or. Down one road, you keep the document model: HTML elements, CSS layout, links, form controls, the focus order, the browser's text rendering. Everything works — and everything is flat. Down the other road, you take a GPU render target: a <canvas> driven by a graphics API gives you full spatial freedom, but the surface it produces is a void of pixels. There are no elements inside it, no layout engine, no caret, no form, no native scrolling — every one of those must be reimplemented inside the render loop, which is where text gets blurry, tabbing breaks, and content turns invisible to everything that reads documents rather than pixels.

A 3D Spatial Web Interface narrows the either/or from inside the render target. It rebuilds the document's structure — the element tree, the addresses, the events, the save format — over the scene's own elements, and hands the web platform the jobs it already does well: CSS solves layout, the Web Animations API computes easing, and native form elements beside the canvas hold the controls' state and keyboard focus. The GPU keeps custody of projection, lighting, and depth.

The five properties

Five properties, together, define the architecture. Each has its own detailed page.

1. Scene elements as an addressable document tree

The things you see in the scene are elements of a document, not anonymous draw calls: every solid, light, group, line of text, picture, and imported model is part of one parent/child tree of records. A group parents its children the way a container element does — its subtree moves and serializes as a unit — and every record has an id that stays fixed while the scene runs and may carry an authored label that saves with the scene. The reference implementation's lookups — its query interface and the host page's port — accept the label in place of the id, and refuse rather than guess when two records share it, so an element can be found, queried, and referred to by name. This property is the core of the Scene Document Model, detailed in The Scene Document Model: Document Structure for 3D Elements.

2. Layout solved by the web's own layout engine

Nothing in the architecture replaces CSS: where elements are laid out rather than placed at authored coordinates, spatial arrangement starts from boxes the browser has already solved. In the reference implementation, volumes can be arranged by rigs — layout machines that position 3D volumes the way a container positions boxes. A 3D volume has no CSS box of its own, so for each one seated in a rig the engine lays out a stand-in — an empty box of the volume's declared size — inside an offscreen measurement container that the author's ordinary CSS grid and flexbox lay out. The engine reads each solved rectangle and maps it onto a plane in the scene at a fixed scale of 50 CSS pixels to 1 world unit — then applies per-volume 3D deltas such as depth lift and tilt. The measurement container exists only to be measured, and is hidden from assistive technology. The mapping is detailed in Mapping CSS Box Models and Grid Layouts to 3D Coordinates.

3. Input delivered as events on the element tree

A click on a scene element arrives as an event naming that element, not as a screen coordinate a script must interpret. In the reference implementation the pointer is resolved by a CPU ray cast through the same camera model the renderer marches with — exact against JavaScript twins of the distance functions for sphere, box, torus, and capsule, and against a conservative bounding box for other primitives — and a hit on a pickable element enters the scene's message bus as a hover, press, or release message naming that element, for listeners and state machines to react to. A state machine bound to its own element hears a press on that element or on any of its parts, and the bus separately offers bubbling delivery for messages sent to a record, which walks parent pointers toward the scene root and can be stopped the way stopPropagation stops a DOM event. Keyboard interaction with scene content is navigation-level today, with one exception: each operable glass UI control — the reference implementation's in-scene button, switch, checkbox, radio, slider, and text field — keeps its state in a native, focusable form element placed right after the canvas, so Tab reaches those controls in authored order and the element and the glass share one value; the glass label and progress bar keep native but unfocusable counterparts (a span, a progress element). Broader accessibility support is architectural intent, not a compliance claim. The full path from screen space to the bus is traced in Event Propagation in 3D: From Screen Space to Scene Records.

4. Stateful and serializable

The scene is a document, not a program state: objects, materials, animation clips, and declarative (JSON) state machines all serialize into a scene document that saves, loads, and round-trips the way a page does. Each element can carry named clips and its own state machine, and the document stores their definitions, never their live state. Motion follows the same web-native rule as layout — in the reference implementation, animation clips are named keyframe sequences interpolated by the browser's Web Animations API and sampled once per frame into GPU buffers, so easing and timelines come from the platform rather than a bespoke tween engine, and layout transitions collapse to cuts when the platform reports prefers-reduced-motion. How browser-driven easing stays in step with a GPU render loop is covered in Synchronizing Web Animations API Easing with a GPU Render Loop.

5. Deployable as a static page

The finished interface ships as ordinary static files — no runtime service, no account, no calls back to the vendor. In the reference implementation, exporting a scene produces one self-contained folder: a single-file player script, the scene document, and every asset, with all references pointing inward, so it plays from any static host. Embedding is one element over that player, <s4s-scene src="./scene.json">, and authoring capability is structurally absent from the player file rather than hidden behind a flag. This property makes adoption incremental — a spatial page sits beside flat ones on the same host — and anchors Migrating a 2D HTML/CSS Layout to a 3D Spatial Web Interface.

What is 3D Spatial Web Development?

3D Spatial Web Development is the practice of building interfaces with the architecture above — web development extended into depth, rather than graphics programming with content bolted on.

The skills transfer accordingly. A practitioner reasons about grid tracks, focus order, and easing curves before shaders. Depth becomes a layout property the way width and order already are.

What it is not

Three familiar categories look adjacent and are not, because each fails at least one of the five properties.

Decorative canvas 3D. Scroll-driven canvas animations — a product spinning as you scroll, particles drifting behind a hero section — render pixels that merely depict content. Nothing in the canvas is clickable, focusable, or readable as a document; the interface remains the flat page around it. The full distinction — Functional 3D versus Decorative 3D — is drawn in Functional 3D vs. Decorative 3D Web Interfaces.

Game engines in a tab. A full game engine compiled for the browser renders everything itself and solves its own layout inside the render target, independent of the page's CSS. That is the right trade for a game and the wrong one for an interface: the browser's layout engine never sees the interface, so property 2 fails by construction.

VR and metaverse frameworks. These target headsets, avatars, and free first-person movement. A 3D Spatial Web Interface is a page in a normal browser tab, driven by scroll and pointer — in the reference implementation's design language, "rails, not WASD": the visitor keeps one-dimensional scroll input and the world does the moving. Piloting a camera is a skill; scrolling is not.

Reference implementation

The Software 4 Senses 3D Spatial Web Studio is a reference implementation of this architecture. Its renderer is a WebGPU engine that draws scenes by ray marching signed distance functions in a WGSL shader — assembled once from the engine's full primitive catalog and parameterized by capacity limits, never recompiled by scene contents; published scenes ship that shader pre-baked in a few catalog tiers, and the player boots the smallest tier covering the primitive types the scene uses. Imported models are converted in the browser into sampled distance-field volumes, so they march like every other shape. Scenes author in a browser-based workshop and export as the self-contained static packages described under property 5.

Related reading

• Functional 3D vs. Decorative 3D Web Interfaces — the category boundary between an interface and a decoration, in full.
• The Scene Document Model: Document Structure for 3D Elements — how pure 3D elements gain the structure of a document: an element tree, bubbling events, clips and state machines, round-tripping serialization.
• Migrating a 2D HTML/CSS Layout to a 3D Spatial Web Interface — the practical path from an existing flat page to a spatial one.
• Spatial Web Glossary — the vocabulary of the field: slab, rig, rail, stage, passage, and the rest.