Hacker News Reader

Comment by alex_h | Hacker News Reader

Can someone enlighten me as to why "pure CSS" is seen as the pinnacle of web design? It seems that for problems involving a computational element like this, Javascript would be much more concise and readable. Having said that, it is beautifully done.

View on HN

I would say that from 2006 and earlier, designers sought to go "pure CSS" primarily because of the possibility of javascript being disabled on the client. Especially for search engine crawlers at the time, this would be a bad thing.

Things have changed and more and more people run with javascript enabled, and more and more website stakeholders are willing to put up with things being broken for users who don't have it enabled. I know that's a contentious statement, but it's true. If Google Analytics and ads aren't being pushed down to you because javascript is disabled, most site owners are willing to put up with the experience being broken for you too. I'll sidestep the debate of graceful degradation.

Now however, there are performance reasons for going "pure CSS". A lot of CSS transforms and animations are hardware accelerated and/or just animate more fluidly than they would if they were animated via javascript. Javascript is single threaded, and when a webpage is doing a ton of varied activities, it's hard to ensure fluid animation when the only tools at your disposal for drawing frames are pretty crude methods like setTimeout.

In addition to what the other replies said, there's another reason: effects like this reside purely in the presentation layer, and just like the argument for separating content from presentation, a good argument can be made for trying to separate application code from presentation as much as possible. The less animation you're doing with JavaScript, the less your application code will have worry about updating the presentation layer in a loosely coupled way – just changing a CSS class or whatever already provides that (relatively) loose coupling.

At BigDoor, we ship the same JavaScript code to many different partners, but their widgets can have very different form factors and visual effects. It's nice to not have to distribute a bunch of animation code to every partner just in case one partner's theme happens to use it – we can keep it in the CSS and just swap that out.

Soon I think people will see that using JavaScript for the simple animations they've been performing all this time (fade out, slide in, etc.) is just creating a tightly coupled system.

Javascript is turing-complete. That's a /lot/ of power and that means that security-conscious users (especially given the proliferation of more-powerful JS apis allowing the possibility for exploits in file, GPU, etc. access, along with JIT-enabled exploits as opposed to the old simple interpreting) will have it turned off whenever possible.

Using CSS for non-turing-complete interactions which are limited in their computational ability to a simple automaton means that CSS can be trusted much more than JS, and that there are stricter guarantees on performance. It's also semantically cleaner when used for things like visual effects on windows, because even if CSS doesn't load, the markup representing the menu will be intact. JS systems have the ability to load markup asynchronously or generate it from other data in the page and destroy all notion of graceful degradation.

Let's be clear: "security-conscious users" who turn off Javascript are a very small minority. If a site is geared towards serving developers or small startups, it might be serving this minority. If not, SEO ("how do I make this site readable by search engines?") will be a much larger concern than "graceful degradation for the benefit of the tiny few who care about security enough to disable Javascript or use NoScript but not whitelist my sites' scripts". Often designing something to gracefully degrade will serve both SEO and security-conscious users, but in cases where it won't (this case for example -- where Google decidedly doesn't care about the layout of the navigation items, as long as they're accessible to it), there's not much incentive to find a pure-CSS approach when a pure-JS approach might be simpler.

CSS is technically Turing complete too: http://lambda-the-ultimate.org/node/4222

It has nothing to do with turing completeness.

More complexity leading to bigger surface area for potential attacks, yes. GPU and file access, yes. But nothing to do with turing completeness.

Here's a non turing complete language I wouldn't like to be able to run in a web context. It has a single command: rm {path}

On the other hand a turing complete language that has no access to any IO, DOM manipulation etc. I would be perfectly happy to let run.

It isn't the power that comes from turing completeness that makes javascript a potential security vulnerability, it's the interactions it can have outside of computation.

Its imperative nature (mutation, side effects) and potential non-termination makes it unattractive as a catch-all hypertext document language.

By using the language of Least Power (timbl@w3c.org) that still accomplishes your task, you achieve a more concise and more analyzable document.

I wouldn't call that "nothing to do with TC".

Its imperative nature is unrelated to TC.

Non TC languages can be sufficiently complex as to make analysis difficult.

I don't see any of the risks of js as linked to TC in any meaningful way beyond a very hand-wavey "TC tends to lead to complexness".

People like to push a technology as far as they can. It's part of the satisfaction of mastering a tech that you think of ways to push it beyond what is considered the comfort zone of that tech.

There might be some inherent value of avoiding javascript, but I think this is just a hack for the satisfaction of being able to do it.

> There might be some inherent value of avoiding javascript

CSS transitions are faster than JavaScript animations[1].

Browser could easily optimize them (since each keyframes are predefined) vs. DOM manipulation, which is always slow.

[1]: https://developer.mozilla.org/en/CSS/CSS_animations

Reply on news.ycombinator.com