Show HN: X86CSS – An x86 CPU emulator written in CSS
121 points
7 hours ago
| 13 comments
| lyra.horse
| HN
freakynit
3 hours ago
[-]
Incredible achievement. Horrible development on CSS front.

CSS should NOT be becoming turing complete. Nor any other DSL.

reply
mspreij
16 minutes ago
[-]
> CSS should NOT be becoming turing complete. Nor any other DSL

Hasn't it been so for a while? I mean I agree with you but it's a bit late

reply
hudecekdev
2 hours ago
[-]
This is absolutely horrible... in a good way. Kinda like Doom in a PDF. Well done.
reply
Dylan16807
3 hours ago
[-]
> A hover-based clock, such as the one in Jane Ori's CPU Hack, is fast and stable, but requires you to hold your mouse on the screen, which some people claim does not count as turing complete for whatever reason, so I wanted this demo to be fully functional with zero user input.

That hover clock post is from 2023 and the "some people claim does not count" post is 2022. They were probably talking about the ones that make you check thousands of boxes to drive the logic forward.

Anyway, very cool advancement.

reply
rebane2001
1 hour ago
[-]
I wasn't sure whether to address the disconnect in the FAQ - I wanted it to be short and readable.

The idea is that, since a long time ago, there has always been demos that prove turing completeness and other programmy qualities in CSS, but that which people dismiss as requiring user inputs. The ones around by the time the comment got made were definitely at the "keep on clicking on the same spot on the screen" level - essentially just providing a clock.

And seeing discussion from after Jane Ori's hack, many still claim that even as much as hovering your mouse on a specific part of the screen makes css not a programming language.

reply
csmantle
5 hours ago
[-]
I think we can look forward to running this on more non-Chrome browsers once @function [0] gets wider support?

[0]: https://caniuse.com/wf-function

reply
rebane2001
5 hours ago
[-]
It relies on a few things, but @functions, if() statements, and container style queries are the main ones.
reply
culi
58 minutes ago
[-]
Some of those things are included in this year's interop

https://wpt.fyi/interop-2026

reply
notpushkin
5 hours ago
[-]
Whoa!

Completely unrelated but somehow unsurprising:

Zero-day CSS: CVE-2026-2441 exists in the wild - https://news.ycombinator.com/item?id=47062748 - February 2026 (233 comments)

reply
rebane2001
5 hours ago
[-]
I do actually have a CSS CVE[0] in Chrome, but it was in the changelog as "in Animation" instead of "in CSS", so no fun stories/headlines for me :c

[0] https://chromereleases.googleblog.com/2025/06/stable-channel...

reply
carra
2 hours ago
[-]
I don't think it's that unrelated. If you make a system way more complex than it should be (clearly the case with CSS) it's obvious the risk of vulnerabilities increases exponentially.
reply
dmitrygr
5 hours ago
[-]
There is absolutely no reason for css to be turing complete. None. That being said, well done
reply
notepad0x90
4 hours ago
[-]
Can an argument be bade that CSS only exists becuase javascript failed to develop a styling component to displace it?

I like to think webassembly is the right track. But ECMAScript and CSS alike need(ed) to devolve into a simpler byte-code like intermediary language syntax.

Browsers supporting complex languages has always been a bad idea, what they need to support is capabilities, and access and security primitives. wasm hasn't displaced javascript, because afaik, the wasm spec for browsers doesn't require them to implement javascript (and ideally, CSS) via wasm.

Instead of distilling, simplifying and speccing CSS and Javascript, browsers caked on layers upon layers of complicated features. The idea that browsers should define and regulate the languages developers use to write front-end code needs to die.

reply
Leszek
3 hours ago
[-]
The complex parts of JavaScript are the semantics, not the syntax. You could reasonably easily spec a bytecode for JS to get rid of the syntax part, but nothing would change in the complexity (almost all modern engines parse to bytecode as the first step and operate on bytecode from then on).

If you wanted to implement JS in wasm, you'd either need a bunch of wasm extensions for JS semantics (dynamic object shape, prototypal inheritance, etc), or you'd need to implement them in wasm from scratch and basically ship a JS runtime written in wasm. Either that, or you need to change the language, which means de facto adding a new language since the old JS still has to stick around for old pages.

reply
nsonha
3 hours ago
[-]
> CSS only exists becuase javascript failed to develop a styling component to displace it

there is no sortage of projects that do it (especially during the react era, people wanted to get rid of both html and css) but they get pushed down by dogma/inertia mostly. There was iOS constraint layout language ported to js. Seemed pretty cool, but the guy behind it decided to give up and everyone was like welp we tried, didn't work.

reply
Aloha
3 hours ago
[-]
This feels like... just because you can, doesnt mean you should.
reply
voidUpdate
1 hour ago
[-]
So is this x86 compatible, or 8086 compatible? Because those are different things
reply
bux93
19 minutes ago
[-]
There's a list of the supported opcodes on the page if you scroll down.
reply
rebane2001
1 hour ago
[-]
reply
voidUpdate
1 hour ago
[-]
The instruction matrix they provide only includes 8086 instructions, not 186, 286 etc, which are all x86, hence the x at the start. From that wikipedia article, "The term "x86" came into being because the names of several successors to Intel's 8086 processor end in "86", including the 80186, 80286, 80386 and 80486. Colloquially, their names were "186", "286", "386" and "486"."
reply
rebane2001
1 hour ago
[-]
That wikipedia article lists the 8086 in its "Chronology of x86 processors" section as an x86-16 CPU.
reply
sunbum
1 hour ago
[-]
If it was 8086 they would have written 8086
reply
voidUpdate
1 hour ago
[-]
They write both. They write x86 repeatedly in the article and title, then show an instruction matrix that doesn't include, for example, the 468 CMPXCHG instructions or the crypto extensions PCLMULHQHQDQ instruction. Best I can guess, they mean 8086, which they think is equivalent to x86
reply
rebane2001
1 hour ago
[-]
Why is the 8086 not equivalent to x86? PCLMULHQHQDQ is from the CLMUL extension, which only began appearing in CPUs in the early 2010s - are CPUs from before then not x86?
reply
voidUpdate
1 hour ago
[-]
x86 is an overarching group. Each processor is backwards compatible, I believe, so a 486 can run 8086 code, but they are not equivalent. If I download an x86 version of a program, I don't expect it to be written only in 8086 instructions
reply
rebane2001
1 hour ago
[-]
When you download an x86 program you're making a lot of other assumptions too, such as what the target operating system and hardware are. Even 8086 MSDOS software won't directly work in this emulator because it's not emulating DOS nor an IBM compatible, it has it's own addresses for the I/O. It's still x86 though.
reply
rootnod3
1 hour ago
[-]
> What you're seeing above is a C program that was compiled using GCC into native 8086 machine code being executed fully within CSS.

They did write 8086 in the text, but x86 in the title.

reply
_s_a_m_
2 hours ago
[-]
Only Chrome ..
reply
andrewstuart
5 hours ago
[-]
Abomination! (Makes sign of cross)

Also: wow.

reply
MetaMonk
5 hours ago
[-]
this is incredible
reply
gurjeet
5 hours ago
[-]
> Your browser is unable to run this demo. Please try with an up-to-date Chromium-based browser.

Sorry to see internet regressing to Internet Explorer days.

Edited to add: This is the message I get when using Firefox.

reply
randfur
3 hours ago
[-]
For what it's worth Firefox has a bug open to implement some of the core CSS features being used here: https://bugzilla.mozilla.org/show_bug.cgi?id=1950366
reply
StilesCrisis
4 hours ago
[-]
Not really, Internet Explorer was single platform and closed source.
reply
toast0
2 hours ago
[-]
Internet Explorer was certainly closed source, but it ran on many platforms.

It was popular on Mac Os (classic and X). It was also released for Solaris and HP-UX.

reply
robin_reala
1 hour ago
[-]
Internet Explorer on Mac was a completely different rendering engine (Tasman) to Windows (Trident). The only that was the same was the name.

(I swear at some point my brain will run out of space because it’s full of useless things like this.)

reply
anthk
2 hours ago
[-]
It was suffered on these platforms, because even IE for Mac didn't grant the 'compatibility' with 'web pages' designed for IE.
reply
harsh-trvth
4 hours ago
[-]
I'd argue that it's the non-Chrome browsers holding the web back nowadays. Realistically, Firefox and Safari exist to just hold back web standards and eventually implement features Chrome had yesterday.
reply
notpushkin
4 hours ago
[-]
Nice bait.
reply
harsh-trvth
2 hours ago
[-]
Go look at any web proposal. The Mozilla team consistently rejects proposals then relies on WebKit to piggyback on their decision.

This is what I mean by holding the web back. Don't even get me started with WebGPU still not being stabilized in Firefox, or the myriad of features WebKit has not implemented yet with respect to PWAs and service workers.

Really, the situation is more like "Chrome vs two modern IEs".

reply
nsonha
3 hours ago
[-]
I realy hope an AI did this intead of human, such a waste of time (the css part, not the x86)
reply
marmakoide
49 minutes ago
[-]
Don't look at the end destination, look at the journey to the destination

* Learn low-level details of a basic but real-world CPU

* Practice the brain gymnastic of programming an atypical Turing-complete computer

Your created new connections in your brain, put to use some of the old established connections. Having a machine spit-out the emulator would rob you of all that. Like, you can drive from A to B, but running for A to B can do you much good.

reply
saagarjha
1 hour ago
[-]
This seems like a great use of time actually
reply
rebane2001
35 minutes ago
[-]
I did not use any AI
reply