Beautiful Image Hover Effect Using Only Webkit CSS (No JS)
nikesh.me
nikesh.me
Other than that, this looks awesome, at least in Chrome on Mac.
If the animation is interrupted midway (i.e the animation happens on :hover, and the user moves the mouse away), the reversed animation always takes the same amount of time. This can result in the reverse animation proceeding at different speeds (try setting the -webkit-transition-duration to 5s, and hover your mouse over the element for just a second).
Instead, the browser should precisely reverse the animation it has already played, e.g. if half the animation has already occured, for 0.25 seconds, the reverse animation should similarly last only 0.25 seconds.
In my opinion, it is just easier and cleaner to add an extra <div> to the code than to add a bunch of extra lines of JavaScript to do the same thing.
Not being hostile, just want to clarify.
Regarding the original comment, I do feel the urge...clean and easy to maintain HTML is an irresistible compulsion for me :}
That said, the animations are really just sugar, and would be painful in any browser that doesn't handle them very fast (I used to hate lightbox). Since the effect may still be worthwhile without them, and purdy with them, I prefer this to javascript.
But then again, I guess the point of the article was about showcasing what one could achieve with CSS alone.
i.e. -webkit-box-shadow:0px 0px 30px #ccc; should have box-shadow:0px 0px 30px #ccc; and so on. It just ruined the entire article..
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.
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.
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?
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!
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.
>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.
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.)
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.