6 ms·
Beautiful Image Hover Effect Using Only Webkit CSS (No JS)
- NathanKP 16y agoVery 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.
- MartinCron 16y agoEffects 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.
- jacquesm 16y agoThat looks really cool. How big a %age of the mainstream browsers can show this effect?
- RossM 16y agoWell since it uses Webkit I guess just Chrome and Safari. It looks like Firefox is behind on animations, although they've implemented transforms now.
- metamemetics 16y ago17.2% (does not work in Opera)
- yread 16y agoOnly for webkit
- mgcross 16y agoNice demo, but I feel that the title is a little misleading as the CSS is more so webkit-specific CSS than it is CSS3.
- sesqu 16y agoI'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.
- rev087 16y agoI 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.
- nirmal 16y agoWhen 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?
- NathanKP 16y agoNot 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.
- rev087 16y agoIf 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 :}
- nirmal 16y agoJust 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.
- NathanKP 16y agoYes, 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.
- CoryMathews 16y agoArrrrg 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..
- nikeshhayaran 16y agoIt is just an example to show how differently we can use CSS3 transition property ... I don't think it ruined the entire article..
- chunkyslink 16y agoNo, I completely agree. But I work with some CSS purists and they would probably think the same thing. Ruined I tell you ! RUINED !
- rimantas 16y agoCSS purist should learn that vendor prefixes are not hacks.
- rokhayakebe 16y agoFrom the comments it says you should switch -webkit to -moz for Firefox, I believe.
- cousin_it 16y agoThis looks nice, but could someone remind me, why is CSS better than JavaScript for this kind of functionality?
- metamemetics 16y agoIt 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.
- j79 16y agoThey'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.
- metamemetics 16y agoServing 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?
- daleharvey 16y agobecause 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.
- nightshadow 16y agoThere 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.
- MartinCron 16y agoThe 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.
- glhaynes 16y agoThe 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.
- MartinCron 16y agoI 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.
- not_an_alien 16y agoYeah, but how is that going to work in the iPad since it has no hover?
- durbin 16y agoi think we have differing opinions on what is beautiful and sexy.
- onecreativenerd 16y agotry moving the mouse around over the images and then look at your CPU graph
- Pistos2 16y agoIn contrast with what others have said, it works for me in Opera 10.53 in Linux.
- drivebyacct 16y agoThis could be done without JS for years. The neat part is doing it without images.