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.
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.
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.
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.
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?
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 :}
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.
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.
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.
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?
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!
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.
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.
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.
