Using a lookup table is a valid way to implement something. It is used often for precalculating expensive functions. (trig tables are very common). This is just one extreme of the runtime-vs-memory trade-off.

Sure, but if the headline was "CSS can be used to implement a lookup table", it would be much less eye-catching.

More to the point, Boolean expressions and truth tables are not equivalent representations that should be treated on an equal footing; there's an exponential blowup involved when converting from one to the other. Just try extending that 4-bit adder to 16 or 32 bits. The functions that can be tractably represented using this scheme are a strict (very small) subset of the functions that can be computed by true Boolean circuits.

The difficulting in actually creating some of these larger lookup tables is, of course, very true. That doesn't mean that sometimes, depending on the problem you're solving, lookup tables can still be a useful (or preferred) implementation method.

It is the programmer's job to decide what point on the "using storage"<->"using CPU time" continuum is appropriate for the current problem. Obviously, larger chained adders at 16 or 32-bits would be crazy. (of course, at that point you would want to implement a carry lookahead anyway to avoid the horrible propagation delay in the last carry bit)

Yes, but this time it is disappointing. If the website was a tool for learning logic gates, it would be perfectly acceptable and quite clever. However, since the website is saying that it has implemented logic gates in CSS, a natural, if not necessary expectation is that these gates should be composeable, which they are not. Logic gates that can't be fed into each other really strain the definition of a logic gate (its part of the reason that circuits are interesting while a piece of paper with a truth table is not)

Edit: Just to clarify, the disappointment is from being excited that something like this could be wired up the way we initially thought. The result remains cool and clever all the same.

Not wanting to be negative here, but I don't get the point of these CSS projects.

CSS isn't Turing complete. It's a (poorly designed) markup tool, not a general symbol processing language. So there's a whole world of stuff it just can't do in any useful way.

Any attempt to make it do this stuff is either going to have to fake it with limited sleight-of-mind, or is simply not going to work.

So "I made s Haskell compiler out of pure CSS" is always going to be disappointing. (If you could make real logic gates, you certainly could make a Haskell compiler. Although it's possible it wouldn't be fast enough for production code.)

I built this for fun, and to remind people that CSS can do more than you think. (it should also be a nice tool to help teach adders)

While I would obviously never do something this insane in a real product, I have used CSS for surprisingly much actual logic in real code (empty states for lists, hiding controls that the user cannot use, etc).

See also http://stackoverflow.com/a/5239256/34397

Exactly.

On FPGAs, it's actually how most logic functions are implemented. FPGAs are a big grid of SRAM-based lookup tables, some latches and fixed function blocks, and a whole ton of interconnections.

But not a single lookup table. If you can chain lookup tables it's equivalent to any other kind of gate. If you have to process all possible input combinations at once you can't do any meaningful computation.

This is how the famous Connection Machine 2's “one-bit processors” were implemented and programmed too, and basically the connection fabric is roughly analogous.

Indeed one can dynamically any kind of rapidly-reconfiguring FPGA-array into a very peculiar and high-performance general parallel processor.

That's correct, typically FPGA logic looks something along the lines of a bunch of logic feeding into a latch the output of which feeds into yet another bunch of logic and so on, and all this synchronized by a clock. The individual lookup tables are quite small, but in the aggregate together with the latches they can perform quite complex functions.

Lookup tables get very large as the number of potentially valid outputs increases and can do only so much (no way to incorporate state with a lookup table).

(Memory elements are lookup tables with feed back. Very instructive to deconstruct for example the gate diagram of the D-flip-flop 7474 into one table with five inputs and three outputs.)

Note that that's all computed by LESS code.

https://github.com/SLaks/Silon#implementation-details https://github.com/SLaks/Silon/blob/gh-pages/styles/_operato...

The actual declarations end up being nicely simple; see https://github.com/SLaks/Silon/blob/gh-pages/styles/_themed-...

The CSS is just a truth table, but the LESS (which is Turing-complete) actually contains all of the logic.

I have to wonder what exactly you expected?

As someone who works with CSS everyday, it's exactly what I expected once I saw it working. How else could it possibly work?

I don't know, that's the point! Implementations frequently have unexpected behavior that can be abused for computational purposes. For example, you can perform computations on an x86 without actually executing any instructions, by setting up the page tables such that the MMU functions as a rudimentary one-instruction computer. https://github.com/jbangert/trapcc

Real, asymptotically-efficient computations in CSS would require some kind of layer of indirection -- a way to make the styling of one element depend on another one. I'm far from a CSS expert and I don't know if such a thing is at all possible, but it's not out of the realm of possibility.

Off the top of my head, you might be able to get somewhere by requiring the user to put their mouse pointer in a certain location, and using box sizes to trigger the :hover pseudo-class. If the pointer covers multiple overlapping elements, is :hover applied to all of them, or just the topmost?