11 ms·
CSS3 proven to be Turing complete?
- forrestthewoods 11y agoThat's horrifying. And I'd argue a damning indicator that CSS3 is wildly overcomplicated. It really shouldn't be Turing complete.
- akerro 11y agoCan you center images yet? :>
- dasil003 11y agoI get the joke since I've been doing the web design thing for a couple decades at this point, but in case your question was serious, yes it is finally solved: https://philipwalton.github.io/solved-by-flexbox/demos/vertical-centering/ https://philipwalton.github.io/solved-by-flexbox/demos/verti...
- meesterdude 11y agocame to say the same thing. I love love love flexbox. I just wish i could drop all the vendor prefixes, but safari seems to be the holdout iirc
- gotchange 11y agoIsn't IE =< 10 supported by the Felxbox model?
- deleted 11y ago[deleted]
- talmand 11y agoSuch knowledge exists, but it requires a long and dangerous journey filled with adventure, thrills, and excitement too bold for most to endure. Many have traveled down that path, but few have returned to tell the tale. I am one of those few. I could easily share that knowledge, but for one to fully understand, one must walk such a path thyself guided by the voices from the source that flows over the stacks of such knowledge.
- gotchange 11y agoAs I walk through the valley of shadow of vertical-align, I took a look at my codebase and I realize there isn't much left ...
- forrestthewoods 11y agohttp://howtocenterincss.com/ http://howtocenterincss.com/ Good luck and God speed. There's no shame in turning back.
- PeCaN 11y agoHeck, it means that theoretically you can't verify a CSS3 stylesheet for correctness because you don't know the stylesheet will ever finish rendering. In practice it's probably not a problem since you don't have infinite HTML, but it is theoretically slightly disturbing. I'm an advocate of provably-correct, non-Turing-complete languages, which really should include CSS....
- Dylan16807 11y agoThis proof does not imply that. It cannot loop without you clicking all the boxes.
- PeCaN 11y agoA static analyzer doesn't know that you won't click all the boxes though.
- Dylan16807 11y agoIt still renders in O(n) time where n is the number of elements. You don't need Turing completeness to have trouble caused by user input. Imagine a million check boxes where the only rule is that they shrink by a pixel when checked. That should be about the same difficulty to analyze as the 110 rule checkboxes. Each input only affects the styling of 1-3 nodes.
- murbard2 11y agoTwo comments: 1) it's not surprising: a lot of very simple systems can compute. It seems to naturally happen as you add flexibility to your rules. See for instance Wang Tiles or some cellular automata. 2) it's not a good thing: it means that the behavior of CSS3 is undecidable in general, which makes it much harder to build tools that can meaningfully analyze it.
- SeanAnderson 11y agoYeah. My initial thought after reading the title was, "Shit. Don't tell people this! Someone's going to be crazy enough to invent something with this knowledge." Anyone who has worked with CSS long enough knows that: 1) Rule priority can get out-of-hand very quickly. 2) It's a nice thought to have more powerful selectors, but, taking #1 into consideration, perhaps limiting its power isn't such a bad idea after all. I was already on-board with using PostCSS modules, https://github.com/postcss/postcss https://github.com/postcss/postcss, to selectively import functionality for use in CSS rather than the heavy-handed approach of bringing all of SASS, LESS, or Stylus. Leaving powerful expression to languages built for it seems natural -- especially when CSS and JS intermingle so heavily.
- d-Pixie 11y agoI completely agree that it's not a good thing. I know that the browser maintainers also see the increasing complexity of CSS as a bad thing. That's why I was so sceptical to it from the start ...
- api 11y agoGUIs tend to do this. I think the reason is that programmers fundamentally underestimate the problem of building a good graphical user interface, and therefore systematically design solutions that are inadequate. These inadequate frameworks then accumulate ugly nasty cruft because their underlying structure is not adequate to elegantly address the problem domain. GUI toolkit and renderer development should begin with the humble admission that building a good GUI system is incredibly hard, on par with massive distributed systems and AI, and that the problem should be tackled with that level of difficulty as an expectation. A good analogy would be between a GUI toolkit and a mature 3d virtual world game engine. Those are probably roughly equivalent problem domains.
- haberman 11y agoSo CSS3 is both Turing complete and so low-level that most projects of significant size use a preprocessor like LESS, SASS, etc to write their CSS3 for them.
- Spivak 11y agoWhat's your point? The same is true for x86 and you don't see many people writing that by hand.
- TeMPOraL 11y agoIt means that JS-as-web-Assembler just got itself a competitor.
- astazangasta 11y agoBoo! Boo to this comment and the horrors it may unleash.
- lucozade 11y agoAlthough as another comment pointed out, as it's Turing complete, you could write an x86 emulator in CSS. So you could write your style sheets in x86 if you were so inclined. Now there's a thought that doesn't bear too much thinking about...
- haberman 11y agox86 is by design an imperative abstraction. It makes sense for it to be Turing-complete. Very few imperative abstractions are not (the only one that comes to mind is DTrace's D Language). CSS is primarily a declarative abstraction that grew complex enough to be Turing-complete. You would hope that by paying that complexity you would at least get an abstraction that was convenient enough to write by hand. But CSS has neither the static-analysis benefits of a non-Turing-complete language nor the convenience benefits of a fully Turing-complete language.
- Dylan16807 11y ago1. Feeding infinite HTML is not the same as feeding tape. A million tape cells can keep a typical Turing machine running indefinitely. A million rows only keep this running for a million execution steps, which is what, a tenth of a second if optimized? 2. The 'crank' here is not part of CSS. Computer languages that are declared 'Turing complete' need to be able to crank themselves. You need to be able to tell them to go, and wait. I accept that magic the gathering Turing machine, (at least as long as you remove the word 'may'), because it's part of the MtG rule set that you continue performing all the state transitions until you reach a halt. 3. Allowing this completely external pump means that anything that can add and multiply three numbers and then exit would be counted as Turing complete, because you can then instantiate an infinite number of these and pump data through. The Turing complete nature of that construction lies mostly in that pump. It is not at all just a crank that say 'go'. And 3 is really the important part here. None of the scary implications of 'Turing complete' come into play, because you can't take the result of one arithmetic statement and feed it into more. All of that playing around is roughly O(n) in terms of page size. Not O(unlimited) as 'Turing complete' might imply.
- lmkg 11y ago> 1. Feeding infinite HTML is not the same as feeding > tape. A million tape cells can keep a typical Turing > machine running indefinitely. A million rows only keep > this running for a million execution steps There are read-only systems that are considered Turing Complete. They also work by concatenating new data (of potentially unbounded size) at each computation step. For example, a one-dimensional cellular automaton called Rule 110: https://en.wikipedia.org/wiki/Rule_110 https://en.wikipedia.org/wiki/Rule_110 . The fact that traditional Turing Machines reclaim storage is an implementation detail, not anything fundamental to Turing Completeness or computer science.
- Dylan16807 11y agoThe distinction is that those systems have "create a new line via X" as a core part. That's not in CSS, that's external. That's the key thing keeping CSS from really being Turing Complete.
- 11y ago
- dheera 11y agoGreat, so now I can write an x86 emulator and run Windows 95 in CSS, but I still can't figure out how to reliably vertically-center an element.
- Raphmedia 11y agohtml, body { height: 100%; margin: 0; } body { -webkit-align-items: center; -ms-flex-align: center; align-items: center; display: -webkit-flex; display: flex; }
- anonbanker 11y agoAnd this is why we are in no way better-off with Chrome as the #1 browser than we were with IE as the #1 Browser. In order to center content reliably across browsers, we have to implement browser-specific hacks, because flexbox was only finalized in May of this year. This has been a struggle since HTML+, so almost 20 years now, just to center content. Thanks Google, Apple and Microsoft. Meanwhile, I have web pages on my hard drive that I designed in 1999 with vertical alignment (amongst other tricks), that worked in Netscape 4.x, Seamonkey 0.86, and still work in Firefox 42. and I never needed a -moz prefix.
- Nadya 11y agoWhat? Flex doesn't need a prefix and hasn't for ages (since version 20. It's on 50 now) Furthermore, it's best that features are behind prefixes to be used for progressive enhancement and any major browser implements new features behind a prefix before it is accepted. There is no "cross browser hacks" for any evergreen browser. Except, ironically given your statement, IE has a buggy implementation. Edge supports it and Microsoft is deprecating IE<11 and will hopefully fix the issues in IE11. The big issues can be avoided by not declaring a min-height. http://caniuse.com/#feat=flexbox http://caniuse.com/#feat=flexbox
- anonbanker 11y agoyes, beta features should be behind a prefix. that's all established. However, if vertical alignment is still prefixed in 2015, I don't think I need to submit more for my case, downvoted as it may be.
- fixermark 11y agoI think there's a flaw in the model. "Assume that the amount of HTML currently loaded is finite but sufficient for all of the state to be properly rendered." So consider <html> <div class="myContainer"> <div>1</div> <div>2</div> <div>3</div> . . . I've never met an HTML streaming solution that won't just stream this sequentially, which means no </div> for myContainer will ever be emitted (and therefore the HTML will never be well-formed, and the CSS will never have sufficient information to lay out). If the HTML were streamed such that <html><div class="myContainer"></div></html> were received, and then the interior of myContainer were streamed, that'd be a different story, but that doesn't exist. So I don't think this blog post's argument that CSS3 is Turing complete works for any real implementation.
- d-Pixie 11y agoWhat relevant CSS rule can't be applied to this? We know our previous context and everything before which is what CSS acts on anyway, no lookahead rules in CSS :) And yes, there could come an yet as to unknown element later that changes the display, displays on top of using position:absolute; for example, of current content. But not that changes how current content itself is displayed.
- vectorjohn 11y agoI'm skeptical a little, in that the article starts off by saying it is "more" Turing complete than C. Something either is or is not Turing complete. The nitpick that a C implementation has a pointer size which limits the memory to !infinite is an unimportant implementation detail. If that's your argument, nothing is Turing complete because the universe is made out of a finite amount of matter and energy. Also, as others have pointed out, it doesn't "run" unless an external thing is pressing buttons. If you allow what are essentially external programs to run, you might as well have Javascript doing the job, and then the headline becomes a lot less interesting.
- neocraftster 11y agoDoes this mean that in addition to a javascript blocker i need a CSS blocker to stop malicious code from being run in my browser?
- d-Pixie 11y agoNot yet :)