In 2006, Ars Technica published an April Fool's article[0] declaring that the perennially-forthcoming Duke Nukem Forever would finally see the light of day... as... a browser game! Ho ho, how droll.
Works smoothly in Firefox. But the default key mapping is busted: fire at Alt means that it opens and closes the menu in Firefox with each press. Also, Alt + left arrow ends the game and goes back in history.
Interestingly, it was more choppy in Chromium.
I could not find a key for moving sideways ("strafing").
Use 3D CSS to enhance a 2D page with some flair. But be aware, 3D CSS, it's trying to solve things that most realtime 3D rendering does not, like intersecting planes need to be subdivided in order to correctly handle transparency. This means 3D CSS has an O(N^2) or worse type of issue vs rendering yourself using WebGL or WebGPU where you'd avoid those issues. This demo probably does not intersect any planes but the browser itself has to check for those intersections anyway. TL;DR: If you're going to make a 3D web game use WebGL or WebGPU, not 3D CSS
Creating 3D scenes with CSS has always been possible[0], but like this project, it's required JavaScript for interactivity.
But there's a lot more CSS features now. While in the past, Turing completeness in CSS required humans to click on checkboxes, now CSS can emulate an entire CPU without JavaScript or requiring user interaction.[1] So I wonder if DOOM could be purely CSS too, in real time.
> Yes, Lyra Rebane build a x86 CPU completely in CSS, but that technique is simply not fast enough for handing the game loop. So the result is something that uses a lot of JavaScript.
In recent years CSS has become closer to a full programming language through experimental features, for example in 2025 they added if statements and some math functions like modulo
I was amazed when I first came across CSS scroll snapping. It's great for creating immersive experiences where one part of the page fills the entire screen while native browser scrolling still works.
I ran calypso.z3, tristam_island.z3 and a few more Zmachine text adventures under an interpreter created in PostScript.
Also if I want I can cross-compile a static build of Frotz for Linux/Misc and emulate it under a RISC interpreter for Linux syscalls written in... Perl, runable in every modern Perl port out there. Linux/RISC binary under Perl for NetBSD/Vax? Yes. Slow? Not much, it's a text game in the end.
But, as for the ZMachine, you can run text adventures in Android,
Game Boy, Amiga, MSDOS, Windows, Palm PDA's... anything 8bit and up.
Also, damn Sokoban under Eforth written in Subleq, a VM which can just:
- set up a 2^16 RAM size
- single opcode: substract A from B, if less than 0, go to addr in C.
- A < 0? Get ASCII input in B
- B < 0? Put ASCII output in B
- C < 0? End
This, just this, and people wrote Subleq simulators in C, AWK, Python, TCL, FPGA's and whatnot. And it will run Eforth, and that means... you can write a
ZMachine interpreter on it and be really slow if emulated in a Pentium 4 (maybe 3/5 seconds per command with a ZMachine on top of Eforth for Muxleq instead of Subleq), but the game will be playable and a great exercise on Turing completeness.
If a Mandlebrot render under Muxleq+EForth (with no floats used, just integers) is as fast as a C64/Amiga with a native Forth. then having that tiny EForth+Muxleq is not that useless.
Is CSS that awesome? It's still a language designed for styling webpages with 30 year of added features. I'd argue something purpose built would be a much better tool for the potential usecases people try to use CSS for now.
I guess I am asking, if modern CSS is so awesome, it's awesome compared to what exactly?
I think the argument lies in its flexibility and versatility (regardless of it being the most efficient or effective tool for this one particular task).
Duct tape is awesome for the same reason -- even though there are several effective use cases for duct tape where a different tool would technically be "better" for the job.
I am not sure what a purpose-built tool would look like, but the CSS-like language you see in UI frameworks like GTK is tailored for styling actual UI's.
In CSS on the web, just centering a div has historically been a problem. We have flexbox now, but what if CSS was designed with our current needs from the get-go?
In 2006, Ars Technica published an April Fool's article[0] declaring that the perennially-forthcoming Duke Nukem Forever would finally see the light of day... as... a browser game! Ho ho, how droll.
Crazy to see how far we've come.
[0]: https://arstechnica.com/gaming/2006/04/forever/
Quake Live did come out as a browser NaCl game a year or so later.
Seriously impressive, especially the viewport culling trick, not seen that one before.
FYI if you want to use inspect element, the viewport div consumes mouse elements, you can get rid of this with
But where can I try it out in my browser?
EDIT: https://cssdoom.wtf/
It works perfectly in Safari on mobile. this never happens.
Works smoothly in Firefox. But the default key mapping is busted: fire at Alt means that it opens and closes the menu in Firefox with each press. Also, Alt + left arrow ends the game and goes back in history.
Interestingly, it was more choppy in Chromium.
I could not find a key for moving sideways ("strafing").
All in all, quite mind-boggling.
Never tried Doom on a phone before, this one is surprisingly fluid and very playable.
This is great. And Firefox should get kudos too, for running it the best, with fewest workarounds needed.
FYI: this is a cool hack and very impressive, but ... don't do this. That fact that it runs doesn't make it a good idea. Like running DOOM in Excel (https://github.com/Pranshul-Thakur/DOOM-in-excel) or making a DIV for every pixel and rendering by changing colors of divs https://news.ycombinator.com/item?id=46409359
Use 3D CSS to enhance a 2D page with some flair. But be aware, 3D CSS, it's trying to solve things that most realtime 3D rendering does not, like intersecting planes need to be subdivided in order to correctly handle transparency. This means 3D CSS has an O(N^2) or worse type of issue vs rendering yourself using WebGL or WebGPU where you'd avoid those issues. This demo probably does not intersect any planes but the browser itself has to check for those intersections anyway. TL;DR: If you're going to make a 3D web game use WebGL or WebGPU, not 3D CSS
Very cool demo though!
Creating 3D scenes with CSS has always been possible[0], but like this project, it's required JavaScript for interactivity.
But there's a lot more CSS features now. While in the past, Turing completeness in CSS required humans to click on checkboxes, now CSS can emulate an entire CPU without JavaScript or requiring user interaction.[1] So I wonder if DOOM could be purely CSS too, in real time.
[0]: https://keithclark.co.uk/labs/css-fps/ [1]: https://lyra.horse/x86css/
The author links to th CSS x86 project:
> Yes, Lyra Rebane build a x86 CPU completely in CSS, but that technique is simply not fast enough for handing the game loop. So the result is something that uses a lot of JavaScript.
In recent years CSS has become closer to a full programming language through experimental features, for example in 2025 they added if statements and some math functions like modulo
https://www.simplethread.com/new-and-upcoming-css-features-i...
The only thing missing is the ergonomics of a real programming language.
With how these things are going, soon hackers will be challenging themselves to run Crysis on calculators and microwaves
I think we're going to get to the point where AI will try to run Doom on humans.
This page could use some "Practical CSS scroll snapping": https://css-tricks.com/practical-css-scroll-snapping/
I was amazed when I first came across CSS scroll snapping. It's great for creating immersive experiences where one part of the page fills the entire screen while native browser scrolling still works.
When done right, I oddly find it immersive too. But know some people aren't fond of scrolling being tampered with.
The post here could really use it though. The main content is pushed to the bottom of the page!
Really cool!
It would be really interesting to see this without the texturing applied.
at this point i’m more interested in what _can’t_ run doom.
scared to go check my washing machine display
I ran calypso.z3, tristam_island.z3 and a few more Zmachine text adventures under an interpreter created in PostScript.
Also if I want I can cross-compile a static build of Frotz for Linux/Misc and emulate it under a RISC interpreter for Linux syscalls written in... Perl, runable in every modern Perl port out there. Linux/RISC binary under Perl for NetBSD/Vax? Yes. Slow? Not much, it's a text game in the end.
But, as for the ZMachine, you can run text adventures in Android, Game Boy, Amiga, MSDOS, Windows, Palm PDA's... anything 8bit and up.
Also, damn Sokoban under Eforth written in Subleq, a VM which can just:
- set up a 2^16 RAM size
- single opcode: substract A from B, if less than 0, go to addr in C. - A < 0? Get ASCII input in B - B < 0? Put ASCII output in B - C < 0? End
This, just this, and people wrote Subleq simulators in C, AWK, Python, TCL, FPGA's and whatnot. And it will run Eforth, and that means... you can write a ZMachine interpreter on it and be really slow if emulated in a Pentium 4 (maybe 3/5 seconds per command with a ZMachine on top of Eforth for Muxleq instead of Subleq), but the game will be playable and a great exercise on Turing completeness.
If a Mandlebrot render under Muxleq+EForth (with no floats used, just integers) is as fast as a C64/Amiga with a native Forth. then having that tiny EForth+Muxleq is not that useless.
https://github.com/howerj/muxleq
https://freedom.github.io
Use Deutex, GNU make and Pillow for Python to compile.
Then wou will have up-to-date IWADS to be used aywhere. No need to put ID copyrights, just a mention to FreeDoom creators.
this is wild.
> CSS is awesome.
No
>> CSS is awesome.
>No
Yes
CSS is awesome?
No
Yes
> [Paladin] Attack!
The game logic runs in JavaScript
Also: a modern CPU is around 10000x faster than the 486 CPU Doom was designed for. Per core.
Is CSS that awesome? It's still a language designed for styling webpages with 30 year of added features. I'd argue something purpose built would be a much better tool for the potential usecases people try to use CSS for now.
I guess I am asking, if modern CSS is so awesome, it's awesome compared to what exactly?
I was writing CSS +20 years ago and it's never been better.
I think the argument lies in its flexibility and versatility (regardless of it being the most efficient or effective tool for this one particular task).
Duct tape is awesome for the same reason -- even though there are several effective use cases for duct tape where a different tool would technically be "better" for the job.
But you don't choose CSS, it's the only tool in the toolbox. As long as you stick to the Web.
What kind of system would you propose (or do you envision) for applying visual styling to HTML markup in modern web pages today?
You can keep it high level but your comment makes me think you have something in mind, and I'm honestly curious.
I am not sure what a purpose-built tool would look like, but the CSS-like language you see in UI frameworks like GTK is tailored for styling actual UI's.
In CSS on the web, just centering a div has historically been a problem. We have flexbox now, but what if CSS was designed with our current needs from the get-go?
compared to old css, it just keeps getting better