[HN Gopher] CSS is DOOMed
___________________________________________________________________
CSS is DOOMed
https://cssdoom.wtf/
Author : msephton
Score : 473 points
Date : 2026-03-28 20:39 UTC (1 days ago)
(HTM) web link (nielsleenheer.com)
(TXT) w3m dump (nielsleenheer.com)
| Levitating wrote:
| 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?
| oopsiremembered wrote:
| 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.
| Levitating wrote:
| But you don't choose CSS, it's the only tool in the toolbox.
| As long as you stick to the Web.
| sbarre wrote:
| 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.
| Levitating wrote:
| 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?
| micromacrofoot wrote:
| compared to old css, it just keeps getting better
| pier25 wrote:
| I was writing CSS +20 years ago and it's never been better.
| hrmtst93837 wrote:
| People keep reinventing 'better' styling tools, and we ends up
| with more bloat and more magic, while static UIs definately
| stay simpel.
| hexasquid wrote:
| I'm asking the same question!
|
| No doubt the very loudly opinionated not-web-dev community, who
| have So Much To Say about web devs and web tech, have produced
| an uncontroversial, perfect layout system, styling system, and
| language to produce the replacement for this awful web tech.
| Where is it? What is it? Please provide (the better version of)
| a hyperlink to the docs.
| Levitating wrote:
| There's decades of UI frameworks where the structure of the
| elements/widgets dictates the layout. HTML/CSS doesn't do
| that, because it is clearly made to style text documents, not
| UIs.
|
| So yes I will argue that Qt6 and GTK are better than
| flexboxes.
|
| Because you asked for it, here's some documentation to a UI
| framework which I believe to work better than the web stack:
| https://doc.qt.io/qtforpython-6/PySide6/QtWidgets/index.html
| 0x737368 wrote:
| With how these things are going, soon hackers will be challenging
| themselves to run Crysis on calculators and microwaves
| oopsiremembered wrote:
| I think we're going to get to the point where AI will try to
| run Doom on humans.
| OrangePilled wrote:
| This page could use some "Practical CSS scroll snapping":
| https://css-tricks.com/practical-css-scroll-snapping/
| division_by_0 wrote:
| 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.
| OrangePilled wrote:
| 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!
| division_by_0 wrote:
| Yes, and in most cases it's perfectly valid not to
| interfere with scrolling. The nice thing about CSS scroll
| snapping is of course that the browser still handles it
| (instead of it being taken over by JS).
| ogghostjelly wrote:
| Personally, I find it to be a little disorienting. I get a
| bit of motion sickness with scroll snapping and I'm not
| exactly sure why.
| larnon wrote:
| The live demo doesn't work in Brave.
| division_by_0 wrote:
| The demo really does not work in Brave. I use vertical scroll
| snapping on the landing page of one of my projects (enabled
| for screens with a min width of 768px and a min height of
| 600px - should work in Brave): https://cybernetic.dev
| sheept wrote:
| 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/
| captn3m0 wrote:
| 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.
| inopinatus wrote:
| I feel obliged to repeat my assertion that this evolution of
| CSS was inevitable and foreseeable and that the HTML Editorial
| Review Board should've chosen DSSSL in the first place.
| sgbeal wrote:
| It would be really interesting to see this without the texturing
| applied.
| lysace wrote:
| _The game logic runs in JavaScript_
|
| Also: a modern CPU is around 10000x faster than the 486 CPU Doom
| was designed for. Per core.
| rkagerer wrote:
| But where can I try it out in my browser?
|
| EDIT: https://cssdoom.wtf/
| TeMPOraL wrote:
| Never tried Doom on a phone before, this one is surprisingly
| fluid and very playable.
| nine_k wrote:
| 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.
| ranger207 wrote:
| Strafing is implemented on A and D at least, but having one
| hand on the arrows to turn and WASD to move is a bizarre mix
| of modern and original controls
| lights0123 wrote:
| > Interestingly, it was more choppy in Chromium.
|
| Firefox's WebRender is truly a great creation. While Chrome
| is faster at most things especially involving JS, Firefox
| puts so much of its rendering on the GPU so moving elements
| around is incredibly fast.
| edoceo wrote:
| There are some new key-trap ApIs that can handle that, IIRC
| FF don't handle that part as well as Chrome.
| bethekidyouwant wrote:
| It works perfectly in Safari on mobile. this never happens.
| _fzslm wrote:
| My phone IMMEDIATELY got toasty as I started moving around the
| world :')
| notnmeyer wrote:
| at this point i'm more interested in what _can't_ run doom.
| josefrichter wrote:
| scared to go check my washing machine display
| anthk wrote:
| 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
| josefrichter wrote:
| this is wild.
| anthk wrote:
| 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.
| jsjsjxxnnd wrote:
| 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...
| amelius wrote:
| The only thing missing is the ergonomics of a real programming
| language.
| cafebabbe wrote:
| I like the declarative nature of it. It makes it so easy to
| debug anything, with "simple" introspection tools. I feel
| that many horrors will be created when we introduce control
| flow to CSS.
|
| And this project kinda show how far you can go, still, if you
| really want it :D
| amelius wrote:
| A functional language should be able to do both.
| senfiaj wrote:
| It's not just closer. Someone wrote an x86 emulator with CSS
| (it uses JS only for clock to make it more reliable).
| https://lyra.horse/x86css/ . So, CSS is officially Turing
| complete (which is a bit scary IMHO).
| MrDOS wrote:
| 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/
| w-ll wrote:
| Quake Live did come out as a browser NaCl game a year or so
| later.
| hackernudes wrote:
| It was a traditional plugin (NPAPI), not NaCl (Native
| Client). Honestly a total gimmick. I still play Quake Live,
| though!
| swyx wrote:
| thats wild that you can still link to a 2006 blogpost. kudos,
| ars technica.
| socalgal2 wrote:
| [flagged]
| adi_kurian wrote:
| Really cool!
| pverheggen wrote:
| 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
| #viewport { pointer-events: none; } #viewport
| * { pointer-events: initial; }
| quantummagic wrote:
| This is great. And Firefox should get kudos too, for running it
| the best, with fewest workarounds needed.
| h1fra wrote:
| [flagged]
| tomhow wrote:
| Please omit internet tropes on HN.
| https://news.ycombinator.com/newsguidelines.html
|
| We detached this comment from
| https://news.ycombinator.com/item?id= and marked it off topic.
| h1fra wrote:
| So impressive! Bonus, you can wall hack by just deleting a div
| ahah
| ehsankia wrote:
| Even better, since everything is well organized, you can add
| `opacity: 0.7` to `.wall` specifically, and get something that
| looks almost exactly like how old school wallhacks looked like.
| hjkl0 wrote:
| Is that a Doom reference? What's a wall hack? How did it
| look?
| throwaway290 wrote:
| I mean they literally just told you...
| codethief wrote:
| A wall hack is any technique allowing the player to see
| opponents through walls. Googling for screenshots or videos
| should give you a good idea of how it looks.
| sulplisetalk wrote:
| Yawn.
| gfody wrote:
| super playable on ff but I got stuck here
| https://imgur.com/a/6nXbPY3
| rox_kd wrote:
| Couldn't agree more ... Especially how platforms like Stitch 2
| are eliminating the barriers for non-technical individuals to
| actually get pretty decent UI/UX experience ..
| DarthCeltic85 wrote:
| I LOVE this! You did a bang up job, is the skin change function
| coming in a future update?
| malkosta wrote:
| What a master class in linear algebra...
| Roshan_Roy wrote:
| This feels like one of those "because we can" projects that
| accidentally reveals where the platform is going.
|
| CSS started as purely declarative styling, but between things
| like conditionals, math functions, and now these rendering
| tricks, it's slowly creeping into "programmable system"
| territory. Not because it's the right tool for it, but because
| browsers are becoming the real runtime. The interesting question
| isn't "can Doom run in CSS", it's how much logic we'll keep
| pushing into layers that were never meant to handle it.
| rhdunn wrote:
| The question is really about where the boundary between
| presentation (CSS) and interactivity (JavaScript) lies.
|
| For static content like documents the distinction is easy to
| determine. When you think about applications, widgets, and
| other interactive elements the line starts to blur.
|
| Before things like flex layout, positioning content with a 100%
| height was hard, resulting in JavaScript being used for layout
| and positioning.
|
| Positioning a dropdown menu, tooltip, or other content required
| JavaScript. Now you can specify the anchor position of the
| element via CSS properties. Determining which anchor position
| to use also required JavaScript, but with things like if() can
| now be done directly in CSS.
|
| Implementing disclosure elements had to be done with a mix of
| JavaScript and CSS. Now you can use the details/summary
| elements and CSS to style the open/close states.
|
| Animation effects when opening an element, on hover, etc. such
| as easing in colour transitions can easily be done in CSS now.
| Plus, with the reduced motion media query you can gate those
| effects to that user preference in CSS.
| titzer wrote:
| It's abstraction inversion at its finest. Declarative styling
| sounded like a good idea, but it jumped the shark long ago.
| It's begging to become a real programming language but for some
| reason the design ethos behind CSS seems to have been avoiding
| programming at all costs--maybe that's to keep the browser
| renderer in control (and hopefully responsive), maybe it's
| because they didn't want designers to have to learn to program,
| maybe they just hate JS. Whatever the reason, it's clear that
| CSS took a wrong turn and mutated into absolutely the wrong
| abstraction.
| dgb23 wrote:
| The design of CSS has always been weak IMO. What we needed were
| general, simple primitives that can describe layout
| relationships and a compositional layer that includes some
| common defaults.
| ticulatedspline wrote:
| My first thought along these lines was "do I now need a NoCSS
| plugin along with NoScript"
|
| at what point is CSS powerful enough to become a malware
| vector.
| AndreyK1984 wrote:
| I try a simple absolutely layout (all calculated on a server),
| and helps me a lot. 1) no reflow 2) very few exceptions 3) WAY
| EASIER FOR LLMs
| ec109685 wrote:
| Great example as to why people are yearning for CSS in
| TypeScript. Something as simple as if() only works in Chrome and
| there's not a good shim story for CSS versus a more complete
| language, so you end up with this:
|
| > The problem: CSS can compute a number - 0 for visible and 1 for
| hidden - but you can't directly use that number to set
| visibility. There is a new feature coming to CSS that solves
| this: if(), but right now it only just shipped in Chrome.
|
| > So I used a trick called type grinding. You create a paused
| animation that toggles visibility between visible and hidden.
| Then you set the animation-delay based on the computed value to
| determine which keyframe is used: animation:
| cull-toggle 1s step-end paused; animation-delay:
| calc(var(--cull-outside) \* -0.5s); @keyframes cull-
| toggle { 0%, 49.9% { visibility: visible; } 50%,
| 100% { visibility: hidden; } }
|
| > A negative animation delay on a paused animation jumps to that
| point in the timeline. So a delay of 0s lands in the visible
| range, and -0.5s lands in the hidden range. It's a hack, but a
| functional one. When CSS if() gets wider support, we can replace
| this with a clean conditional. ```
| x099999 wrote:
| itt: web developers continue to get more dumb
| yakazaki_10 wrote:
| The fact that CSS has evolved enough to pull off 3D rendering is
| wild. Makes me wonder where the ceiling actually is.
| Dwedit wrote:
| > "I used Claude to create an approximate version of the game
| loop in JavaScript based on the original DOOM source"
|
| This is the real horror here, Uncanny-Valley gameplay Doom. It's
| like those Doom maps where people tried to recreate the game
| levels from memory, but still made a few mistakes and got some
| details wrong. This is like that, but for the gameplay rather
| than the level layouts. It's different enough to be wrong.
|
| We have Green Armor that sets your armor to 200%. Health Bonuses
| that reset your health to 100% if you exceeded that number, too
| bad if you recently collected a Soul Sphere. Switch-activated
| doors that are supposed to stay open, but instead automatically
| close, but then the secret wall unexpectedly activates like a
| manual door.
| madrox wrote:
| This is so disingenuous. You literally clipped the full
| sentence that changes the context significantly.
|
| > "Once I've proven to myself that rendering was feasible, I
| used Claude to create an approximate version of the game loop
| in JavaScript based on the original DOOM source, which to me is
| the least interesting part of the project"
|
| This post is about whether you can render Doom in CSS not
| whether Claude can replicate Doom gameplay. I doubt the author
| even bothered to give the game loop much QA.
| cafebabbe wrote:
| Seriously? Your takeaway from _this_ is bad armor bonus
| computations?
| x099999 wrote:
| The fact that Claude is killing CSS officially means we need to
| switch back to IRC or something. AI is a parasite we cannot
| integrate but only avoid. (P.s. if you work in AI, stop, you are
| literally destructive to humanity.)
| AyanamiKaine wrote:
| Its incredible how far concepts like CSS can be pushed. But
| sometimes I wonder what if CSS would be just JavaScript i.e both
| concept are merged.
|
| Would that be better or worse for webdev? I don't know. But I
| like to ponder.
| tgv wrote:
| I think it would be too easy to create an uncontrollable
| cascade of function calls, causing terrible performance. IMO,
| it's best to keep concerns separated. Perhaps the current
| JS/DOM interface is a bit cumbersome, but it gets a lot done.
| What is your reason for merging?
| AyanamiKaine wrote:
| > What is your reason for merging?
|
| Good question, I personally think that seperating by concerns
| is good. But when problems arise like boundaries that get
| crossed or compilers implementing language features into css
| like Sass, maybe it proves that those things are actually not
| two concerns but one.
|
| Lately I am using Catch2 (a c++ testing framework) and wanted
| to benchmark some code. My first instinct was looking for a
| benchmark framework. But to my surprise Catch2 does also have
| a benchmarking framework included!.
|
| Most people would argue that a testing framework should not
| include a benchmarking framework. But using it myself it
| showed me that both concerns of benchmarking for performance
| regressions and testing are similar.
|
| Similar enough that I would prefer both of them together.
|
| Most people, me included, are asking: "Should this be split
| into more?" But seldom, we ask: "Should this be merge into
| one?"
| senfiaj wrote:
| Someone wrote an x86 emulator with CSS (it uses JS only for
| clock to make it more reliable). https://lyra.horse/x86css/ .
| So, CSS is officially Turing complete (which is a bit scary
| IMHO).
| mikax wrote:
| thats really cool
| bradley13 wrote:
| Is this a proof of how great CSS is?
|
| Or is it proof that CSS has "jumped the shark", adding in a
| plethora of features that have no place in a "stylesheet"?
| antisol wrote:
| Yeah. I came here to say: "this is awesome, but it's _not_
| evidence that css is awesome ".
| virtualritz wrote:
| CSS is /the/ spec to look at to understand how awful something
| designed by committee gets.
|
| In web specs closely rivaled by SVG.
|
| You can pick which one is uglier and you'll be right.
| creesch wrote:
| Be honest, did you just reply to the title and the title along
| even skipping the other comments?
| virtualritz wrote:
| I opened the article and read the first paragraph. Then
| skimmed the rest.
|
| As others pointed out: the fact you can do this in CSS tells
| you everything you need to know if you consider what CSS is
| for. Even w/o ever looking at the spec or understanding how
| it came to be.
| throawayonthe wrote:
| i don't see what you mean? it's a rendering technology
|
| i _guess_ if you 're someone still stuck on the "web
| browsers are for displaying static documents" and "css is
| for prettifying markup" thing, then sure, I bet what you
| said sounds real witty
| Levitating wrote:
| Crazy that the future of software development now looks like
| we'll all be making UIs with specs that just a few years ago
| didn't allow you to trivially center a widget in a container.
| b0ner_t0ner wrote:
| IDDQD
|
| and IDKFA
|
| did not work unfortunately.
| yourapostasy wrote:
| While standalone CSS is not yet Turing complete, I worry about
| the new attack vector categories opened up by moving it towards
| that state. Already I believe attackers have a choice to spread
| the attack payload between CSS, HTML and JavaScript to evade
| current detectors and analysis at the network borders, and evade
| CSP's since we're well into undecidability territory, like using
| CSS attribute selectors if the CSP allows external images or
| fonts. But I'm far from proficient at web browser red teaming. Is
| this worry unfounded?
| codethief wrote:
| > While standalone CSS is not yet Turing complete
|
| Looks like it is, though?
| https://news.ycombinator.com/item?id=47558097
| saidnooneever wrote:
| just a small note on this very cool implementation and write up.
| you wrote modeling tools and animation stuff has camera that
| moves around.
|
| i think ultimately, there also the world moves aroun the player
| and cameras are just a concept to make the frustrum etc (maybe
| modern tools do it differently, im a little out of date)
| ionwake wrote:
| I feel there should be a gov dep where all the "i turned this
| into DOOM" folks get hired, to build the next spicy
| interplanetary propulsion systems. They are clearly needing an
| exotic task to stop twiddling their fingers.
| art0rz wrote:
| They would just end up making the thing they're building run
| Doom.
| andyjohnson0 wrote:
| And then they would find a way to make that embedded Doom run
| the thing that they are building [1]. Possibly inside a
| cellular automaton.
|
| [1] Can Doom Run It? An Adding Machine in Doom
| https://blog.otterstack.com/posts/202212-doom-calculator/
| afferi300rina wrote:
| At this point, I'm just waiting for someone to implement a
| CSS-only browser inside this CSS-only Doom, so we can
| achieve full recursive insanity. The 'Can it run Doom?'
| meme has officially transcended hardware and entered the
| realm of pure Turing-complete masochism.
| SuzukiBrian wrote:
| Within a week they would have a rocket prototype where you
| can plug in a mouse and keyboard and play doom on the exhaust
| flames by mixing different fuel chemicals.
| phplovesong wrote:
| But can it run crysis?
| TZubiri wrote:
| While running Doom on X is typically a show of personal hacking
| skills, and a display of the turing completeness/power of X,
|
| I think that running Doom on X can also be a criticism of X,
| certainly the opposite of the intention in some cases. Consider a
| config mechanicsm, if I prove that I can run Doom on .md or .ini,
| or notepad.exe, most people should be concerned, not just for
| bloat, but for security reasons.
|
| The value of some tech is precisely in what it cannot do, not
| just what it can do.
| kuberwastaken wrote:
| Beautiful. Art.
| AndreasMoeller wrote:
| Perfect!
| batisteo wrote:
| I remember when we needed 4 gifs to make rounded corners on a div
| _joel wrote:
| div tags? pah, I remember when all this were tables lad.
| vardump wrote:
| Tables? Bah. I remember when all of this were image maps
| instead.
| nickcageinacage wrote:
| soooooooo cooool thank you
| mcparchtect wrote:
| soo good
| gigatexal wrote:
| Never ceases to amaze me what people will port doom to
___________________________________________________________________
(page generated 2026-03-29 23:01 UTC)