Beautiful Image Hover Effect Using Only Webkit CSS (No JS)(nikesh.me)
nikesh.me
Beautiful Image Hover Effect Using Only Webkit CSS (No JS)
http://www.nikesh.me/blog/2010/05/sexy-image-hover-effects-using-css3/
15 comments
The dark box flipping around on top of the picture seems gratuitous and pointless. It'd be a nicer effect if the picture just zoomed and became brighter.
I totally agree, I'm guessing that the example included that just to demonstrate what was possible as each picture had a different dark box effect.
Other than that, this looks awesome, at least in Chrome on Mac.
Other than that, this looks awesome, at least in Chrome on Mac.
There is a big flaw in CSS3 implementation of animation:
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.
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.
The example in the linked article behaves exactly as you describe, at least in Chrome on Mac. If I just fleetingly hover over something, it pulses up and down at the same speed for the same amount of time. It just looks right.
Yeah, but how is that going to work in the iPad since it has no hover?
Nice demo, but I feel that the title is a little misleading as the CSS is more so webkit-specific CSS than it is CSS3.
When I looked at the markup, I thought, "I would use JS to insert those mask divs." Does anyone else feel that same base compulsion to keep the markup clean?
Not really. Using JavaScript to add mask <div>'s is a messier solution, requiring more KB of code, especially if you want it to work on all browsers, even those that don't properly support DOM manipulation. Also the JavaScript would have to run after the other parent <div> has already been downloaded and rendered, meaning that there would be a brief time when there was no mask.
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.
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.
Just so I'm not missing something, are there browsers which would support the Webkit CSS but not support DOM manipulation? Or are you concerned with people running NoScript style plugins?
Not being hostile, just want to clarify.
Not being hostile, just want to clarify.
Yes, NoScript is a problem. However, I was referring to other scenarios in general where a problem can be solved by just adding a <div> in HTML code. It seems more economical to me to add the <div> manually to the HTML code as in this Webkit example rather than writing a JavaScript routine to manipulate the HTML code at runtime on the client's machine as you suggested.
If you use a javascript library such as Mootools, you could add a onDomReady event, wich fires as soon as the HTML is rendered - even before the <img>. Of course that means yet more Kbs, but almost all solutions have their downsides.
Regarding the original comment, I do feel the urge...clean and easy to maintain HTML is an irresistible compulsion for me :}
Regarding the original comment, I do feel the urge...clean and easy to maintain HTML is an irresistible compulsion for me :}
I'm not sure you can call -webkit-transition-duration CSS3.
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.
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.
I do agree with the usability concerns. The less animation the better, imho. If you remove the animation component that almost all "lightbox-like" implementations use, it's quite a handy feature tho.
But then again, I guess the point of the article was about showcasing what one could achieve with CSS alone.
But then again, I guess the point of the article was about showcasing what one could achieve with CSS alone.
Arrrrg he used only the -webkit hacks and did not put the actual CSS3 commands for other browsers.
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..
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..
It is just an example to show how differently we can use CSS3 transition property ... I don't think it ruined the entire article..
No, I completely agree. But I work with some CSS purists and they would probably think the same thing. Ruined I tell you ! RUINED !
CSS purist should learn that vendor prefixes are not hacks.
From the comments it says you should switch -webkit to -moz for Firefox, I believe.
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.
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.
It's the idea of progressive enhancement. Markup for your content, CSS for your presentation, and JavaScript for behavior/functionality.
[deleted]
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.
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?
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?
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!
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!
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.
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.
>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.)
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.)
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.
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.
That looks really cool. How big a %age of the mainstream browsers can show this effect?
Well since it uses Webkit I guess just Chrome and Safari. It looks like Firefox is behind on animations, although they've implemented transforms now.
17.2% (does not work in Opera)
Very nice! The code is simple and easy to read as well. Now if only webkit had more thorough coverage in browsers so that we could use these pure CSS effects and know that all our visitors can see them.
Effects like this should never be counted on for "all our visitors", it's really more of a progressive enhancement/graceful degradation thing. Example: hover effects won't ever work for people using touch-screen devices.
i think we have differing opinions on what is beautiful and sexy.
Only for webkit
In contrast with what others have said, it works for me in Opera 10.53 in Linux.
try moving the mouse around over the images and then look at your CPU graph
This could be done without JS for years. The neat part is doing it without images.