Your browser is not supported.

This website is optimized to work in modern browsers like Safari 3+, Firefox 4+, Chrome 10+ and IE9+. If you are using a different browser, you may experience visual glitches or other problems.

Posts tagged with Safari

I know everyone's all

?!?! over iPhone 4, and I kind of am too, but I gotta tell ya, what’s really making me go ?!?! is Safari 5. Included:

  • Safari reader, a feature that works much like Arc90′s popular Readability bookmarklet by detecting when the currently loaded web page has an article, and allowing the user to reformat the page in an easy-to-read, scrollable view that cuts the obnoxious ads out. What’s more, they actually go through every page of multi-page articles and concatenate them together for one seamless, easy reading experience. Say it with me: ?!?!

    Now, you might be thinking, “How are the content providers going to let this stand, when it could wreak havoc with their ad sales?” Well, grasshopper, its at least partly because when Safari is concatenating the pages’ content, it does a full HTTP request on each page, so the innocent kitten publishers who artificially split up short articles into 3 and 4 and more pages just to maximize ad annoyance views don’t have to worry about losing their accustomed number of ad-frame loads.

  • A smarter address field, that no longer requires you to remember exact URLs; it searches within (rather than at the beginning of) the URLs and page titles in your history like Firefox has been doing for months (perhaps years) now. I’ve got two things to say to that: hallelujah, and about damn time.

  • Never expected this, but sanctioned, easy to install, secure extensions, that can be developed in HTML, CSS and JavaScript. ?!?! Also, ROCK.

  • Then, of course, is the improved HTML5 support and the ever more feature-packed web inspector, the icing and the cherry, respectively, on the sundae.

All in all, pretty ?!?! for me.

I gotta tell ya something else. Humble pie tastes terrible. Turns out my new cheapie phone doesn’t have much going for it other than its cheapness. I can at least get calls on it more reliably than the iPhone 2G, but text messages don’t work. At all. Seriously. All my friends have stopped sending me text messages, because literally more than half of their messages to me never get there. Not get there late, which sometimes happens too, but never get to me at all.

Then there are the times when I myself am trying to send a text, and the phone (a $*@#!^% Motorola i465) reports that the message was sent, though it actually wasn’t, and I’ll have no idea that the message never got out the door until I happen to reboot my phone days later, and all the recipients are asking me why they’re getting replies to their messages so late.

In fact, if I had an actual piece of crap the size of my phone, it’d be more useful, because then I could use it as fertilizer. This…thing isn’t worth the plastic it’s made of. So, well, iPhone 4. As much as I loathe and detest the idea of giving AT&T my money again, at least I’ll get a nice phone in the bargain.

Well, I'm excited.

Apple has released a beta for Safari 4, and it looks pretty awesome. I’m really psyched about the new web inspector features and the (hallelujah!) JavaScript debugger. I’ll install it on my non-work machine soon and report back with more details.

Also, I really really want a new MacBook Pro, since my PowerBook G4 is really struggling with the only tasks I use it for: watching video and using PhotoShop. Sigh.

Update 2009-02-24 16:25—The Safari 4 beta is rocking my world. Especially the revamped web inspector. I really really wanted the Firebug-style element highlighting when you hover over an element in the markup in the inspector, and I got it. That and the JS debugger are going to change my life.

Also, recent benchmarks show that Safari 4 is, for the moment, at least, 42 (yes. 42.) times faster than IE7 and 3.5 times faster than Firefox 3 on Windows. Let the JavaScript engine wars commence! (via)

Gah!

I’ve made no secret of the fact that I’m no fan of Adobe products, especially the bloated, sluggish Adobe Reader—unless I want to fill out PDF forms, it’s of absolutely no use to me when Preview does everything I need, faster and better.

So when I installed Leopard from scratch on my personal laptop, I decided that under no circumstance would I install Adobe Reader. Problem was, every time I tried to open a PDF in Safari, I’d get a dialog box prompting me to choose an Adobe product to view the PDF in—and to add insult to injury, all non-Adobe products were not selectable.

When I obviously couldn’t choose Adobe Reader and clicked Cancel, the Safari window would just go grey and sit there, forcing me to download the file* and open it in Preview if I wanted to view it, even though Safari was supposed to support inline PDF viewing as of Tiger.

As you might imagine, this drove me ABSOLUTELY BATTY. Gnashing teeth, foaming mouth, shaking fist, the whole enchilada. ARGH. <pause for deep breathing exercises />

Anyway. This state of affairs was mildly irritating, so I was pretty happy (okay, okay, I did the Snoopy dance) when I found out how to fix this problem this morning. You need to do two things:

  1. Go to /Library/Internet Plug-Ins and remove AdobePDFViewer.plugin.
  2. Open up Terminal and type
    defaults write com.apple.Safari WebKitOmitPDFSupport -bool false

    at the prompt. This ensures that Safari will open PDFs rather than forcing Preview to.

What I can’t figure out is how the PDF viewer plugin got installed on a vanilla Leopard installation. I suspect it happened when I installed Photoshop. Sneaky bastards. (cf. reference 1, reference 2)

* That is, if the referring web page didn’t redirect through some dumb download script, but don’t even get me started on that.

How to fix the bookmark syncing bug in Safari on Mac OS X 10.5.2

Ever since I installed Leopard on my personal laptop, I’d been having problems syncing information across my two computers (one of which still ran Tiger) using the .Mac sync feature. Keychain sync didn’t seem to be working at all, and the others were spotty.

So when I finally upgraded my work laptop to Leopard a couple of weeks ago, I thought my problems would go away. Not so much, in fact. I was still having problems, and they had actually gotten worse. My personal laptop, with a fresh install of Leopard (as opposed to my work laptop, which had just been upgraded) stopped syncing altogether; the Sync application kept crashing.

After some reading around, I deleted the sync history by removing the Local folder from ~/Library/Application Support/SyncServices, but while that helped, it still didn’t seem to solve my problem fully. Now keychain and mail account syncing was working beautifully, but Safari bookmark sync wasn’t working at all.

And now, thanks to Daring Fireball, I know how to fix it. Woo!

Talking shop: software (part 3)

Browsers and browser-plugins
First, let me explain a bit of my strategy. As I said, I code to the standards and then hack for browser compatibility. My first line of defense is Safari/Firefox, and once I have my styles/layout working in both of those, I move on to IE6. I am not supporting IE7 at this time, because our clients run mostly IE6 and have no immediate plans to upgrade.

The browsers alone are not enough, though. Each needs some kind of enhancement or companion tool to help me debug my CSS code.

  • Safari + XyleScope: Safari you know about, and XyleScope, you probably don’t. The latter is the only application of its kind out there, and I really wish it wasn’t; I wish there were versions of it for every browser and every operating system. What it does is use the Safari rendering engine to render any URL you give it, and dissects the styles used in every component. The killer part of this app is that you can select any item on the page by clicking on it, and XyleScope will give you the complete breakdown of styles that apply to it (and most importantly, in which order), its place in the markup hierarchy, and a graphical representation of its box model rendering, the last of which is sometimes priceless. I’d love love love to get a tool like this for IE, the browser with the most weird box model-related rendering bugs, but there just isn’t one that does that for me (more on this later).

    XyleScope does have some shortcomings, though. One is that it only uses the Safari rendering engine, which gives it limited usefulness when testing cross-browser compatibility. The second—and crucial—one is that it doesn’t deal with generated elements very well. So when I’m testing with my webapp running, and much of the content is generated by my server-side code, XyleScope gives up.

  • Which is mostly the reason that I use WebKit, the open-source, next-generation, beta version of Safari. It’s got two important advantages over Safari, the first being that it lets you style form elements, which Safari does not (which blows). Secondly, it’s got this awesome (seriously, I can’t say enough about it) “inspect element” feature that will inspect any element in your final page, and give you all the goods on it, from place in the markup hierarchy, final computed style, and a listing, like XyleScope’s, of what styles from your stylesheet apply and in which order. On top of that, it’s got a lovely clean interface that is a pleasure to use (except for the obnoxious scrollbar behavior in the markup hierarchy section, but I’m hoping that’ll be fixed soon).
  • Firefox + FireBug: Firefox is my control group. Besides Safari/Webkit, it’s probably the best widely-used browser with regard to standards support. If my site works in Firefox, it’ll (mostly) work in every other browser. As I said, debugging is crucial to my work, so I use the immensely useful FireBug plugin to help me inspect generated elements when testing. Feature-wise, it’s almost identical to the inspect element functionality in WebKit, but it’s a little less stable and doesn’t have as nice of a UI; and really, you can say the same of Firefox in general in comparison to Safari/WebKit. That said, FireBug is an invaluable debugging tool.
  • Last but unfortunately not least, Internet Explorer and the IE developer toolbar: IE6. What can I say? Like any other web developer who has ever tried to program for it, I hate it. But most of my users use it, so what can I do? Since most of my debugging takes place in IE6, it was vital that I had some sort of debugging tool, because XyleScope isn’t available for Windows. Enter the IE developer toolbar. Much like the inspect feature in WebKit and FireBug for Firefox, this helps you select elements on your rendered page and inspects them, HTML, CSS and all. My very favorite part of this is the tool that allows you to size your window to any of a set of common resolutions, so you can see just how much your users can see, and design accordingly. I couldn’t live without this, as it makes my job that much easier.