On June 2, 2026, a project called CSSQuake reached 131 points on Hacker News, catching the attention of developers who appreciate unconventional browser experiments. The project, built by Layoutit Studio, runs id Software’s 1996 first-person shooter Quake entirely through HTML and CSS. There is no WebGL, no Canvas API, and no traditional JavaScript rendering loop handling the graphics.
TL;DR: CSSQuake is a browser port of id Software’s 1996 shooter Quake that renders 3D graphics entirely through HTML and CSS using the PolyCSS engine. The project reached 131 points on Hacker News, demonstrating that CSS can handle real-time 3D rendering without WebGL or Canvas APIs.
What Is CSSQuake and How Does It Work?
CSSQuake is a browser-based port of Quake that renders every frame as inspectable HTML elements and CSS properties. According to the project’s GitHub repository maintained by Layoutit Studio, the game runs without any traditional graphics API. The PolyCSS engine handles all 3D math and converts it into CSS transforms.
The project’s official site at cssquake.com describes the experience simply: players can “play Quake in your browser with no install” while the game “renders the game as inspectable HTML and CSS powered by PolyCSS.” This means every wall, floor, and enemy visible on screen is a DOM element positioned with CSS.
When a player opens Developer Tools, they can inspect the 3D scene as regular HTML. The DOM updates in real time. Each element receives CSS transform properties that position it in 3D space. The browser’s rendering engine then composites these elements into the final image.
This approach is unconventional. Most browser-based 3D games rely on WebGL, which provides direct access to the GPU through a JavaScript API. CSSQuake bypasses that entirely. The PolyCSS engine translates 3D geometry into CSS 3D transforms, perspective properties, and matrix operations that the browser already knows how to render.
The Hacker News discussion around the project drew 24 comments, with many developers expressing surprise that CSS could handle this workload at all. One commenter noted the technical audacity of attempting real-time 3D rendering through a styling language designed for document layout.
What Is the PolyCSS 3D Engine?
PolyCSS is the custom 3D engine that powers CSSQuake. The GitHub repository describes it as the core technology that makes CSS-based 3D rendering practical. It handles perspective projection, geometry transformation, and scene management — all output as CSS properties on DOM elements.
The engine works by converting 3D scene data into CSS 3D transforms. Each surface in the Quake map becomes an HTML element with properties like transform: rotateY() and translateZ(). The CSS perspective property on a parent container creates the depth illusion. PolyCSS calculates the correct matrix values for each frame.
Key technical components of PolyCSS include:
- Perspective projection system — converts 3D coordinates to screen-space CSS values
- Transform matrix calculation — generates CSS
matrix3d()or individual rotate and translate properties for every visible element per frame - DOM element management — tracks which surfaces are visible and creates, updates, or removes HTML elements as the player moves through the level
- CSS property optimization — minimizes the number of style recalculations by batching updates and reusing existing DOM nodes where possible
- Input handling layer — captures keyboard and mouse input and translates it into player movement, view rotation, and game actions
- Level geometry parsing — reads Quake’s original BSP map format and converts brush data into renderable CSS-positioned surfaces
- Texture mapping via CSS — applies Quake’s original textures as background images on DOM elements, scaled and positioned to match the 3D perspective
- Frame rate management — attempts to maintain playable performance despite the overhead of DOM manipulation and CSS recalculation on every frame
PolyCSS essentially functions as a translation layer. It sits between Quake’s game logic and the browser’s rendering pipeline. The engine takes 3D scene data from the Quake engine and outputs CSS instructions that the browser interprets as visual elements.
The result is a 3D game rendered through CSS compositing. The browser’s built-in layout and paint systems handle the actual pixel output. This is fundamentally different from WebGL, where JavaScript sends drawing commands directly to the GPU.
Can You Actually Play Quake in CSS Without JavaScript Rendering?
Yes, but with important caveats. CSSQuake runs and is playable in modern browsers, but the performance characteristics differ dramatically from a WebGL or Canvas-based port. The game logic itself still requires JavaScript — PolyCSS uses JS to read input, update game state, and calculate 3D transforms.
The key distinction is what handles the rendering. In CSSQuake, JavaScript does not draw pixels. Instead, JS updates CSS properties on DOM elements, and the browser’s CSS rendering engine produces the final image. This means the game is technically CSS-rendered, even though JavaScript drives the underlying simulation.
Players can load cssquake.com directly in their browser. The game renders the original Quake level geometry using HTML elements styled with CSS 3D transforms. Movement, looking around, and interacting with the environment all function. The experience is genuinely playable.
However, the DOM is not designed for real-time 3D graphics. Every frame requires the browser to recalculate styles, perform layout passes, and composite dozens or hundreds of transformed elements. This creates significant overhead compared to GPU-accelerated rendering paths.
The project demonstrates what CSS can technically achieve. It also shows why nobody ships production games this way. The rendering pipeline fights the browser’s layout engine at every step.
How Does CSSQuake Compare to WebGL and Canvas-Based Ports?
CSSQuake trades performance for technical curiosity. WebGL-based Quake ports like QuakeJS use the GPU directly through a JavaScript graphics API, achieving smooth frame rates and accurate lighting. Canvas-based ports draw pixels through a 2D rendering context. CSSQuake does neither — it relies entirely on DOM elements and CSS properties.
The performance gap is substantial. WebGL ports can hit 60 frames per second on modest hardware because the GPU handles geometry rasterization in parallel. CSSQuake must update individual DOM elements, trigger style recalculation, and let the browser composite the results. This process is far slower per frame.
Here is how the rendering approaches compare across key dimensions:
| Feature | CSSQuake (PolyCSS) | WebGL Port | Canvas 2D Port |
|---|---|---|---|
| Rendering method | CSS 3D transforms on DOM elements | GPU shaders via JS API | 2D pixel drawing context |
| Performance | Limited by DOM and style recalculation | GPU-accelerated, typically 60 FPS | Moderate, CPU-bound |
| Developer Tools inspection | Full DOM and CSS inspection of 3D scene | WebGL canvas, not inspectable | Canvas pixel data, not inspectable |
| GPU acceleration | Indirect, through browser CSS compositing | Direct GPU access | Minimal or none |
| Accessibility of implementation | Uses standard web technologies | Requires graphics programming knowledge | Requires manual rendering code |
| Best suited for | Experimentation and education | Production browser games | Simple browser games and emulators |
The biggest advantage of CSSQuake is inspectability. A developer curious about how a specific wall or enemy is rendered can open DevTools, find the corresponding DOM element, and see the exact CSS transform values. This makes the project valuable as a teaching tool for understanding 3D projection and CSS transforms.
WebGL ports are faster and more practical for actual gameplay. But they abstract the rendering behind a canvas element. The GPU work happens in compiled shaders that are opaque to inspection. CSSQuake exposes every rendering decision as readable CSS properties.
The Hacker News community recognized this trade-off. The 131-point discussion reflected appreciation for the engineering effort rather than excitement about a new way to play Quake. The project proves CSS can function as a 3D rendering layer. It also proves why WebGL exists.
What Are the Technical Limitations of Rendering 3D in Pure CSS?
CSSQuake renders 3D graphics without WebGL, Canvas, or JavaScript-based rendering engines. Instead, the PolyCSS 3D engine uses CSS transform: matrix3d() properties applied to DOM elements. Every visible surface in the game world exists as an HTML element positioned in 3D space using CSS transforms. This approach works. But it comes with constraints.
The browser’s CSS engine was never designed for real-time 3D rendering. Each wall, floor tile, and enemy sprite requires individual DOM nodes that the browser must composite every frame. According to the GitHub repository, PolyCSS handles the mathematical projections — converting 3D coordinates to 2D screen space — entirely through CSS transform matrices. The GPU accelerates CSS compositing, which is why the game runs at all. Still, performance depends heavily on element count.
Texture mapping presents another challenge. Traditional game engines map textures onto polygon surfaces using UV coordinates. CSS has no native equivalent. The PolyCSS engine approximates textured surfaces by tiling background images across transformed elements. Perspective correction on these textures is limited because CSS transforms apply uniformly to each element rather than per-pixel. This produces visible warping at certain viewing angles — a trade-off inherent to the approach.
Lighting and shading are similarly constrained. CSS cannot perform per-pixel lighting calculations. The original Quake relied on lightmaps baked into texture data. CSSQuake approximates this with pre-rendered texture data that already includes shading information. Dynamic lighting effects — muzzle flashes, flickering torches — require creative workarounds using CSS filters or opacity changes on overlay elements.
| Limitation | Traditional Engine (WebGL) | CSSQuake (PolyCSS) |
|---|---|---|
| Rendering API | GPU shaders | CSS transform matrices |
| Texture Mapping | UV-mapped polygons | Tiled background images |
| Per-Pixel Lighting | Real-time lightmaps | Pre-baked into textures |
| Element Count | Single canvas | Hundreds of DOM nodes |
| Frame Rate Target | 60+ FPS | Variable, hardware-dependent |
Why does any of this matter? Because CSSQuake proves that browser rendering engines can handle surprisingly complex 3D scenes through their CSS pipeline — a pipeline originally built for styling documents and laying out text.
Who Created CSSQuake and What Is the GitHub Repository?
CSSQuake was developed by LayoutitStudio and is available as an open-source project on GitHub. The repository, hosted at github.com/LayoutitStudio/cssQuake, contains the full source code for both the game implementation and the underlying PolyCSS 3D engine that powers it. The project’s tagline describes it as “a port of Quake (1996), powered by the PolyCSS 3D engine.”
The GitHub repository includes the PolyCSS engine as a core dependency. PolyCSS handles the mathematical heavy lifting: converting 3D world coordinates into CSS-compatible transform matrices, managing the scene graph, and updating DOM element positions each frame. The engine computes perspective projections, handles camera movement, and translates player input into viewport changes — all outputting CSS properties rather than drawing to a canvas.
The live demo is hosted at cssquake.com, which describes the project simply: “Play Quake in your browser with no install. cssQuake renders the game as inspectable HTML and CSS powered by PolyCSS.” The site requires no downloads, plugins, or external dependencies beyond a modern browser.
The repository structure separates the PolyCSS engine from the Quake-specific game logic. This separation means developers can study how the rendering engine works independently of the game assets. The engine’s source code reveals how CSS matrix3d() transforms are constructed from 3D position and rotation data. Each frame, PolyCSS recalculates these matrices for every visible element and writes them as inline CSS styles.
The project was submitted to Hacker News by user msalsas, where it garnered 131 points and 24 comments within hours of posting. The community response highlighted both the technical achievement and the novelty of seeing a 1996 first-person shooter rendered entirely through CSS transforms.
How Did the Developer Community React on Hacker News?
CSSQuake appeared on Hacker News and quickly accumulated 131 points with 24 comments — a strong reception for a CSS experiment. The post, submitted by user msalsas, linked directly to cssquake.com, where visitors could immediately play the game in their browser. The discussion centered on the technical audacity of rendering a 3D game without WebGL.
Commenters on Hacker News examined how PolyCSS achieves real-time 3D rendering through CSS transforms. Several participants discussed the performance implications of using DOM elements as rendering primitives. Some noted that modern browser engines have become fast enough at CSS compositing to make projects like this feasible — something that would have been impossible a decade ago.
The Hacker News thread also drew comparisons to other CSS experiments. Developers referenced earlier projects that pushed CSS beyond its intended purpose, including CSS-based 3D demos and pure-CSS animations. CSSQuake distinguished itself by implementing a complete game rather than a static scene or simple animation. The fact that it rendered a recognizable Quake level with textures, movement, and shooting mechanics impressed many commenters.
The project also appeared on hckrnews.com, a site that sorts Hacker News submissions by time. CSSQuake was listed alongside other popular submissions, confirming that it resonated with the broader developer community beyond the initial Hacker News thread. The discussion revealed genuine curiosity about the PolyCSS engine’s architecture and whether the approach could scale to more complex scenes.
Several commenters on Hacker News pointed out that CSSQuake serves as a stress test for browser rendering engines. The project pushes CSS compositing, transform calculation, and DOM manipulation to levels that ordinary web pages never approach. This makes it a useful benchmark for evaluating how different browsers handle extreme CSS workloads.
What Does CSSQuake Mean for the Future of CSS as a Rendering Platform?
CSSQuake demonstrates that CSS has evolved far beyond its original purpose as a document styling language. The PolyCSS engine proves that modern CSS transforms — specifically matrix3d() — can handle real-time 3D rendering when combined with GPU-accelerated compositing. This raises a question: could CSS become a viable rendering platform for interactive applications beyond demos?
The answer is nuanced. CSSQuake works because browsers now GPU-accelerate CSS transforms and compositing. The browser treats transformed elements as layers that the GPU can composite efficiently. This architectural shift — from CPU-driven layout to GPU-driven compositing — is what makes projects like CSSQuake technically possible. A decade ago, the same approach would have produced single-digit frame rates.
However, CSS remains fundamentally a declarative styling system. It lacks the programmatic flexibility of WebGL or WebGPU, which provide direct access to GPU shaders and rendering pipelines. CSSQuake’s PolyCSS engine must translate every 3D operation into CSS property values, introducing overhead that a native rendering API avoids. The DOM itself adds latency — each element update triggers style recalculation, layout passes, and compositing.
The implications extend beyond gaming. CSSQuake shows that interactive 3D experiences can be built using standard web technologies that every browser supports natively. No WebGL context creation, no shader compilation, no canvas element required. The entire scene exists as inspectable, debuggable HTML and CSS. This accessibility could make 3D web content easier to build for developers who already know CSS but not graphics programming.
For the broader web platform, CSSQuake highlights how browser rendering engines have matured. The CSS pipeline — from style resolution through layout to compositing — has become fast enough to handle workloads its designers never anticipated. Whether this leads to new CSS features designed explicitly for 3D rendering remains an open question.
Can You Inspect and Modify the Game Using Browser DevTools?
Yes — and this is one of CSSQuake’s most distinctive features. Because the game renders entirely through HTML elements and CSS properties, every visible object exists in the DOM. Players and developers can open browser DevTools, inspect any wall or sprite, and see the exact CSS transform matrices that position it in 3D space. This is impossible with canvas-based rendering, where pixels are drawn to a single element.
The cssquake.com site explicitly highlights this capability. The project description states that it “renders the game as inspectable HTML and CSS.” Each frame, PolyCSS writes updated transform: matrix3d() values as inline styles on DOM elements. DevTools’ Elements panel shows these values updating in real time as the player moves through the level.
This inspectability has practical value beyond novelty. Developers learning 3D graphics can examine how perspective projection translates to CSS transforms. Each wall element’s matrix contains the mathematical result of the camera’s position, rotation, and perspective calculations. By inspecting these values, developers can understand the relationship between 3D coordinates and the 2D screen positions that CSS ultimately renders.
Modification is equally straightforward. Because the game uses standard CSS, developers can override styles, change element properties, or inject custom CSS rules using DevTools. Changing a wall’s background image, adjusting opacity, or modifying transform values produces immediate visual results. This makes CSSQuake an interactive playground for experimenting with CSS 3D transforms in a way that static tutorials cannot match.
The ability to inspect and modify the rendering pipeline in real time sets CSSQuake apart from other browser-based Quake ports. Traditional ports using WebGL or Canvas render to a single element, making individual objects invisible to DevTools. CSSQuake exposes every surface as a discrete, addressable DOM node.
Frequently Asked Questions
Do you need a powerful computer to run CSSQuake?
CSSQuake runs in any modern browser that supports CSS 3D transforms and GPU-accelerated compositing. The project requires no installation — visitors to cssquake.com can play immediately. However, because the PolyCSS engine updates hundreds of DOM elements per frame, performance scales with the browser’s CSS compositing speed and the device’s GPU capabilities.
Is CSSQuake a complete port of the original Quake game?
CSSQuake is a functional demo that renders Quake’s 3D environments using CSS transforms rather than a full recreation of the entire 1996 game. The GitHub repository describes it as “a port of Quake (1996), powered by the PolyCSS 3D engine.” The project demonstrates the rendering technique with recognizable Quake levels, movement, and shooting mechanics.
Can CSSQuake be used for actual game development?
CSSQuake is primarily a technical demonstration of CSS-based 3D rendering, not a production game engine. The PolyCSS engine that powers it handles CSS transform matrix calculations and DOM element management, but CSS lacks the rendering performance and flexibility of WebGL or WebGPU. The project is best suited for experimentation, learning, and pushing the boundaries of what CSS can do.
Where can you try CSSQuake yourself?
The live demo is available at cssquake.com, which requires no download or installation. The full source code is available on GitHub at github.com/LayoutitStudio/cssQuake, where developers can examine the PolyCSS engine, run the project locally, and inspect how CSS transforms drive the 3D rendering pipeline.
Summary
CSSQuake represents a remarkable technical achievement: running id Software’s 1996 shooter entirely through HTML elements and CSS transform matrices. Here are the key takeaways:
CSS can handle real-time 3D rendering. The PolyCSS engine converts 3D coordinates into CSS
matrix3d()transforms, proving that modern browser CSS pipelines — with GPU-accelerated compositing — can render interactive 3D scenes without WebGL or Canvas.Every game element is inspectable. Unlike canvas-based rendering, CSSQuake exposes every wall, floor, and sprite as a DOM node. Developers can open DevTools and watch CSS transform matrices update in real time as the game runs.
Performance comes with trade-offs. The approach requires hundreds of DOM elements updated per frame, making frame rates dependent on browser CSS compositing speed and GPU power. Texture mapping and dynamic lighting are limited compared to traditional rendering engines.
The project is open source. The full code is available at
github.com/LayoutitStudio/cssQuake, with the PolyCSS engine separated from game logic, allowing developers to study the rendering architecture independently.The developer community noticed. CSSQuake earned 131 points on Hacker News with 24 comments, sparking discussions about CSS as a rendering platform and the maturity of modern browser engines.
Try it yourself at cssquake.com, then explore the source code on GitHub to see how CSS transforms can build a 3D game engine.