Recently, I’ve had the pleasure of building the UI for a client program using Webkit. Access to all the CSS3 features has been great as well as completely liberating from the constraints of IE compatibility.

WebKit offers another great feature: the -webkit-transition property to animate transitions between different style declarations. One obvious application is fading an element in and out which requires a CSS property which I’ve long since relegated to the pile of “nice, but not so applicable” properties: “visibility.”

here’s an example:
.module {
visibility: hidden;
opacity: 0;
-webkit-transition: opacity 0.2s ease-in;
}
.module.display {
visibility: visible;
opacity: 1;
}


Why not just use the display property? Because even if display is “none”, an absolutely positioned <div> will block click and other mouse events from being detected by elements below (in terms of z-index) the hidden <div>.

I’ve just spent an hour and a half upgrading to WordPress 2.9.1. Why did it take that long? Well, their database upgrade assigned the wrong collation to the fields in the database, rendering all the double-byte characters in my posts as ???. Very annoying and a pretty major oversite for such a widely adopted piece of software.

After searching around the WordPress Forums, I found this post which blames the Gengo plugin for these encoding problems: [Plugin: Gengo] characters showing as ?????.

What was the solution? Open up phpMyAdmin. and:

1. Change the collation for each table to “utf8_general_ci”

2. Change the collation of the offending fields to “utf8_general_ci”

It’s a pain, but it’ll solve the issue. Hopefully, the next WordPress version will solve this problem.

Well, I signed up for the Versions app beta and finally got it about a bit over a month ago. I installed it and then minutes later, I clicked it off, fired off an email to their feedback address and removed it from my dock, expecting never to use it again. You see, the problem was I couldn’t get it to work with my Site5 SVN setup. I received an email back from the beta team and now it’s working and back in my dock.

Version’s website mentions a feature: svn+ssh:// key pairs are unnecessary. However, the first time I tried to connect to my repository on Site5, I got an error message “Connection closed unexpectedly.” I tried many different login permutations, but nothing worked. And so I was resigned to looking into other more painful Mac SVN clients like SvnX.

The email today alerted me to newest beta update and so I downloaded the update and tried again. No beans. Following a tutorial on setting up SVN on Site5 I was still getting the same error. There was still no way to point to the private key I had set up. After re-reading the Versions website (I really hope some documentation is on the way), I realized I was going about it the wrong way. Assuming you’ve already setup SVN on your Site5 account, here’s the correct way to connect to your Site5 SVN repository without creating key pairs:

Location: svn+ssh://[Site5 username]@www.[domain name]/[path to repository]

Example: svn+ssh://username@www.versions.com/home/username/svn/project
Username: [Site5 username]

Password: [Site5 password]