Results tagged “Safari” from Bill's Words

Safari 5 has a neat feature called “Reader.” It’s almost perfect as it renders the content of web pages in a nice, distraction-free, clean, readable format. Pressing the space bar makes the text scroll up very nicely, with subtle accelerations and decelerations, one screenful at a time, and scrolls slowly enough that your eye can follow the text you are currently reading. Excellent.

But Reader, like webpages, documents, and every other scrollable document-handling application that I know of, has one problem: scrolling to the last page. When you scroll to the last page, it doesn’t advance “a full page” as it did for the previous page advances. Instead, it only advances enough so that the bottom of the text ends up at the bottom of the window. This behavior means that your eye, used to following the current point in the text to the top of the screen, is jerked to a stop (if your reaction time is quick, which mine isn’t) or it keeps moving and is left to search out the current point in the text—jarring in an otherwise-pleasant reading experience. I think that full page advances allow your eye to see the top of the window and “know” that the scroll will stop; I have no trouble following the text and stopping at the right place for full page advances.

So the tweak I’d like to see is for the bottom of the last page to scroll up with the last, fractional page, so that the scroll amount is the same for all pages, including the last. Right now, scrolling to the last page in Reader of the review of the Magic Trackpad on Ars Technica looks like this, even though I’ve already read to the line that begins “Magic Trackpad. Nobody needs…”

Current Reader Last Page.jpg

And this crude mockup is what I’d want it to look like instead:

Desired Last Reader Page.jpg

In this way, the scroll amount is the same, no matter how much text is left in the article, and my eye could track upwards the same amount with each press of the space bar.

A nice side effect of this change is that the reference point for “a screen’s worth of scrolling” wouldn’t change throughout the Reader session, so that when I use shift-space bar to go back up, I see the same text in the same location with each screen’s worth of scrolling. So the text that was, you know, “just up at the top of the screen about halfway back in the article” is still, you know, “just up at the top of the screen about halfway back in the article.”

Otherwise? I love Reader. Nice one, Apple.

When it’s a “><”, of course!

Here’s the text of the original function in a standard html file. It’s properly enclosed in tags, and other parts of the script work, so don’t get your panties in a wad.

      function getArgs() {

      var args = new Object();
      var query =;
      var pairs = query.split("&");
      for(var i = 0; i < pairs.length; i++)
      var pos = pairs[i].indexOf('=');
      if(pos == -1) continue;
      var argname = pairs[i].substring(0,pos)
      var value = pairs[i].substring(pos+1)
      args[argname] = unescape(value)

      return args;

This code is part of a custom app that my company uses, so I won’t publish the whole thing. (It’s available upon request—let me know and they’ll send it to you.) But suffice it to say that this code can be pretty easily found on the web, too. Just Google “getargs() javascript” and you can find numerous sources for it.

As best I can tell, Safari refuses to execute this code, instead returning a null value or something to the caller. When I look into the Web Inspector window to see what’s going on (because I’m curious like that), this is what I see:

Odd GTLT Comparator.jpg

Look at line 121 carefully. That’s an odd comparator, isn’t it?

I saved the original source of that page and put it onto my machine, which has only the proper “<” comparator in it, and verified that the Web Inspector window does indeed show me the odd “><” comparator, highlighted appropriately as if it were comparing i to < pairs.length.

I sent off a bug report to Apple using Safari’s feedback. But I’m not holding my breath.