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.
Sound cool? I don't think so. Not only does it make CSS more complicated, it makes JavaScript more complicated, too.
Misbehaving
Animation is behaviour. You're telling your elements how to behave. Move this way, disappear, turn around. Good element. Here's a biscuit.
JavaScript was designed to be that layer of interactivity. It's designed to change the values of an object over time. All the mechanisms are right there. By introducing the ability to change element values via CSS, there's now a number of factors that have to be considered:
Cross-browser compatibility
Obviously, right now, there isn't any. Therefore, to create these animations, you'll end up having to resort to JavaScript but having to filter out Safari to create the same effects.
JavaScript interactivity
The other major concern is how accessible are these properties via JavaScript? What if I try accessing a property that is mid-animation? What about after? Will I know the animation has completed? By separating the behaviour layer, it can lead to gaps in expectations.
This gap has already happened with pseudo-elements. Try getting the correct style of a span that happens to get styled by a :first-line declaration. (hint: you can't) By manipulating values within the CSS, life for the JavaScript developer just got a whole lot harder. Are the values that we're checking for accurate?
Accessibility
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.
Remember HTML+TIME?
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 really hope that other browsers don't try to jump on this bandwagon. I'd rather the DOM got extended and we leave behaviour where it belongs: in JavaScript.
Conversation
I'm with you on this one. This sounds really stupid.
mm, well the only positive thing I can think of is that animations will work for people that have css on but javascript disabled...
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:
There are plenty of examples of rich user interfaces today that employ animation - pulsing as a form of highlight comes to mind. These animations are inherent part of the visual presentation. A multi-style page like CSS Zend Garden is a good example – if you change the stylesheet, the animations should change too. They are inartistically linked with it. Having to switch between two versions of Javascript animation code would be… stupid.
Take the case of drag-n-drop in this example. The animation of the drag proxy to it's original location is a user behavior. The animation would be triggered by Javascript – by first setting the transition CSS property and then setting the target location. The rest is again left up to the browser. The DOM CSS manipulation thus provides the necessary entry-point for behavioral animation.
This solution, however, removes the unnecessary rapid fire of Javascript callbacks updating the position over and over again. The overhead is removed and Javascript thread is freed up to perform more useful tasks.
PS: I love the live preview Jonathan
Why is a CSS solution better than a JavaScript solution? How it addresses the technical issues (when did the animation start, what is the value at any given time, what happens when I try to access a property of an element mid-way, how do I know that an element is being animated, when did it stop...)?
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!
Jonathan: I totally agree with you that a JavaScript solution is probably better, as in it's probably more flexible, more robust, and more useful (after all, JavaScript is a full programming language, so it's natural that it would be more robust). But, that doesn't mean it's behavior instead of presentation.
This is going to be more of an issue going forward. As we get more advanced, we're going to need more programming constructs for presentation. CSS is too simple for the future. Either we need a much, much more advanced CSS, or we need to decide it's okay to use a full programing language like JavaScript for presentation.
In short: animation feels like presentation to me, but you're right that JavaScript is better-equipped than CSS to handle that presentational task.
:)
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.
I see good place for a "bounce three times" (or any other animation) addition to :hover and other pseudo-classes, which are, in their current form, already a form of interaction. However, you don't want to use CSS to make all div's flash for 40s when loading a page. I think most people would agree that, if you wanted to do that, you should use javascript.
this sounds like Safari heading to Microsofts IE proprietary filters ...
CSS is to give style to content not to animate content.
This is bad, really bad. I already have enough trouble trying to get effects with Javascript working cross browser wise, and this can add some more confusion, frustration, headaches, and broken keyboards/monitors for ALL programmers. It's already bad enough with browsers conflicting with one another. CSS is for styling/POSITIONING elements on the page - not effects - that is what Javascript is for.
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?
If CSS is meant to give style to content, surely animation is style? I find that current javascript implementations of such behaviour are convoluted to say the least - and one line of code looks highly desirable from a developing point of view.
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.
@Johnathan:
Because it allows visual layer animation to be decoupled from behavioral programming and coupled with visual styles that it belongs to.
I don't see any problem at all. The animation starts when a CSS value changes. If you triggered that in Javascript, you know the time anyway. Value at any given time is exactly the same as now - a value "somewhere in the middle" of the animation in progress. You know when the element stops by adding the transformation duration to the start time.
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:
filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='image.png');
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...
The common javascript syntax for most animation libraries involves passing concrete styling values as parameters (as illustrated by your own pseudocode examples above), which is obiously poor seperation of style and behaviour.
The best/cleanest seperation I've seen in javascript libraries, something like they implement in
Mootools.fx.Morph demo, and Bernie's Animator.apply method, where the animation class' parameter is a CSSclassName. That way the CSS coder gets to decide the visuals.That leaves only the decisions of a) transition-speed and b) 'easing'-effect in the hands of the Javascript programmer. However, most graphic designers I know would love to be able to tweak those parameters themselves, instead of having to go through the programmer all the time...
This is a gray area, and there will always be cases where a pure Javascript animation is more appropriate, but I think Apple's approach is a nicely logical step forward in the development of CSS.
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?
I don't see this idea to be useful at all. It seems like a complete IE6 type of move -- if it's not something that will be supported by everyone (IE, 'fox, Opera), why create it? What value does it have? Sounds better suited for a javascript library to me.
Jeff is advocating blinking in CSS. Oy. Anything between a 2Hz and 60Hz frequency is *unhealthy* to look at! That's what blinking does!
I don't know how I feel about this animation support in Webkit, but I think it's stupid. Not that it's a horrible idea, just that there's so much support in CSS 3 to work on, and I want to at least see the standards-aware browsers working toward that, not thinking of random little "features" that are already achieved with Javascript.