2007 / January 4^th/ A little rant on Safari

It seems many web professionals around the blogsphere praise and worship Safari for it’s temporary status as superior type-renderer. While that’s all well and fine, I’d be willing to pay Apple large sums of money to ditch WebKit and it’s crappy engine in favor for my much preferred Gecko engine.

The problems with WebKit aren’t readily apparent. Many people don’t notice them, and that’s well and fine. But as soon as you start playing with line-height, margins around cleared floats and that little thing called Javascript Safari just falls on it’s face and acts dumb. Not to mention the inability to style form elements in this year of two thousand seven (Netscape 4 had this functionality in 1997).

It has without a doubt, caused me more grief and headaches than Internet Explorer 6 & 7 combined. The problem is not the quantity of bugs, but rather the quality of the bugs. There aren’t any hacks or workarounds for Safari other than downloading the nightly WebKit build, which is hardly ideal for a client fix. Sure, you can use a couple of specificity hacks, but there’s no conditional comments. There’s no position:relative. There’s just bugs without solutions.

Javascript console?

Let’s start off with my #1 complaint: The (worst ever) Javascript console. Oh what I’d give for you to just stay open for 5 minutes. Or maybe respond to console.log once in a while? This thing constantly crashes on me. I’ve ditched it in preference of Firegbug Lite for the time being (which is more stable than the built in console!) — but seriously guys, this is ridiculous. I can’t afford to have my #1 debugging tool crap out on me all the time, ignore errors, and hide text.

Javascript… please?

2nd complaint: While Javascript is fast on WebKit it seems to have all sorts of problems. Positioning offsets are completely screwed. Key events are wacko. And my latest finding: It’s implementation of window.location.hash is so bassackwards, that I’d venture to say it makes Safari the single most impeding technology to AJAX applications.

The details are slightly unimportant, but the overall jist of it is: window.location.hash is a magical little method that lets you manipulate the hash in the browser. For AJAX apps, this allows you to enabled the back-button and permalinking. Well, not for Safari.

Safari decides that not only will it lock up the browser in a forever-loading state when window.location.hash is changed, but it won’t register the getter for this property until a second or two after it’s set. What the hell? The problem for this inlies in the best way to emulate a back-button/permalink is to monitor window.location.hash and see if it’s something different than what you’re expecting. However, if this report is false, your app can’t know for sure when/if it’s changed.

Bye, bye Safari support. I do wish that Apple would stop worrying about meaningless tests like Acid2 that have no bearing on the reality of Web production, and instead focus on meaningful, everyday support like being able to set a height on an input element.

Anyways… little rant done. You may continue to your regularly scheduled programming.

1. 

   Jonathan Snook

   January 4^th | #

   stands up and claps

   They seriously need to push the latest webkit out because the current version is just too annoying. There’s been numerous stuff I’ve come across that already seems to be fixed but instead I’ll have to wait a few months for it to make it into the hands of the average Mac user.

2. 

   Justin Kistner

   January 4^th | #

   Oh, snap. Good call out on everyone being a fanboy for Safari because of the nicely rendered type. I realize that’s a big part of what I like about it. I know the JS support for Safari leaves much to be desired. I’ve loved Firefox for a while and now that I’ve discovered Firebug, it’s hard to not use it as my default.

3. 

   Nathan Smith

   January 4^th | #

   Amen. IE6 + 7 have their quirks, but at least they can be targeted specifically. With Safari, all you can do is bang your head against the desk. Please Apple, let’s get some style-ability on form elements!

4. 

   Ben

   January 4^th | #

   No idea what you are talking about - it renders sites amost perfectly, and has handled every Javascript I have thrown at it in the last two years. And surely you can use Drosera for any problems.

   The only real issues I have with it are the lack or rounding past 2 decimal points, which means some ‘em’ fractions don’t work out exactly the same.

   Compared to Firefox/Camino and its lack of proper type, (yes I know you mentioned it), crumpling when any kind of opacity is used and horrible performance, I can’t see what the problem is.

5. 

   matt

   January 4^th | #

   Wow. I’ve been waiting for this post for a while–thanks for standing up to Safari Kyle. It really is a shame that so many people champion this browser, despite its maddening bugs.

   Pretty much all IE6/7 issues are about a 2 second Google search “deep.” Safari bugs, especially the JS ones, are a nightmare. Apple’s either got to ditch WebKit, bring it to full FF compatibility, or at least document their bugs explicitly.

6. 

   Andy Beeching

   January 5^th | #

   There is a bit of a hack to serve Safari only styles…

   http://www.ibloomstudios.com/article1/

   But obviously if this is fixed in the nightly builds (don’t know myself) then it might not be worth the bother. Thanks for highlighting Safari’s short-comings though, very insightful!

7. 

   Thomas Aylott

   January 6^th | #

   Over at CrazyEgg, Safari is our favorite browser.

   FireBug in FireFox is only a little lower on my list of absolutely necessary webdev tools than TexMate, but I have no love for FireFox. I demand that an app I use so much respond to keybindings and the mouse EXACTLY the same as every other app I use regularly. That includes support for “Edit in TextMate” in every text entry field.

   Don’t get me wrong, if I had to choose between FireFox 1 and IE9, FireFox wins hand down. And maybe eventually they’ll get the app to feel more Maclike. But the new Leopard Safari junk is really making that look unlikely.

   For my personal browsing and general web use, Safari is head and sholders above all other browsers I have ever used. Safari support for CrazyEgg is much more important than IE6 support. And, personally, If it doesn’t work in Safari, then I leave and probably never return.

   However, you are absolutely right that Tiger Safari is single handedly holding back the state of Ajax apps.

   I was recently going to start doing some seriously wacky stuff with manipulating document.stylesheets rules on the fly, but Safari 2 was the only browser that couldn’t handle it (that we care about).

   However, the good news is that Leopard Safari is coming out very soon and the adoption rate for Safari users to upgrade is extremely fast, so we should have to worry for much longer.

   The webkit nightlies really do fix every problem I have been able to find. Including document.stylesheets and location.hash.

   I use the trick of adding a classname to the body tag for the browser, then I can just use rules like body.safari .buggything {whatever} and body.ie6 .everythingelse {etc}

8. 

   James John Malcolm (AkaXakA)

   January 13^th | #

   No position:relative? You’re kidding! Really?

9. 

   Ken

   January 16^th | #

   Hm, I’m actually a big fan of Firefox, it’s the sole browser I use, but at the new company I’m with, it isn’t an option to not support Safari, so unfortunately I’m stuck with it, but I really have no huge complaints other than form styling off the top of my head. We actually support IE6/7, Firefox mac/pc, Opera, Netscape, and Safari. Safari is just another browser we have to check to me. But I don’t do the AJAX stuff that you guys do, so I can’t vouch for the browser there. Anyways, to my point, I can vouch for the fact that position relative does in fact work. But for anything else your mentioning, my experience is severely lacking and I can’t say the same. Get back to position: relative’ing guys, I’m not sure what your talking about here Kyle.

10. 

    Kyle

    January 16^th | #

    In reference to position:relative, I meant the hasLayout fix for IE. Basically, giving something position:relative; will solve 95% of IE bugs.

11. 

    Pete

    January 24^th | #

    Totally on the money Kyle. They do think different down in Cupertino, they manage to create event bugs that are reproducible only 70% of the time. Real fun trying to sort that shit out with a console that logs when it feels like it. I used to think that IE was the prime cause of OMFGWTFBBQ in my life.

    Hey Apple, Safari is always the last browser to be supported in complex ajax apps (no web gtalk still in Safari) because it is so hard to get right, not because of a conspiracy theory.

    p.s. and it leaks like a sieve to boot

12. 

    James

    February 4^th | #

    “Oh, snap. Good call out on everyone being a fanboy for Safari because of the nicely rendered type.”

    As the web is made of text I would say that is more important than a bunch of gimmicky fringe technology.

    But I probably would say that, I’m a typography obsessed designer so looking at the Clearshite and messily kerned pixel type on your average windows desktop makes me want to vomit so Safari is a godsend.

13. 

    James John Malcolm (AkaXakA)

    February 13^th | #

    Ah, right, as pos:rel as a metaphor for a fix-everything solution :)

14. 

    Margaret Shear

    March 4^th | #

    Not that I agree with this logic, but I’ve always interpreted Safari’s lack of styling for forms to be based around Apple’s consideration of the form field to be a part of the browsing environment (and thus the OS). Although of course an appropriately styled form allows information to flow within context, leading innately to a smoother user experience.

    …which leads me to an observation I had recently while doing some post-launch bug fixes on a highly trafficked, AJAX-intensive website with a 11% (!) Safari user-base…

    The feedback we received from Safari users was over the top defensive. Despite the fact that they have an alternative (superior) browser easier at their fingertips, Safari users seem to devoutly cling on their browser without fail, defending it at every opportunity and demanding equal service (despite the fact that the browser itself doesn’t provide that at core). A reaction which I attribute to the lauded brand solidarity that Apple has so elegantly enforced across product lines. Little things like OS-styled form elements make users believe, albeit mistakenly, that the brand governs all…

15. 

    Santosh Rajan

    March 15^th | #

    Have a look at my cross browser key event solution.
    http://santrajan.blogspot.com/2007/03/cross-browser-keyboard-handler.html

16. 

    Kyle Korleski

    March 18^th | #

    It’s not like Gecko is without it’s demons. Some pages load excrusiatingly slow, some crash Firefox completely and sometimes, Flash disables use of the keyboard.

17. 

    MAC News » Mac - Getting to Know WebKit

    April 9^th | #

    [...] Firefox install takes much longer to render CSS and load images than WebKit. Although, some developers don’t like the way WebKit handles [...]

18. 

    MAC News » Apple - Getting to Know WebKit

    April 9^th | #

    [...] Firefox install takes much longer to render CSS and load images than WebKit. Although, some developers don’t like the way WebKit handles [...]

19. 

    ignorantcow

    April 11^th | #

    position: relative; does not trigger hasLayout.

    http://www.satzansatz.de/cssd/onhavinglayout.html#prop

    It does however, fix some z-index issues (elements disappearing, etc).

20. 

    Alek

    May 1^st | #

    client side XSLT…. I have had to completely recode months of work just to cater to a single new Safari user. Parsing XML to js objects then using DOM manipulation to render a page is so freaking great >:|

    http://developer.apple.com/internet/safari/faq.html#anchor21

    Why does that read to me as Apple saying “we don’t support it, so you don’t need it”?

    p.s. found this article while trying to get .hash to work…. sigh

Name

Email (will not be published)

Website (optional)