This post is targeted for Finnish audience, although it’s written in English.

Last year during Full Frontal Javascript Conference at November I got an idea of arranging some kind of event for (frontend) web developers in Finland. The sad truth is that we don’t have such events at all.

There’s at least medium amount of very talented web developers living in Finland. However, we get together very occasionally, mostly in events that aren’t related to web development at all. Therefore I have a strong opinion we should form a more concrete community which I’m already named as “Frontend Finland” :)

The idea of arranging such event got buried. But couple weeks ago, a colleague of mine (at Futurice) mentioned he had the very similar idea about arranging a JavaScript event in Helsinki, Finland.

So we made a quick review about potential topics to be discussed. Actually I had already made a short list with an ex-colleague from Fruugo.

The event itself, as a first event ever, would be very modest and unofficial. And the “official” part wouldn’t last longer than two to three hours, containing no more than four presentations about different topics.

The event would be:

• free (or very minimal charge for covering running costs),
• arranged on late September or early October,
• located in Helsinki,
• gathering around 40 to 80 enthusiastic web developers,
• contain short sessions (15-30 minutes) of presentations,
• social event to emphasize we’re not alone :)

The event is in very early planning stage and I’m about to contact potential developers, asking them whether they would like to contribute with their know-how, sharing their experiences.

The big question is: what kind of topics you would like to hear about? The preparatory topics we discussed of were: current state and general knowledge about DOM scripting, overview to some JavaScript framework (most likely jQuery), using JavaScript for building rich web applications or CMS’s, using JavaScript in mobile web development and “bubbling under” trends like WebGL or server-side JavaScript.

In addition, if everything goes well and we get such event arranged at all, there’s definitely place for another similar kind of event about frontend web development in general. That event would cover topics about HTML5, CSS3 and the status of latest modern browsers (such as IE9 or Firefox 4). This event would take place somewhere in Spring 2011.

And if you’re able to contribute in any way, please contact me via e-mail.

General Web Development and Web Design

HTML & CSS

Javascript, jQuery and Other JS Frameworks

Hacking and Security

This article is also published in Finnish, titled as “CSS3 Transitiot – olemmeko jo perillä?” at gfx.fi.

Like mentioned above, the whole topic has been split in two parts. The first part is offering a general overview in current status of CSS3 Transitions. Second part is called “CSS3 Transitions – Problems and Solutions”, which will explain in details how CSS3 Transitions behave in different browsers.

The first part of the article contains following sections:

• Getting Started – what you must have on your workstation
• The Basics of the Basics – what you should know about transitions
• The Basics – what you must know about CSS3 Transitions (demo section)
• Conclusions – are we there yet?
• External Resources – places where you must visit after reading this article

Getting Started

To get started, you’ll need a browser that supports CSS3 Transitions:

• Apple Safari (supported in Safari 3.1 and later, and in iPhone OS 2.0 and later.)
• Google Chrome
• Mozilla Firefox 3.7 alpha (also known as Minefield)
• Opera 10.5x (also supported by Opera Mobile 10 beta 2)

What about Internet Explorer?

At the moment it’s announced that Internet Explorer 9 isn’t going to support CSS3 Transitions. The best support for IE Transitions and Transformations can be achieved with Matrix Filter.

Additionally, I recommend reading an article titled Cross-Browser Animated CSS Transforms — Even in IE, written by Zoltan “Du Lac” Hawryluk who is the author of cssSandpaper.

The Basics of the Basics

Unfortunately, there’s no “one rule to rule them all” for transitions. Actually every browser has their own proprietary properties. Fortunately the syntax for values are consistent.

What can be transitioned?

Most properties can be transitioned and therefore I see no reason to list them here explicitly. However, there are some difference between browsers and the most obvious exception is that Firefox 3.7a doesn’t support transition of transformations at all.

The property values for transitions

Transitions have four values to declare at maximum:
Shorthand:

-webkit-transition: property_name duration timing_function delay;
-moz-transition: property_name duration timing_function delay;
-o-transition: property_name duration timing_function delay;
transition: property_name duration timing_function delay;

You also can declare every value explicitly:

(Target) Property:

-webkit-transition-property: property_name;
-moz-transition-property: property_name;
-o-transition-property: property_name;
transition-property: property_name;

Duration:

-webkit-transition-duration: duration;
-moz-transition-duration: duration;
-o-transition-duration: duration;
transition-duration: duration;

Duration (like delay) can be entered either in seconds (eg. 0.5s) or in milliseconds (eg. 500ms). It’s important to note that if the value is entered without suffix, transition will not work at all.

Timing (of motion):

-webkit-transition-timing-function: timing_function;
-moz-transition-timing-function: timing_function;
-o-transition-timing-function: timing_function;
transition-timing-function: timing_function;

Available timing functions:

• cubic-bezier(cp1_x, cp1_y, cp2_x, cp2_y)
• ease – equivalent to cubic-bezier(0.25, 0.1, 0.25, 1.0).
• linear – equivalent to cubic-bezier(0.0, 0.0, 1.0, 1.0).
• ease-in – equivalent to cubic-bezier(0.42, 0, 1.0, 1.0).
• ease-out – equivalent to cubic-bezier(0, 0, 0.58, 1.0).
• ease-in-out – equivalent to cubic-bezier(0.42, 0, 0.58, 1.0).

Delay:

-webkit-transition-delay: delay;
-moz-transition-delay: delay;
-o-transition-delay: delay;
-transition-delay: delay;

Delay (like duration) can be entered either in seconds (eg. 0.5s) or in milliseconds (eg. 500ms).

In general, it’s good to declare transitions on default state selectors without pseudo classes. This will cause transition played in both direction, eg. when hovering.

Remember, you have to enter all the properties four times before being cross-browser compliant. Therefore it’d be best to use shorthand codes for keeping your CSS code clean.

The Basics

Now, I’m going to demonstrate some of the transitions. You must either hover or to click activation buttons for displaying transitions.

All the code examples below has no browser proprietary format written – this is for saving space.

Basic Transition: Dimensions and Scaling

I’ll start by demonstrating the basic transition. It also demonstrates the difference between width+height and scale transform.

#widthHeight	{transition:all 500ms;}
#widthHeight:hover	{width:200px;height:200px;line-height:200px;}

#scale	{transition:all 500ms;}
#scale:hover	{transform:scale(2.0, 2.0);}

As you can see, width and height increases normally while scaling is treated almost like absolutely positioned element. On scaling, the transform-origin is set to middle while modifying width+height origin is on the top-left corner.

Transition with Timing Function

Below there are two blocks rotating; one with linear timing-function and second one with ease.

#rotateLinear	{position:relative;clear:both;left:0px;
		transition:all 2500ms linear;}

#rotateEasing	{position:relative;clear:both;left:0px;
		transition:all 2500ms ease;}

#rotateLinear:target	{left:200px;
			transform:rotate(360deg);}

#rotateEasing:target {left:200px;
			transform:rotate(360deg);}

Activate LinearActivate Easing

As you probably noticed, the movement is different but both transitions ends at the same time (after 2500ms).

Transition with Delay

Delays are useful in some cases. And they’re very easy to implement in transitions:

#bgColorDelay	{background-color:#12142B;
		transition:background-color 500ms linear 800ms;}
#bgColorDelay:hover	{background-color:#336699;}

Transition Chaining

Transitions can also be chained. This doesn’t come as a default feature, but chaining can be achieved by adding delay between transitions:

#widthHeightOpacity	{transition:width 500ms, height 500ms linear 500ms, opacity 500ms linear 1000ms;}
#widthHeightOpacity:hover	{width:200px;height:200px;opacity:0.1;}

This has one caveat: transitions are displayed in same order no matter whether the element is hovered or it’s in default state. And that makes no sense. Therefore we need to reverse the declarations (compared to earlier examples) as following:

#widthHeightOpacity	{
	transition:width 500ms 1000ms, height 500ms linear 500ms, opacity 500ms linear;
}

#widthHeightOpacity:hover	{width:200px;height:200px;opacity:0.1;
	transition:width 500ms, height 500ms linear 500ms, opacity 500ms linear 1000ms;
}

Is There Anything Else?

Well of course, there might be something else I haven’t noticed at this point. But what I’m trying to emphasize is that transitions are rather simple to implement (although they require a bit extra work for cross-browser compliancy).

Conclusions

Are we there yet? Yes, we’re over halfway there. Transitions in general are very cool in proper use.

However, I’m personally still bit skeptic with CSS3 Transitions: at this point, you can’t rely on them and you must do cross-browser testing thoroughly. I’ll cover some of the problems at the following part of this article series. And I’m also going to briefly compare CSS3 Transitions with jQuery Animations.

If you’re dealing with a platform solely running on WebKit (like iPhone or Adobe AIR) then go ahead and enjoy the full power of both CSS3 Transitions and WebKit animations.

External Resources

Here are some good resources provided both by browser vendors and other external authors. I strongly suggest reading them for adopting transitions and other CSS3 techniques.

• Safari CSS Visual Effect Guide: Transitions
• Mozilla CSS transitions – MDC
• Opera: CSS3 Transitions support in Opera Presto 2.3

• CSS3.info
• CSS3, Please! The Cross-Browser CSS3 Rule Generator
• CSS Fundamentals: CSS 3 Transitions | NetTuts+
• CSS Transitions 101 | Webdesigner Depot
• Going Nuts with CSS Transitions | 24 ways
• Safari CSS Visual Effect Guide: Animations

Comments?

Feel free to comment any part of the article. Additionally, if you know good resources about CSS3 Transitions, go ahead and contribute.

General Web Development

HTML & CSS

Javascript, jQuery and Other

Server-Side Development and Frameworks

Security and Hacking

Last week at work, I encountered a very peculiar problem in Internet Explorer. There were several IE-related bugs reported in a certain part of the service. However, I couldn’t reproduce them and I expected these bugs had been fixed during other updates in the code..

..until it suddenly happened. All the tested versions of IE’s (6, 7, 8) started reporting either error “failed” or “unexpected error”, pointing to jQuery’s code. And there worst part was that error occurred occasionally, although nothing was changed.

In this case, there’s jQuery 1.3.2 in use. Error message didn’t help and the line it was pointing to, belonged to a internal / helper function into jQuery.

At first, errors disappeared after some fixes I expected to resolve the situation. But, like I mentioned earlier: these errors were occasional.

I didn’t have anything that could have helped me at least a little on tracking this problem (later I found not even unit tests would’ve solved this – although it’s not an argument why I didn’t have unit testing for javascript). So, my only choice was trying to isolate the problem function by function, line by line.

Ultimately I found that all the errors were caused by event handler bindings made with function $.fn.live(). I couldn’t blame the selectors being too unprecise, although I reduced the amount of troublemakers by fine-tuning them. In addition, I found that wrapping them in setTimeout() with small delay would have possibly fixed the problem. Also, IE6 had the most problems, while IE7 started to feel stable.

Most likely there was something going on with perfomance. However, after all this I wasn’t in a mood to expect these problems were completely solved. So I ended up binding event handlers with $.fn.bind() whenever something was dynamically added. It meant more lines of code, but it also meant that no errors were occurred ever again.

The point of this article can be put in one sentence: if you receive an error with message “failed” or “unexpected error” from jQuery and this happens only in Internet Explorer, comment out every possible live() binding and try again.