CSS Animations in Safari
Safari is building in CSS animations. That's right. With a little bit of CSS, you'll be able to animate obects on the page. The transitions are built using a number of CSS declarations for declaring what properties should change, for how long, and even being able to transform the object like rotations.
Animation is behaviour. You're telling your elements how to behave. Move this way, disappear, turn around. Good element. Here's a biscuit.
This gap has already happened with pseudo-elements. Try getting the correct style of a
span that happens to get styled by a
And what of accessibility? While I'm no accessibility guru, I can only imagine the headaches this'll introduce in accessibilty circles.
Extend the DOM
Now, I can see why they thought this was a good idea. CSS makes it really easy to extend without getting in anybody's way and risk incompatibility. Just add a
-webkit prefix and go to town. But the DOM is flexible, too, and would have made it easier to create a cross-browser solution. In fact, I'd love to see the ability to rotate elements like Safari demonstrates.
Imagine if there was an animate or rotate method on elements?
// (property, start, end, duration) document.getElementById('elementId').animate('opacity', .5, 1, 2000); document.getElementById('elementId').transform('rotate', -90, 4000);
At least then all we'd have to do is check if the animate or transform methods existed before overwriting them with our own specifications. You can't do that with CSS.
Of course, Safari isn't the first one to try this. Microsoft has something similar that they came up with in 1999 called HTML+TIME and was even based on standards. Luckily, that didn't catch on either.
All doom and gloom?
There are potential uses for this such as prototyping. It'd make things easier to just drop in a couple extra CSS declarations to demonstrate a potential interaction to a client.
And, as some people suspect, this could be intended for use on the Apple iPhone, enabling developers to include simple animations .
Don't jump on the bandwagon
I'm with you on this one. This sounds really stupid.
Otherwise seems a weird thing to do.
I'm all for browser-native animation. Don't really care how to get there, as long as we get it.
That said, I agree it'd make more sense to run this through the DOM.
I disagree. Many kinds of animated transitions are presentational and have nothing to do with behavior. For example, the pulsing default buttons in dialogs in OS X, or the animated fade that occurs when you roll over buttons in dialogs on Vista. These animations are not behavior, but are actually part of the visual theme of those controls.
A good way of thinking about this feature is to ask yourself if you would have to redo certain animations completely if you changed the visual appearance of your page. If the answer is yes, then that animation is probably presentational and tied to that specific theme.
Anyway, that's what this feature is about.
Yeah I'm gonna have to agree on this one, I can not see anything good coming from this.
I agree. CSS animation is probably one of the dumbest things I've heard in awhile. It seems like the iPhone is plunging web development back into another round of browser wars. I suppose it's to be expected, as we work out the kinks of a (relatively) new medium, but I wouldn't have pegged Apple to be the bad guy this time around. It's almost like a full role-reversal: IE7 becoming more standards compliant, and Safari off doing it's own thing. Being a web developer is fun times, I tell ya!
Along similar lines to my worry: http://www.thelucid.com/articles/2007/10/30/proprietary-css-rules-are-we-returning-to-1995
I'm with Dave here. The "behavior" in Behavior Layer refers to the behavior of the user. The Behavior Layer might be more aptly-named the user-interaction layer. Animations are presentational. The are part of the visual style of a site or web app. They're not (at least usually not) part of the interaction process.
I agree that animation in general does not need to be in CSS, but I think most are missing where I think this might be used the most - :hover
We already use :hover to change the colors of links, what if it faded to the new color? Do you really think that is behavior? Even when the color was already being changed, it was just immediate?
So again, I agree. But I think you are ignoring some uses where it is the same as current practices, just enhanced.
And yeah, I don't expect this to catch on in any other browser ever. But I think there will be some nice widgets come out of this.
I'm pretty sure they introduced it for iPhone and WebClips.
Wow, some really good points there. As for accessibility features, I guess browsers supporting CSS animation will have an option to disable it, something like disabling GIF animation.
And I never knew HTML+TIME. Looks ugly, anyway.
@Dave/Jeff: I define behaviour (of the Content-Presentation-Behavior layer) as change. A user enacts a change by interacting with the page via a mouse click, etc. However, these changes can occur without user intervention or as a continuation of user intervention. A user may begin the interaction by hovering over an element but the animated element behaves in a particular way: it throbs, it bounces, it moves so you can't click on it.
While I'm surely trivializing the development process, the Webkit crew had to build the code to animate an element on the page. They simply made CSS the implementation point. Why not make the implementation point in the DOM? It'd still be available to all the iPhone talkin', widget writin', Safari lovin' folks and yet makes it easier for cross-browser implementations among other things. For example, what happens when I try to animate an object that also has a CSS animation on it?
It's not that I'm saying, "hey, no browser-based animation"... I'm saying, let's put it in the DOM where I think you'll get plenty more traction and offer up plenty more ways to extend the functionality, beyond anything you could do with CSS transformations.
You can animate from the DOM too, by using CSS object model to set the appropriate style rules. The way it is implemented, it work both ways.
Jonathan, I know you're not anti browser-animation. Still, CSS just makes sense to me as the place for this. Animation is a purely visual and presentational thing. CSS is the best place for visual and presentational bits, in my mind. I wouldn't throw a fit if it was in the behavior layer, because I'm not a purist like that -- but if you're choosing, CSS just feels like the right place to me.
If, when you hover over and element, it changes color, where do you specify that color? CSS. So if, when you hover over and element, that element animates, it makes sense that animation would also be defined in CSS.
At least to me. :)
Jonathan: thanks for the response. I can certainly see your angle here, but I sympathize with Apple's reasoning, especially as browser developers.
This goes beyond the scope of your article, but I feel that the 'hover' pseudo-class (which provides precedent for CSS event handling, as Nathan pointed out) is unfairly snubbed by endorsers of the behavior layer. The extra links necessary for IE6 implementation of 'hover' are often called semantically meaningless, but it could be argued that any element with an event associated with it should be a link anyway--it would certainly encourage accessibility. If we're willing to accept behavior into CSS, the line between 'turn red on hover' and 'bounce three times on hover' is blurred somewhat.
Of course, the real reason to use a behavior layer is that many more events than 'hover' exist (for our biggest target--iPhone webapps--the disputed 'hover' is meaningless). As style rules per se, 'red' and 'bouncing three times' do not seem equally valid: one is a static description, one describes three events and is only valid before the last event has completed! But for the simple sort of animation common in Dashboard widgets and webapps, 'bounce three times' is a handy shortcut as a style rule. (Though I certainly agree, bad practice in general.)
Jon, your earlier point about extended DOM functionality that get in the way is another valid counter-argument; there are so many kits out there that add methods to Element's prototype, it would seem dangerous for Apple to assume the 'animate' or 'transform' methods aren't taken. Ok, so Apple could have used 'appleSaysAnimateAndOnlyAppleCanUseThisMethodName', but that would be very un-Apple :-)
It's border-line, but I tend to agree with Dave/Jeff. In my opinion, behavior means user-interaction. There can be two types of animation: animations that are part of visual presentation and animations that constitute behavior. As I'll show below, neither these two use cases contradicts the animations in CSS. Let's look into both cases:
PS: I love the live preview Jonathan
I'll probably just use Flash instead... neither CSS nor JS. ;-)
Seriously though for a moment, for all the good points on both sides, I'm trying to think of a real-world situation where I will need an animation without some kind of event triggering it. Although motion is a visual state, which does suggest CSS, I still see it requiring some type of interaction to activate it.
Pseudoclasses are, unfortunately, the gray area in this argument because they are just shy of true interaction. These are static states that change appearance based on certain conditions, such as a :hover (which is where I start seeing how making a button fade/throb/glow on :hover makes perfect sense).
Rather than argue A/B, perhaps we should elaborate the finer details of what qualifies as a CSS appearance (or pseudoclass), and what qualifies as interaction.
I agree. This is far too familiar, like Microsoft's proprietary extensions to DOM, their half-assed CSS implementations, as well as proprietary CSS (filters that use DirectShow and those awesome page transitions).
You can argue from the other side that these extensions could be written in such a way as to be ignored by other browsers, but if you wanted anybody except a Safari user to view your page properly, you'd have to write supporting DOM animation code, and intentionally skip processing in Safari.
There's no point in reinventing a tool that already exists. If they truly were concerned about both standards and user experience, the best bet would be to support the E4S specification completely, and leverage the performance benefits of a strongly-typed language. Just grab Adobe's source for Tamarin from Mozilla!
I'm with Anton on this one. Presentational animation in CSS seems logical, but you really want control. You want event triggering and you want better control over the conditions of those animations happening.
this sounds like Safari heading to Microsofts IE proprietary filters ...
CSS is to give style to content not to animate content.
I DO like the fact that they are trying to enhance a previous language. BUT not like this. THIS is wrong.
Users don't care how the Internet/web site works, BUT the programmers do.
Looking at this from a cross-browser development angle is nonsensical. Surely CSS is meant to enhance a person's experience of a website? Wouldn't you prefer your ice cream with chocolate sauce and a cherry?
What the property allows for is implicit animations - i.e. providing a smooth transition from one state to the next - instead of jumping. Not a complete timeline control of an animation state - look at it like Core Animation in Leopard.
I'm glad that the WebKit team are advancing towards a better Web - if that means proprietary CSS, so be it. Heck, no other browser supports multiple backgrounds natively... why should I support them?
I agree with Dave Hyatt, this type of animation is styling and belongs in CSS.
Perhaps there'd be less confusion if we call it "CSS Transition Effects", rather than "CSS Animations". It doesn't do full animation - you couldn't exactly program Pacman with it, that requires a full programming language - this is just style transitions.
I certainly hope other browsers implement it too, and I can create nice smooth effects on my website.
Ben: Having multple backgrounds is a property of CSS3, not because the WebKit team is particularly clever. I was unaware, though, that the animations being discussed are for smooth transition animations.
Having looked at the WebKit specs a little more, I can see that it's going straight to exactly what microsoft did: custom properties and filters available via proprietary CSS. One difference is that they intend to submit these change to the w3c, so maybe we'll see their inclusion in one form or another.
What I don't want to see is another browser that brings yet more proprietary baggage to the web.
Because it allows visual layer animation to be decoupled from behavioral programming and coupled with visual styles that it belongs to.
All of these questions/problems are just a valid (and problematic) on current JS-only implementations of animation.
Michael - Multiple backgrounds are in the CSS3 specification for sure, but to be honest I have no idea why they aren't supported anywhere else yet. Adding more markup to achieve the same effect defeats the point somewhat.
As for proprietary CSS - as long as it's legible and it works well, what's the problem? Would you rather have the CSS spec frozen because of the W3C's painfully slow progress? Do you mind waiting another 5 or so years for Microsoft to update Internet Explorer? Wouldn't it be grand to actually have good tools for development - like a proper grid based layout engine?
Oh wait, my bad. We already have that. It's called a table.
The only time proprietary markup is bad is when it's in place of functionality that should be built in. IE6 needs this kludge to render PNGs with proper transparency:
Trust Microsoft to come up with proprietary CSS that has their name in it.
Animated CSS? sounds too much like <blink>blink</blink>
Jonathan, my first impression with this idea was the same as yours. However, the more I think about it, the more appealing I find it.
Bear with me for a moment...
Mootools.fx.Morph demo, and Bernie's Animator.apply method, where the animation class' parameter is a CSS
className. That way the CSS coder gets to decide the visuals.
I am only half an expert compared to most hear but they way I see it is that CSS should stay for STYLING (hint: Cascading Style Sheet) :?
@Chris: What's wrong with blinking? The bling HTML element was a bad idea, because a presentational property should not be part of HTML, but it would be perfect for CSS. Granted, the property would be widely abused by lousy web designers, but that doesn't mean it's entirely useless. And, if it belongs, CSS is certainly the place where it should exist.
@Jermayn: So your assertion is that animation is not "styling?" I would beg to differ.
How many users (%) of internet use Safari?
Jeff is advocating blinking in CSS. Oy. Anything between a 2Hz and 60Hz frequency is *unhealthy* to look at! That's what blinking does!