I've always found it a bit inconvenient to have the scrolling panes at the top of the window when browsing the documentation on ruby-doc.org, especially when using my laptop’s built-in display instead of an external display. When using an aspect ratio of 4:3 or 16:10 (which is what I'm using most of the time) the limiting factor is height, not width, and the scrolling panes at the top of the window just make vertical space even more scarce.

What’s worse is the classes and methods lists are very long, and it’s difficult to use such a short scrolling window to find what you’re looking for. When scrolling through the list, I often fly right past the item I'm looking for.

The guys over at 37signals are doing it right with the Ruby on Rails documentation. By having the scrolling panes over on the left, they provide more space for the actual document to be displayed while at the same time allowing more items in the large lists to be displayed at once, thus dramatically decreasing search time.

To solve this problem, I created two small HTML files that I keep right on my desktop. One is for 1.8.6 core and the other for 1.8.7. Whenever I need to browse the Ruby docs, I just pop open a new tab in my browser window and drag one of these files in, depending on which one I need to browse. I found them to be very useful in my everyday workflow, so I thought I'd share them here.

Download

It’s a good day for software releases. Firefox 3.5 is officially ready for prime time. Check out these notes from Mozilla for a rundown on all of the goodies developers can expect in the new version. There are quite a few good ones.

PHP 5.3 is out. Really looking forward to finally being able to use late static bindings, closures, and the new i18n extension.

Jakob Nielsen:

Most websites (and many other applications) mask passwords as users type them, and thereby theoretically prevent miscreants from looking over users' shoulders. Of course, a truly skilled criminal can simply look at the keyboard and note which keys are being pressed. So, password masking doesn’t even protect fully against snoopers.

More importantly, there’s usually nobody looking over your shoulder when you log in to a website. It’s just you, sitting all alone in your office, suffering reduced usability to protect against a non-issue.

I love how he calls it a “non-issue” … he’s absolutely right. (Via John Gruber.)

An excellent resource for web typography tools. I don’t think I would go so far as to say that you can’t live without all 21 of them, but you should be able to find some good tools to help you with your web typography needs.

At my last place of employment, my company-issued machine was a Windows laptop (a Dell…don’t get me started). In my search for a code editor for the Windows platform, I was naturally drawn (mainly by lack of decent alternatives) to jEdit.

Over the months that I was using jEdit, I grew accustomed to using the “Strip trailing whitespace on save” feature. I liked how it cleaned up all the extraneous characters, keeping the code as lean as possible. At night when I would sit down to code with my weapon of choice TextMate (Mac only), I found that I really missed this feature.

TextMate does have a command in the Text bundle called “Remove Trailing Spaces in Document” that will strip all of the whitespace from the end of all lines in a file, but it then takes a separate Cmd-S to save the document.

So I combined the two commands into this TextMate macro and bound it to Cmd-S. Enjoy.

Download

Author Michael Tuck presents some well researched font-family “stacks” that should be a good starting point for your own tweaking. The basic idea:

I've been considering the idea of font stacks—using the well-known font-family CSS property—to list as many different fonts as possible in order to optimize the web site experience for a maximum number of users.

He includes Windows, Mac, Linux, and Adobe fonts in his stacks, starting with the least likely and gradually degrading to the most common ones in an attempt to capture as wide an audience as possible. Definitely worth a look, at least until that glorious day when we can all safely rely on Web Fonts to get the job done.

Excellent article by Objective-J author Francisco Tolmasky in response to John Resig’s original article on JavaScript language abstractions. Although I'm a huge fan of Resig’s work and generally believe him to be right on with his evaluation of things, I tend to side with Tolmasky on this one.

In case you have been living under a rock and haven’t yet heard of Objective-J or the Cappuccino framework, check out the first real world demo, 280 slides.

John Resig:

The vast majority of web developers have never filed a bug report with a browser vendor — or even used a nightly version of a browser — which is a shame. If you think about it there are few who are more qualified to assess what is going wrong in a browser than those who spend every day developing for them.

I'm especially surprised when I see professional developers not filing bugs with browsers, or testing on nightlies. Since one of the primary tasks of most developers is to paper over cross-browser issues it becomes in their best interest to see the number of bugs reduced (and making their job dramatically simpler).

An excellent resource for every web developer who cares about having a healthy web and making his own job a little easier.

An interview with CSS master Eric Meyer on the upcoming (we hope) CSS3. For those of you who may not be following its progression, you may be interested to know that CSS3 is not one great big spec, as was its predecessor CSS2.

It really means there is no such thing as “CSS3” the way there was a CSS2. There’s no great big monolithic specification called CSS3. There’s just a bunch of parallel efforts, some of which move more quickly than others.

These parallel efforts have been classified as “modules”, each of which progresses on a separate timeline. What this basically means is that the selectors module may reach official Recommendation status sooner than the multi-column module, for example.

Ultimately, this should make it easier for browser vendors who are anxious to adopt CSS3 but may be intimidated by the enormity of the task by breaking it up into more manageable pieces. However, Meyer believes that it has caused a bit of lag in module development time.

My real point is that because of how things have gone, it’s hard to measure CSS3 adoption against what came before. I do think the split caused an overall slowdown in the development of the specifications. No way to prove that, of course, but that’s the feeling I get.

Eric also discusses the effect that CSS has had on some of the major JavaScript frameworks (in particular jQuery) and how developers like you and I can get help to promote the CSS3 effort. A great read for anyone interested in the future of CSS.