THE OPEN STUDIO / THE EDGE
Can HTML and CSS become 3D?
Move ordinary DOM surfaces in perspective. Learn the difference between spatial styling, a graphics engine and the experimental declarative 3D model element.
Depth can be an illusion with a real model behind it.
CSS 3D isn't a new kind of HTML file. It is a way to transform ordinary document boxes in three-dimensional space. A card can rotate around its Y axis; six flat elements can form the visible faces of a cube; layers can recede in perspective. The browser still knows those elements as DOM nodes.
That is why some astonishing “HTML-only 3D games” exist. They arrange flat browser surfaces in a 3D coordinate system. It's clever and inspectable, but it isn't equivalent to a general-purpose mesh renderer with arbitrary models, lighting and shaders.
Turn a flat card into a spatial surface.
Rotate the card around its Y axis. With a perspective distance on its parent, the farther edge appears smaller, much like looking at a physical panel in a room. The underlying element is still an ordinary HTML <div>.
These controls update CSS custom properties; the example's HTML stays the same.
Try a steep angle, then return to zero. The depth perception changes even though the content and DOM structure have not.
Three technologies that are not interchangeable.
.scene {
perspective: 700px;
}
.card {
transform: rotateY(25deg) rotateX(8deg);
transform-style: preserve-3d;
}
/* CSS 3D positions DOM surfaces in perspective.
It does not load a mesh or provide a full rendering engine. */1. CSS 3D
Best for a small set of DOM surfaces: cards, cubes, layered illustrations and editorial depth. Browser hit testing and semantics remain important, and deeply rotated content can become hard to read or target.
2. WebGL or WebGPU
A <canvas> can host a GPU-backed rendering context. WebGL is broadly available for interactive graphics and conventional 3D engines. WebGPU provides more modern GPU rendering and compute capabilities, but support and environment constraints still require checking. These APIs are considerably more complex and need intentional accessibility alternatives.
3. The proposed HTML model element
The Immersive Web community is developing <model> for declarative 3D resources. Apple/WebKit implementations make this fascinating to explore, but it is not a universally supported HTML baseline feature and must not be the only way essential content is presented.
Choose the smallest spatial tool.
- For a flipping info card, plain CSS transforms may be sufficient—provided the interaction remains accessible without flipping.
- For a complex interactive scene with real models and materials, a graphics API or 3D library is a better fit.
- For a simple diagram, SVG or a static image may communicate better than any 3D scene.
- For experimental native 3D, treat
<model>as an optional progressive enhancement.
A scene needs a way out.
Respect reduced-motion preferences and offer a way to stop continuous movement. Keep focus and reading order aligned with the visible interaction. A 3D transform can produce a tiny target even when the DOM rectangle remains large; test pointer accuracy, keyboard focus and zoom.
Complex 3D rendering can consume significant GPU resources, power and memory. Device capability, texture sizes, resolution and scene complexity matter. Feature detection and fallbacks are part of engineering, not signs of failure.
Build a scene without losing the document.
Break it
Rotate a paragraph 80 degrees and try to read it. Does the fact that it's still selectable HTML make it usable? What happens to perceived hit targets?
Build it
Make a six-faced CSS cube from DOM elements. Add a plain list describing the faces, keep essential controls outside the transformed scene, and provide a reduced-motion alternative. Then explain what would change if you needed a textured, lit model instead.