Hacker News Reader

Comment by cousin_it | Hacker News Reader

This looks nice, but could someone remind me, why is CSS better than JavaScript for this kind of functionality?

The advantage of doing it in CSS is that browsers can implement animation themselves.

Animation in JavaScript is a bit of a hack - run a loop with setInterval, change the value of various CSS values for each frame, dynamically adjust the frame rate based on the amount of time left, implement your own easing...

If an animation is described to the browser directly (fade from this value to this value taking this much time) the browser can implement all of the above itself, in a standard way. With access to APIs like Core Animation, the browser can even take advantage of hardware acceleration.

I argue that it makes sense for browsers to provide an animation API. The only remaining question is what form that API should take. It can either be exposed as CSS syntax, or as part of the DOM APIs exposed to JavaScript (document.animateElement(el, ...) for example).

CSS is meant to handle presentation logic, so if you define animation as part of the presentation layer of your site then putting it there isn't really that crazy.

These kind of CSS extensions and hacks really begin to feel like Interweb has gotten a new shiny hammer, and is trying to do everything with it. IMHO a cleaner solution would be to have all interactivity/animation done in JS and CSS for styling only.

Implement the whole animation API in CSS? What if I want the animation to be triggered by button click instead of hover?

Handle the click with javascript, adding a CSS class to the element. The class definitions should look like those of :hover in this example.

:active

It's the idea of progressive enhancement. Markup for your content, CSS for your presentation, and JavaScript for behavior/functionality.

It isn't. You'd never include this on an actual site due to compatibility, whereas doing it in jQuery would ensure it works on even IE6. All the "cool effect X using browser specific css" posts you see everywhere on the net are pointless.

They're not "pointless". The articles you're reading now are the future of the web. Handling hover events using JavaScript, when it's strictly presentation, makes much more sense with CSS. You wouldn't use JavaScript to add underlines to links, would you?

In addition (since you mention compatibility), adding this to a site wouldn't "break" it. So a segment of your visitors wouldn't see a "hover" event when they mouse over your images. It still functions properly.

Serving different CSS presentation to different browsers, or having browsers download additional css they can't use only to end up with a presentation that differs between browsers or having to use a jQuery implementation anyway for browsers that do not support the webkit hacks would be an large additional investment of your time to write and maintain with little payout.

I control for my sites to degrade gracefully on the JavaScript enabled\disabled axis, why would someone want to invest additional resources in creating a CSS degradation axis that might conflict with JavaScript and be much harder to predict and control the display output due to browsers updates?

because a lot of people wouldnt go to the bother of using fully fledged javascript solutions for a tiny visual flourish.

most of these css techniques degrade very very well and are incredibly simple to implement, if it is a "this site MUST have this animation", then best to go down the jquery route, if its a "this will be nice to add" then doing it in css3 only saves a ton of bother.

>daleharvey: most of these css techniques degrade very very well

>j79: In addition (since you mention compatibility), adding this to a site wouldn't "break" it

The linked page looks like shit in Internet Explor 6,7, and 8 and is completely unviewable in Opera due to masking errors. It degrades horrendously and I would consider it broken.

You're right, it does. But in fairness, it's a demo for webkit browsers. I'm guessing the author wasn't too concerned for IE.

If the demo page was something super simple like:

#links{ -webkit-transition-duration: 0.5s; } #links:hover { color: red; }

Super simple and it wouldn't break anything.

Basically, just because the author didn't consider IE users on a Webkit demo doesn't mean CSS3 is broken (or doesn't degrade properly.)

I know this is wishful thinking, but here's a solution: Stop worrying about pixel-perfect websites across browsers?

As developers, we degrade gracefully if JavaScript is disabled. How about, instead, we degrade gracefully if the visitor is using IE6?

If a visitor using IE6 views my site and they see boxy divs versus others who see rounded corners, does it take away anything from the IE6 visitor? They're still seeing the content (which, hopefully, is the main purpose of their visit!)

Obviously, this isn't a solution for everyone (and seriously, wishful thinking, hah!)

So for my actual response: You're absolutely right. I'm not arguing we start implementing a CSS3 solution along with a JS solution today. This demo (along with other css3 articles) isn't about today. It's about tomorrow and the future of the web.

However, if we keep catering to older browsers, what's their incentive to upgrade?? Sure, we could throw a JS hack together to get all browsers to function the same, but why? (sorry, wishful thinking again!)

I do commend you on degrading gracefully. Many developers simply don't. And just to point out, I completely understand where you're coming from. Good day!

http://dowebsitesneedtolookexactlythesameineverybrowser.com/

Think of this as you would of NTSC television signals -- people with old black-and-white televisions can still watch the shows, but they wouldn't see all the pretty colours, and probably wouldn't have access to SAP or closed captioning. Progressive enhancement means that people using IE6 (or Lynx, for that matter) can still use the site, but they might not see the latest features.

Using JS to do the dirty work for something that is really no more than pleasant eye candy is somewhat reminiscent of some of the schemes I remember for embedding screen-edge encoding to control mechanical colour wheels to enable colour viewing on B&W tvs -- now, that's pointless.

Reply on news.ycombinator.com