
A working DOS computer built from CSS sounds like a joke someone might make after a long night of debugging. It isn’t. CSS-DOS is a real Intel 8086-compatible computer, complete with memory, keyboard input, video output, BIOS routines and disk support, all described through the same language browsers normally use to set colours, spacing and fonts. This isn’t a fake command prompt or a clever animation. The system can boot DOS software, launch Windows 1.01 and even run a limited version of Doom. The surprising part is how it does it. The computer itself lives inside a CSS file.
A processor built from CSS variables
CSS-DOS uses custom properties as registers, memory locations and processor flags. Calculations move data around, test conditions and work through the steps an 8086 processor would normally handle in silicon or emulator code.
Think of it this way: every byte of the computer’s memory can become a CSS variable. Regular RAM sits in one section, video memory in another, and BIOS data has its own place. When the emulated processor executes an instruction, the stylesheet updates those values. Change the right part of video memory and something appears on the screen. Press a key and the input enters the simulated hardware. The browser isn’t showing a prerecorded sequence. It’s evaluating a huge chain of CSS calculations that behaves like a computer.
That distinction matters. Plenty of web projects look like old PCs, but CSS-DOS actually models one. In its pure form, Chrome can run the machine without JavaScript, WebAssembly or a browser extension handling the processor behind the scenes.
Why one CSS file can exceed 300 MB
Normal emulators store instructions and memory in compact data structures. They can read, write and jump between values efficiently. CSS wasn’t designed for that kind of work, so CSS-DOS has to spell out an enormous amount of state and logic. The result is a very large stylesheet.
A self-contained build, known as a cabinet, can pass 300 MB. Some configurations grow even bigger. Each cabinet is prepared for a specific program and hardware setup, rather than acting as one lightweight emulator that loads anything on demand.
The build process selects a BIOS, prepares a disk image, lays out the initial memory and converts that machine state into CSS. By the end, the stylesheet contains both the computer and the software it’s expected to run. It’s wildly inefficient. That’s part of the point.
When Chrome evaluates the CSS directly, the emulated processor manages only a handful of instructions per second. At that speed, waiting for DOS to boot would test anyone’s patience. The browser-only mode proves the concept works, but it isn’t the practical way to use the project.
A JIT compiler brings the machine up to speed
To make CSS-DOS usable, the project relies on Calcite, a just-in-time compiler built to process computational CSS much faster than a standard browser engine. Calcite reads the same stylesheet and compiles its calculations into native code or WebAssembly. It doesn’t replace the CSS computer with a conventional x86 emulator. The processor design, memory map and hardware behaviour still come from the stylesheet. Calcite simply evaluates that stylesheet at a speed closer to what the project needs.
The performance difference is huge. Instead of crawling through a few instructions per second, the accelerated version can run hundreds of thousands of times faster. That separation is one of the cleverest parts of CSS-DOS. The CSS file remains the complete machine. The faster runtime just gives it enough breathing room to function.
Real software, with real limits
CSS-DOS models an 8086-era PC with up to 640 KB of conventional memory. It supports BIOS services, floppy disks, keyboard input and several display modes. The available demonstrations include DOS applications, early Windows software and programs written for first-generation IBM-compatible hardware.
Programs can also write to their virtual disks during a session. Reload the page, though, and those changes disappear because the original disk image returns. There are plenty of other limits. Compilation takes time. Large cabinets can hit browser memory ceilings. Graphics modes need huge numbers of generated pixel rules. Performance depends heavily on the accelerated runtime. Yes, Doom can run. No, this isn’t how anyone should play it.
What CSS-DOS actually proves
CSS-DOS doesn’t offer a practical replacement for JavaScript, WebAssembly or a proper PC emulator. A 300 MB stylesheet isn’t going to become the next standard for running old software. That’s not why the project matters.
It shows just how far modern CSS can be pushed when custom properties, calculations and generated state machines work together. CSS began as a way to control presentation, yet here it describes registers, memory, instructions and hardware behaviour well enough to boot real operating software.
The project also exposes a useful gap between what a language was designed to do and what it can technically express. CSS-DOS is slow, oversized and awkward by normal software standards. It’s also exact enough to turn a stylesheet into a programmable computer. That’s a ridiculous idea. It works anyway.














