> 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.
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.
"providing a clock" is not something to dismiss though. Arithmetic plus looping will give you a Turing machine, so you do need both or you're just showing the ability to do arithmetic.
And a proper Turing machine doesn't need an extra line of template html for each iteration. It's much easier to forgive finite memory, since a small amount of memory can go for billions of years while an iteration limit runs out fast.
This one passes all the bars, but I do think the bars were overall legitimate.
> many still claim that even as much as hovering your mouse on a specific part of the screen makes css not a programming language.
clock != looping, those examples already loop (dont need a line per iteration), but just dont have a built-in clock
and requiring a clock is imo dismissable, because pretty much all modern technology needs a clock too (either from the power grid, or from a hardware component designed for it)
Sure, we can separate loops from clocking for the most part. But it doesn't really change the analysis. These loop. The stuff from several years ago didn't loop properly.
As a tangent though, the system is already powered, you shouldn't need a secondary power source to make your Turing machine go. Something there still feels incomplete, like it probably passes but with an asterisk. But that distinction doesn't matter for CSS since it can self-clock.
This is a cool demo, but it tells me that CSS might be too complex now. Why should you be able to emulate a CPU with a styling language? I’m not sure what you get by using a Turing complete language for visual styling.
I don't know much about CSS, but Turing completeness is notorious for showing up in systems unintentionally.
It doesn't take much to be Turing-complete - if a system provides unbounded read/write memory plus branching or conditional recursion you're usually there.
As an example, Magic The Gathering (the card game) is Turing-complete: https://arxiv.org/abs/1904.09828 . You can use creature tokens as memory and various game mechanics to do flow control. Was this intentional by the designers? Most likely not...
* MOV x86: using memory mapped lookup tables, you can simulate logic gates and branching using only MOV.
* PowerPoint (Without Macros): using On-Click Animations and Hyperlinks, shapes on slides act as the tape and clicking them triggers animations that move the head or change the state of the slide.
* find and mkdir (Linux Commands): find has a -execdir flag executes commands for directories it finds. By using mkdir to create specific folder structures, you can create a feedback loop that functions as a Tag System (aka universal computation).
* Soldier Crabs: Researchers showed that swarms of Mictyris guinotae can be funneled through gates to implement Boolean logic. While a full computer hasn't been built with them, the logic gates (AND, OR, NOT) are the building blocks for one.
Even water is Turing Complete:
* Fluidic Logic Gates: the Coandă effect is the tendency of a fluid jet to stay attached to a convex surface. By using tiny air or water jets to push a main stream from one channel to another, you can create the fluid equivalent of a transistor.
* MONIAC (Monetary National Income Analogue Computer)
* Navier-Stokes equations describe how fluids move are TC.
* In 2015, Stanford researchers developed a computer that operates using the physics of moving water droplets. Tiny iron-infused water droplets moved by magnetic fields through a maze of tracks. The presence or absence of a droplet represents a 1 or a 0. By colliding or diverting each other, the droplets interact perform calculations.
Perhaps so, but ISTM that it encapsulates the same basic point. Try to make something rich and general and you often end up re-implementing a whole computer inside your computer.
Which is why these days it's easier in many cases to just embed an Arm core and implement your controller's functionality in software.
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.
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.
I admit I don't have depth of knowledge with how JS and Wasm work behind the scenes, but you can already compile JS to wasm. Forgive the ignorance, but what am I missing here? When you compile JS to wasm, aren't the semantics and language behaviors already addressed?
My understanding was that things like DOM manipulation APIs would need to be (and are) exposed to the WASM runtime so that the JS-to-WASM compiler could do all the right bytecode "linking".
My idea is that if JS itself was require to in WASM, and native JS support didn't exist, the complexity in browsers would be reduced dramatically. And developers will be free to use different languages. Browsers will focus on APIs instead of language semantics. no more V8!
You can't currently "compile JS to Wasm", you can compile a JS engine (likely written in C++) to Wasm and run JS inside that (almost certainly at lower speed). So instead of "no more V8", it's closer to "ship V8 as part of the website, instead of part of the browser". Exposing DOM APIs to Wasm is a completely different question, though even those would actually have to be new APIs with a new API design that works for Wasm, since the existing DOM APIs are effectively defined in terms of JS objects being passed around.
I didn't know this, thanks for explaining. If DOM APIs could be reworked for wasm support, and JS can work with those APIs, that would suffice. It won't get sites off normal JS any time soon. As far as speed, is it an optimization problem? I'd think just running bytecode is faster than interpreting a script. It doesn't need to be backwards compatible with existing JS code, it just needs to be possible to write front end code in JS for WASM. Migrating to the new approach could be similar to migrating away from Flash, ActiveX and Applets, but at a much larger scale.
10-20 years from now, is it really ok to be stuck with JS and CSS? The complexity is compounding, ever newer webapi's get encoded as JS APIs, and the dependency mess will only increase. Browsers are about as complex in some ways as an operating system. If we think about the world in terms of decades, what is the plan? This is a very serious issue, because of how much the world depends on browser tech, and effectively, Google is the arbiter and overseer of that technology. I don't think this will work out well, unless there is some timely foresight in the architecture.
> 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.
It sounds like the consistent pattern is the requirement for browsers to support it. If browsers supported intermediary languages instead, that might be ideal?
Interesting idea. This will be useful only when the CSS communicates with a server. Maybe it can make requests indirectly by setting background image URLs or something and send data piece by piece for each byte. Not sure.
That happens today in the wild even. CSS url() function and basic things like applying background images to semi-invisible blocks for entirely CSS-based data exfiltration. From what I've heard it is most commonly used today for fingerprinting systems of trackers that use a ton of @media queries to try to fingerprint you based on the subtleties of your browser.
Relates to some Safari and Firefox engineers warning on pretty much every new CSS proposal to consider how it can be (ab)used for tracking.
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.
Very cool. The horsle demo made me think, how hard would it be to add a virtual memory address (or a non-8086 RAND instruction) that returns a random byte (that would allow it to pick a random value and get a standard wordle working in principle)
I see CSS random() is only supported by Safari, I wonder if there's some side channel that would work in Chrome specifically? (I guess timing the user input would work)
wasn't a lack of networking what made it a temple, untouched by the influences of the corrupt internet or something like that? idk I'm not like a Terry Davis scholar by any means but I always figured he did that limitation with some kind of reason in mind
I'm curious to know what you would rate as the most important features to make this work? It seems like calc+if do a lot of the heavy lifting, but the new function syntax is what makes instruction lookup tractable.
Predictably, all the same people who bemoan JS ubiquity feel the need to express their distaste for advances in CSS in this thread. Nobody is actually doing stuff like this in real applications, it’s just a demo, for fun.
Your grumpiness contradicts itself. To the extent that it's just for fun, it's not an advance.
And CSS being Turing complete doesn't make it suitable to replace any JS it couldn't already replace, so why can't JS-haters dislike the idea? If I didn't like a language and people offered an even worse to use replacement I'd be justified in having distaste for it!
> To the extent that it's just for fun, it's not an advance.
The features which are being exploited to implement this are indeed advances.
> If I didn't like a language and people offered an even worse to use replacement I'd be justified in having distaste for it!
You’re missing my point. Nobody is actually suggesting replacing JS with CSS, but many new CSS features eliminate the need to use JS to accomplish what you need in terms of behavior or style. Nobody is seriously suggesting CSS is a _replacement_ for JS, it’s just a better solution for certain common things on the web.
> The features which are being exploited to implement this are indeed advances.
The specific way it became Turing complete seems more accidental than anything. We could have had pretty much the same features without the same --var handling.
> You’re missing my point. Nobody is actually suggesting replacing JS with CSS, but many new CSS features eliminate the need to use JS to accomplish what you need in terms of behavior or style.
I'm also talking about replacing specific things. But none of the specific things done in this article are easier in CSS than in JS.
If you're talking about different posts about CSS, I haven't seen those ones.
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"."
The point is that the 8086 doesn't have anything close to the instruction set now referred to as x86_64 or even x86_32. Asking which it is is asking which instruction set it implements. The answer is that it implements the 8086 instruction set.
Saying this is an "x86 CPU emulator" is misleading, even if technically an 8086 is an example of the x86 family. To avoid the misleading ambiguity you'd have to say something like "emulates a member of the x86 family", at which point you may as well just say "8086 emulator".
I think x86 is still good because it's easily understandable. If I say it's an 8086 emulator, people who aren't familiar with the 8086 aren't gonna go "oh so like an older version of the same x86 on my computer". And "Show HN: CSS program that emulates a CPU that's a member of the x86 family" doesn't roll off the tongue.
I don't think calling it x86 is misleading, and this is coming from the perspective of someone who dabbles in rev and pwn of x86.
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
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?
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
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.
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.
> 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.
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.
> essentially just providing a clock
"providing a clock" is not something to dismiss though. Arithmetic plus looping will give you a Turing machine, so you do need both or you're just showing the ability to do arithmetic.
And a proper Turing machine doesn't need an extra line of template html for each iteration. It's much easier to forgive finite memory, since a small amount of memory can go for billions of years while an iteration limit runs out fast.
This one passes all the bars, but I do think the bars were overall legitimate.
> many still claim that even as much as hovering your mouse on a specific part of the screen makes css not a programming language.
That bar is pretty silly.
clock != looping, those examples already loop (dont need a line per iteration), but just dont have a built-in clock
and requiring a clock is imo dismissable, because pretty much all modern technology needs a clock too (either from the power grid, or from a hardware component designed for it)
Sure, we can separate loops from clocking for the most part. But it doesn't really change the analysis. These loop. The stuff from several years ago didn't loop properly.
As a tangent though, the system is already powered, you shouldn't need a secondary power source to make your Turing machine go. Something there still feels incomplete, like it probably passes but with an asterisk. But that distinction doesn't matter for CSS since it can self-clock.
This is a cool demo, but it tells me that CSS might be too complex now. Why should you be able to emulate a CPU with a styling language? I’m not sure what you get by using a Turing complete language for visual styling.
I don't know much about CSS, but Turing completeness is notorious for showing up in systems unintentionally.
It doesn't take much to be Turing-complete - if a system provides unbounded read/write memory plus branching or conditional recursion you're usually there.
As an example, Magic The Gathering (the card game) is Turing-complete: https://arxiv.org/abs/1904.09828 . You can use creature tokens as memory and various game mechanics to do flow control. Was this intentional by the designers? Most likely not...
* MOV x86: using memory mapped lookup tables, you can simulate logic gates and branching using only MOV.
* PowerPoint (Without Macros): using On-Click Animations and Hyperlinks, shapes on slides act as the tape and clicking them triggers animations that move the head or change the state of the slide.
* find and mkdir (Linux Commands): find has a -execdir flag executes commands for directories it finds. By using mkdir to create specific folder structures, you can create a feedback loop that functions as a Tag System (aka universal computation).
* Soldier Crabs: Researchers showed that swarms of Mictyris guinotae can be funneled through gates to implement Boolean logic. While a full computer hasn't been built with them, the logic gates (AND, OR, NOT) are the building blocks for one.
Even water is Turing Complete:
* Fluidic Logic Gates: the Coandă effect is the tendency of a fluid jet to stay attached to a convex surface. By using tiny air or water jets to push a main stream from one channel to another, you can create the fluid equivalent of a transistor.
* MONIAC (Monetary National Income Analogue Computer)
* Navier-Stokes equations describe how fluids move are TC.
* In 2015, Stanford researchers developed a computer that operates using the physics of moving water droplets. Tiny iron-infused water droplets moved by magnetic fields through a maze of tracks. The presence or absence of a droplet represents a 1 or a 0. By colliding or diverting each other, the droplets interact perform calculations.
> Turing completeness is notorious for showing up in systems unintentionally
Greenspun's 10th law.
https://wiki.c2.com/?GreenspunsTenthRuleOfProgramming
That's on the opposite end of the complexity spectrum.
Perhaps so, but ISTM that it encapsulates the same basic point. Try to make something rich and general and you often end up re-implementing a whole computer inside your computer.
Which is why these days it's easier in many cases to just embed an Arm core and implement your controller's functionality in software.
> Try to make something rich and general
It's also easy to stumble into Turing completeness when you're just trying to let one setting modify another setting in a basic way.
Less JavaScript is a bad thing now?
There is absolutely no reason for css to be turing complete. None. That being said, well done
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.
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.
I admit I don't have depth of knowledge with how JS and Wasm work behind the scenes, but you can already compile JS to wasm. Forgive the ignorance, but what am I missing here? When you compile JS to wasm, aren't the semantics and language behaviors already addressed?
My understanding was that things like DOM manipulation APIs would need to be (and are) exposed to the WASM runtime so that the JS-to-WASM compiler could do all the right bytecode "linking".
My idea is that if JS itself was require to in WASM, and native JS support didn't exist, the complexity in browsers would be reduced dramatically. And developers will be free to use different languages. Browsers will focus on APIs instead of language semantics. no more V8!
You can't currently "compile JS to Wasm", you can compile a JS engine (likely written in C++) to Wasm and run JS inside that (almost certainly at lower speed). So instead of "no more V8", it's closer to "ship V8 as part of the website, instead of part of the browser". Exposing DOM APIs to Wasm is a completely different question, though even those would actually have to be new APIs with a new API design that works for Wasm, since the existing DOM APIs are effectively defined in terms of JS objects being passed around.
I didn't know this, thanks for explaining. If DOM APIs could be reworked for wasm support, and JS can work with those APIs, that would suffice. It won't get sites off normal JS any time soon. As far as speed, is it an optimization problem? I'd think just running bytecode is faster than interpreting a script. It doesn't need to be backwards compatible with existing JS code, it just needs to be possible to write front end code in JS for WASM. Migrating to the new approach could be similar to migrating away from Flash, ActiveX and Applets, but at a much larger scale.
10-20 years from now, is it really ok to be stuck with JS and CSS? The complexity is compounding, ever newer webapi's get encoded as JS APIs, and the dependency mess will only increase. Browsers are about as complex in some ways as an operating system. If we think about the world in terms of decades, what is the plan? This is a very serious issue, because of how much the world depends on browser tech, and effectively, Google is the arbiter and overseer of that technology. I don't think this will work out well, unless there is some timely foresight in the architecture.
> 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.
It sounds like the consistent pattern is the requirement for browsers to support it. If browsers supported intermediary languages instead, that might be ideal?
browser is the new os. It should just have first class support for a common bytecode target (wasm), everything follows.
I think the issue with CSS was that the low level APIs wasn't exposed which was the point of project Houdini https://developer.mozilla.org/en-US/docs/Web/API/Houdini_API...
I have mixed feelings. On the one hand, it's impressive, but on the other, it's concerning that CSS is turning into "JavaScript 2".
Now we can embed a cryptominer on a page even with JS disabled! /s
Interesting idea. This will be useful only when the CSS communicates with a server. Maybe it can make requests indirectly by setting background image URLs or something and send data piece by piece for each byte. Not sure.
That happens today in the wild even. CSS url() function and basic things like applying background images to semi-invisible blocks for entirely CSS-based data exfiltration. From what I've heard it is most commonly used today for fingerprinting systems of trackers that use a ton of @media queries to try to fingerprint you based on the subtleties of your browser.
Relates to some Safari and Firefox engineers warning on pretty much every new CSS proposal to consider how it can be (ab)used for tracking.
Yes, CSS binary data transfer is possible in bith directions.
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)
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...
Wait, does it mean you can commit actual CSS crimes now?
That was in the C++ implementation of the CSS interface that gets exposed to JS, though, there wasn't an exploit from CSS.
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.
Very cool. The horsle demo made me think, how hard would it be to add a virtual memory address (or a non-8086 RAND instruction) that returns a random byte (that would allow it to pick a random value and get a standard wordle working in principle)
I see CSS random() is only supported by Safari, I wonder if there's some side channel that would work in Chrome specifically? (I guess timing the user input would work)
It's really easy, I was considering adding it.
The easiest way is to make an @property that's animated at ridiculous speeds that can be sampled to get (sort of) random bits.
Or use a cycle timer and run a PRNG from it.
Or wait for us to launch random() :-) (It's in development, available if you enable a flag)
Definitely in the "they didn't stop to think if they should" category.
They probably did, and just determined that it would be fun.
The other week I had a fun project to implement IPv6 support in TempleOS. I did stop to think whether I should, and determined that absolutely not.
I asked Claude to start planning on doing it. It started referencing ZealOS, which is a fork of TempleOS and already has a functioning TCP stack.
That's when I determined that it would no longer even be fun, because someone else had already done all the heavy lifting, and gave up.
wasn't a lack of networking what made it a temple, untouched by the influences of the corrupt internet or something like that? idk I'm not like a Terry Davis scholar by any means but I always figured he did that limitation with some kind of reason in mind
Me and some friends of mine thought it would simply be funny if we gave the temple just IPv6 (no v4) support.
I know everyone is saying "CSS doesn't need to be Turing complete" but... to me, this just shows the JS isn't needed anymore.
Incredible achievement. Horrible development on CSS front.
CSS should NOT be becoming turing complete. Nor any other DSL.
> 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
It has been a while. This project that implemented logic gates in CSS is 10+ years old:
https://github.com/SLaks/Silon
Linked from here:
https://gwern.net/turing-complete#surprisingly-turing-comple...
That is the problem though, DSLs always end up becoming turing complete, because there is always that use case they don't cover.
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
It relies on a few things, but @functions, if() statements, and container style queries are the main ones.
Some of those things are included in this year's interop
https://wpt.fyi/interop-2026
The moxy of this is inspiring.
I'm curious to know what you would rate as the most important features to make this work? It seems like calc+if do a lot of the heavy lifting, but the new function syntax is what makes instruction lookup tractable.
Abomination! (Makes sign of cross)
Also: wow.
Predictably, all the same people who bemoan JS ubiquity feel the need to express their distaste for advances in CSS in this thread. Nobody is actually doing stuff like this in real applications, it’s just a demo, for fun.
I get the feeling some people just hate the web.
Your grumpiness contradicts itself. To the extent that it's just for fun, it's not an advance.
And CSS being Turing complete doesn't make it suitable to replace any JS it couldn't already replace, so why can't JS-haters dislike the idea? If I didn't like a language and people offered an even worse to use replacement I'd be justified in having distaste for it!
> To the extent that it's just for fun, it's not an advance.
The features which are being exploited to implement this are indeed advances.
> If I didn't like a language and people offered an even worse to use replacement I'd be justified in having distaste for it!
You’re missing my point. Nobody is actually suggesting replacing JS with CSS, but many new CSS features eliminate the need to use JS to accomplish what you need in terms of behavior or style. Nobody is seriously suggesting CSS is a _replacement_ for JS, it’s just a better solution for certain common things on the web.
> The features which are being exploited to implement this are indeed advances.
The specific way it became Turing complete seems more accidental than anything. We could have had pretty much the same features without the same --var handling.
> You’re missing my point. Nobody is actually suggesting replacing JS with CSS, but many new CSS features eliminate the need to use JS to accomplish what you need in terms of behavior or style.
I'm also talking about replacing specific things. But none of the specific things done in this article are easier in CSS than in JS.
If you're talking about different posts about CSS, I haven't seen those ones.
This is absolutely horrible... in a good way. Kinda like Doom in a PDF. Well done.
Really looking forward to a how it works post. What is that READMEM_1??
it's a placeholder that gets replaces by the python script on build
So is this x86 compatible, or 8086 compatible? Because those are different things
8086 is x86
https://en.wikipedia.org/wiki/X86
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"."
That wikipedia article lists the 8086 in its "Chronology of x86 processors" section as an x86-16 CPU.
The point is that the 8086 doesn't have anything close to the instruction set now referred to as x86_64 or even x86_32. Asking which it is is asking which instruction set it implements. The answer is that it implements the 8086 instruction set.
Saying this is an "x86 CPU emulator" is misleading, even if technically an 8086 is an example of the x86 family. To avoid the misleading ambiguity you'd have to say something like "emulates a member of the x86 family", at which point you may as well just say "8086 emulator".
I think x86 is still good because it's easily understandable. If I say it's an 8086 emulator, people who aren't familiar with the 8086 aren't gonna go "oh so like an older version of the same x86 on my computer". And "Show HN: CSS program that emulates a CPU that's a member of the x86 family" doesn't roll off the tongue.
I don't think calling it x86 is misleading, and this is coming from the perspective of someone who dabbles in rev and pwn of x86.
There's a list of the supported opcodes on the page if you scroll down.
If it was 8086 they would have written 8086
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
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?
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
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.
> 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.
This feels like... just because you can, doesnt mean you should.
this is incredible
Next step: Start Chrome in emulated X86CSS and start X86CSS in emulated Chrome.
Next logical step is to compile the CSS to webassembly, of course!
Only Chrome ..
Bruh...
Can it mine bitcoins or run worms?
[flagged]
> 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.
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
Not really, Internet Explorer was single platform and closed source.
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.
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.)
It was suffered on these platforms, because even IE for Mac didn't grant the 'compatibility' with 'web pages' designed for IE.
I realy hope an AI did this intead of human, such a waste of time (the css part, not the x86)
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.
This seems like a great use of time actually
I did not use any AI
If an AI can do this, it's definitely an AGI.