Webkit introduce more new features
The Webkit team have certainly been busy recently; since we mentioned the introduction of web fonts, they’ve also implemented transformations and animations.
Transformations, via the -webkit-transform property, allow you to scale, rotate and skew block elements; reader Ain Tohvri has put together an impressive test suite. At the moment this property doesn’t affect layout, so behaves more like a relatively positioned element.
Animation, which uses the -webkit-transition family of properties, allows you to set timings for fades, rotation, expansion, collapses, and more. They work in the same way as many current JavaScript libraries.
I’m in two minds about this; while it’s always welcome to see more innovation from browser manufacturers, I can’t help but think that they’re focussing their energies in the wrong direction. As I mentioned above, all of the above effects can be replicated with JavaScript libraries, and I don’t think that CSS should be used for controlling behaviour so explicitly. Users who don’t like to see animated pages currently have the option of disabling scripts, but they won’t have the option of disabling CSS in the same way.
Also, IMHO, there are a more pressing areas of CSS that need investigating; the Advanced Layout or Grid Layout modules are more important to the future of CSS than animations and transformations.
On the positive side, the Webkit team have promised to release technical documents which explain the proposed spec in detail.
If these new features float your boat, you can test them out by downloading the latest Webkit nightlies.
Is it true that transitions are behaviours? A warning div is yellow, a warning div with yellow-fade is an advanced visual clue.
You can do today: div:target {display:block}, why not do do div:target {transition:fade-in}?
If a user want to disable transition the there can be an option to “disable css transitions” in the browser.
Peter,
I think these new CSS features are incredibly important and valuable - they specifically address key selling points for proprietary solutions like Flash (rotation, simple animation). They may sound like flippery, but they’re key features that users want, and any styling mechanism that doesn’t include them has a big gap.
And I’ve never found a cross-browser javascript library that enables rotation and skews - can you let us know where to find one?
Finally, for advanced animation like Pacman, I agree script is the better solution (you couldn’t do that using webkit’s new styles anyway). But for simpler effects like CSS menus that fade in and out, I don’t see why you should need any script at all. These effects are “style” effects, and I think belong in CSS.
I think the delineation between CSS and Javascript should be along separation of layers - visual and behavioral. Animations and transformations are quite on the boundary, but I’d say animations are more a visual design feature.
Think of it this way: consider a multiple layouts web page (ala CSS Zen Garden) where you switch from one stylesheet to the other - do the animations change, too? Of course they do.
In a web page with properly separated of layers, Javascript causes dynamic changes in the web page mostly by changing class names. (A line in a table being highlighted, a tab being active etc.) The visual implications are left up to CSS. Animations should be no different. Coding them in Javascript is a workaround that can get very tedious as RIA’s get more complex.
I agree these properties seem fairly harmless, and don’t have a problem with them myself. I can see how the webkit guys would prefer to toss in some nifty easily defined (I guess?) properties, as opposed to advanced/grid layout stuff, which still have their specs in flux and probably require a lot more work.
It would be nice of course if they’d implement all the latest CSS snapshot features first, but no other browser seems to actually do that either…
@Chris: No, you’re right about rotate and skew, my apologies. As for the rest, I’ve no doubt that they can be used in all sorts of clever ways, but I don’t think there’s been any call for them from developers; certainly when we’ve discussed most wanted features here on this blog, animations/transitions have never come up.
I’m not against these new features, I just think that there’s a lot more that could have been addressed first.
The issues here are two fold. We don’t want another platform/browser war, where each browser is implementing its own features for their perceived need. If WebKit think these are needed then they should work to get them standardised ASAP. We don’t want a case where a site will only work as intended in Safari as it uses these features. It is easy to see this could be the case on mobile sites, where it is the latest fad to just develop for one device/browser.
Also how and where does this overlap with SVG. It is probably possible to do much of this using animated SVG images uses as a background-image in CSS. It could also be done with a compound document, but this isn’t ideal for backwards compatibility reasons. It could become the case where properties like these are used, with SVG as the glue in the background that implements the property. There is certainly overlap here. If we are going to do stuff thatt overlap with SVG, we probably want to look into making the property/value names similar so that we can transfer knowledge across domains.
@David, very good point about CSS overlapping with SVG.
Looking through the SVG table of contents, you’ll spot many other features that could (should?) eventually find their way into CSS (filters, gradients, masks, patterns, transformations - even perhaps paths).
Personally I would support this, because it means these effects can be brought to the HTML web. But it would need to be done in such a way that it doesn’t screw up SVG. Sharing syntax, as you propose, could achieve this and even bring momentum around SVG support from web developers, as they learn about advanced effects in CSS.
You say users can disable javascript, but don’t have control over css, I don’t fully agree on that.
With javascript you mostly have to either enable or disable it, if javascript is required to do some action on the page, then you cannot disable it to hide blinky effects…
In contrast you have much more control with client side CSS.
[...] nowe funkcje webkit [...]
For example, with client side css, you can make it so ALL transitions and transforms are a none !Important; property, therefore preventing them from being used.
A similar greasemonkey script to block such things cannot be done, because each different animation script uses different methods and different variables.
The only problem i have found with webkit is that it crashes a little more with the latest nightly than it used to.
I agree that these are technically behaviors (just like the :hover pseudo class) but then again, without the :hover pseudo class we would all still be using bloated JavaScript to achieve the same effect. I say if it can be done this easy in CSS vs. JS then I’m all for it.
Transitions do straddle the border between presentation and behaviour. However the same could be argued for generated content and that has made it into the spec. I think as long as designers and developers respect the line and don’t abuse it, we’ll be fine.
Personally I don’t think that the argument that we shouldn’t bake these things into CSS because they already exist as JavaScript libraries or SVG holds much water. If that was the case you could argue that we didn’t need to put text control into CSS because it already existed in the form of the font tag.
Javascript libraries have come about because of a real and obvious need from designers and developers. The ability to do simple transitions or animations is lacking natively in CSS, so authors hacked together a simple solution using JavaScript. However there are lots of different solutions so no consistent “standard”. Despite being relatively easy, they are still not as user friendly as a CSS alternative, and consequently put some people off. Lastly, they obviously require a small, but not insubstantial download. Because of these points, I think it would make sense to bake some of the simpler animation and transition effects into the browsers.
Agree with many comments here.
Affine transforms, especially rotation are sorely needed in the Document space. From a purely layout perspective designers have been angling page elements since the constructivist days. From a UI perspective rotation and affine transforms offer lots of visual/feedback possibilities. And there is NO really nice way to deal with these in JS. The only ‘option’ would be to write in a canvas tag(or IE VML thing) and then image capture the doc element, rotate the image capture procedurally and replace the doc element with the rotated view. Also that means your functional/state driven document elements have now become a flat, lifeless bitmap.
Behavior definitions should DEFINITELY be part of CSS. You already have pseudo-states like hover, focus, etc. that sort of achieve this, just not temporally. The only thing behaviors really do is allow you to describe, on an element/class basis how states change. Visual state changes are part of style information, and the way they move from state A to state B could be thought of as style information as well. How they arrive at needing to change state is where the ‘controller’ aspect of code resides. In other words, you could use pseudostates (hover, etc.) and that would implicitly use any transitions, meaning your CSS sort of acts as a view controller. Or, you could use javascript to simple change from one visual style class to another (on some event, like roll over) and still the CSS would dictate: what the first state looks like, what the second state looks like, how to get from state 1 to state 2 visually. Your JS would be a LOT cleaner and able to focus on acting as a client-side controller.
[...] Apple’s proposed animation & transition properties are to be considered. [...]
[...] Webkit introduce more new features - CSS3 . Info [...]