I get a fair number of e-mails asking if the Font Size switcher in my sidebar is a WordPress plugin or where to find it. I built it based on this tutorial at A List Apart.
Sorry Safari users, Safari chokes hard on this technique. I recommend using a better browser.
I also added this info to my About page, on the off chance someone actually thinks to look there. 
I’d be happy if you could make this a wordpress plugin. Still have no idea how to make it on my blog.
C’mon now, the slam on Safari is probably not needed. You had a choice: explain why it doesn’t work on Safari (even as simple as “poor _______ support”) or to make an uninformative slam. I’m disappointed that you chose the latter.
And yes, I like Safari. I’ll leave it at that.
A search on Safari on this blog will net you a list of Safari specific bugs (for a while it was a new show-stopper with every new release) that I’ve had to code around in my software. I’m not a fan.
If I have the font switcher enabled in Safari, it freaks out hard. You probably have the debug menu enabled in Safari, tell Safari to masquerade as a different browser and visit here. You’ll find that you can’t click some links, stuff flickers all over the place, and at times flies around on you.
I don’t know what the actual Safari bug is, several days of debugging it netted no useful info to me.
I changed user agents (Mozilla 1.1) and the font switcher works quite wonderfully in Safari 2.0.4. I realize you may primarily be speaking of older versions of Safari, but in this case, all appears well. I doubt you’ll require a movie screen capture to prove it, but I’d be willing to make one to show you. I also clicked around and spent some time on your blog and encountered nothing I’d consider weird or unusual.
I did do a search on your blog at your suggestion, and found very, very few Safari bugs. In fact, I found more posts saying something worked on Safari than not (often while you were testing IE workarounds). I stopped searching when I got back to Safari 1.2 on about the fourth page of results (in the year 2004), as we’ve had Tiger for quite awhile now already.
Safari 2.0.4 here.
I’m using Safari here and once I trick your site into showing the widget, it works fine.
I think you’re imagining things.
Safari 2.0.4 here, works fine w/ user agent set to Moz 1.1
I also think the “better browser” is a bit unnecessary. The font rendering alone in Gecko browsers is enough to keep me in Safari/WebKit powered browsers (like NetNewsWire, where I am now).
I code websites too, including internal applications (some of which make heavier use of javascript than others), other than the lack of being able to add script tags using the dom (and have them parsed), there’s a grand total of one work around (small, one line) for Safari.
I’ll re-enable it for Safari and we’ll see what happens. I hope it doesn’t cause problems. In my testing before I released the site (Sept. 2006 version of Safari), things did not go well.
I’m glad Safari continues to improve, but based on my experience with it I stand by my recommendation above.
I almost forgot, the old version of my site also had this issue in Safari. I took the “disable this feature in Safari” check out of the code when building the new site in the hopes that whatever bug had caused the problem was fixed, but it still barfed on it at the time (so I had to put it back in).
Here are the old posts:
http://alexking.org/[...]tyle-options
http://alexking.org/[...]ari-problems
http://alexking.org/[...]ily-disabled
http://alexking.org/[...]cher-is-back
Each of those four links are from April, 2004. The world – and Safari – have moved on quite a bit since then. Your recommendation appears to be outdated by about 30 months.
Those 4 links from 2004 describe the problem with the previous style switcher and Safari – the same problem I saw this fall while developing the new site.
And just because new versions of Safari have been released that fix some of these bugs doesn’t stop the old versions with these bugs from existing out there. I know, I get the reports from users of my web apps.
You seem intent on placing the burden of proof for this on me, however I don’t feel this burden.
I could go into detail about the “accesskey on buttons” issue that caused Safari (and any app using WebKit) to crash, or the hidden form that would spike the CPU to 100 percent and require a Force Quit, or the myriad of issues (particularly with keypress capture) we ran into while building the FeedLounge interface, but instead I will simply repeat that I stand behind my recommendation.
You’re welcome to continue to express your opinion here (and it’s nice to see a developer champion Safari), but I hope you don’t mind if I express mine as well.
Vincent wrote:
If someone would like to sponsor the development, I’d be happy to try to put something together.
[...] is challenging me to give Safari another chance, I’m going to take him up on it. I’m setting Safari as my default browser1 for the rest [...]
I hope too that you can make a plugin for this very very nice tool, but now I will try to take inspiration from your code and the tutorial you posted and I will try to do my own best.
ciao