This has always been a mystery to me - how to tell Safari I want to use two personal certificates, one for each site. Until now I’ve trusted Firefox with this matter. But I wanted to give Safari another chance, now that version 3 & leopard are out. And guess what - it can be done! I can now successfully acces both, Klik NLB online banking and e-Student, student’s portal of my university. To share the knowledge, here’s a short tutorial on how to do this, or at least how I did it. This is for Safari on a mac of course, I have no clue how to do this in Windows.

By default, prior to importing any certificates, Safari will fail to open https://klik.nlb.si/ and https://estudent.uni-lj.si/ won’t recognize you.

My first problem was a corrupted keychain. I’ve imported the keychain from my old system to Leopard and it seemed a bit buggy ever since, always asking me for my password, regardless of selecting “always allow”. But then I found the Keychain First Aid (It’s in the Keychain Access, in it’s application menu - the one that reads “Keychain Access”). I tried verifying my Keychain, but it failed due to login keychain not being in my home directory. Repair fixed this. Keychain seemed to actually remember things I told it to remember now.

But even after this fix I couldn’t get klik to load properly, so I just deleted my whole login keychain. You probably don’t have to do this - just remove any certificates that could play a role in the whole process. You’ll probably ind them in the login and System keychains. I also deleted Safari caches here. Just in case.

I had previously exported both my certificates via Firefox into .p12 files. So now I imported the one from NLB into keychain - Open Keychain access, click on the login keychain, then File -> Import items…

I closed Safari, opened it again and navigated to https://klik.nlb.si/. I was greeted with their certificate. I chose to always trust it and also always allow Safari to access my personal certificate from the keychain. Klik recognized me and I could log in.

Next, I imported the sigen-ca certificate (for e-student) into keychain, navigated to https://estudent.uni-lj.si, again clicked “always trust” when presented with a certificate, but I didn’t seem to get recognized. My guess is, Safari was reading the wrong one of my personal certificates.

So here comes the key part - In Keychain access, I right clicked my nlb personal certificate (the one with my name in it), and selected “New identity preference…”. Under location, I entered “https://klik.nlb.si/” and chose the correct one of the two certificates. The klik certificate is “Dusan Smolnikar”, while sigen-ca reads “DUSAN SMOLNIKAR”. Then I did the same for my sigen-ca certificate, where I entered “https://estudent.uni-lj.si” and selected the other personal certificate. I’m not sure wether the lack of trailing slash does anything, but I’ve read somewhere it makes a difference. Experiment if it doesn’t work at first. What I did here, is I matched the certificates with the correct urls, so Safari doesn’t have to guess.

Now, closing Safari and opening it again, klik and e-student both recognized me and I could log into them. I’m happy.

When Safari 3 was released as a beta about 2 months ago, it brought some cool features. One of them were the so-called “Resizable Text Fields”. What it means is that any textarea element can be resized by dragging its lower-right corner. This feature comes in handy when you have more text to input than the website author predicted. You can resize your field to avoid scrolling it. Great.

But as many web developers are aware, more freedom to the user means more worries to the designer. By resizing the text field, a user can affect the look of a website. Of course, a page should allow some customization, but what about extreme values (too small, too wide, …)? Will they make my website fall apart? Well, the good developers of Safari thought of that. Therefore textareas in Safari respect the CSS2 minimum and maximum widths and heights. For example, when a max-width of 300px is set, a user will still be able to resize the text field, but no wider than 300 pixels. Neat.

Another nifty thing we can use is the CSS3 resize property. This allows us to limit the resizing of an element (in this example, the textarea) to horizontal, vertical, or none. So by applying textarea { resize:vertical; } the user will be able to resize textareas vertically, but not horizontally.

A word of advice though - Resizable text fields were introduced to help the user. Even though we can prevent resizing all-together, it’s usually not a smart thing to do. Users like to use such features so don’t take this away from them. Do limit resizing within some reasonable values if you think it’s necessary, but don’t take it as an excuse for bad element positioning.

Yesterday, Apple released it’s Safari 3 beta for OS X and Windows. I’ve been playing with it and it seems quite nice. Windows users did report some problems (and even more problems).

Anyway, I’ve been looking at the web standars project page just now, and noticed the menu looks rather weird in safari. So I’ve investigated a bit and found out it uses text-shadow. So I made a little test case. See how it renders in Safari. Pretty neat, ha? I don’t think any other browser supports this currently. Firefox 2.0.0.4 and Opera 9.00 sure don’t, but I’ll check a few newer versions later today.

update: Opera 9.2 and Firefox 3.0 alpha fail to render text-shadow

update #2: It seems this is old news. text-shadow has been around since safari 1.1 and is said to be working in konqueror also. But what are the big guys (firefox, opera, ie) waiting for?