Today is the big day!  Obviously, all of you are aware that Firefox 3.0 was released at 1:00 pm, EST today, and that Mozilla was eyeing the Guiness Book of World Records record for most downloads in a single day, right?

Sure!

Well, the point is, if you haven’t yet: get Firefox.  As a Mac user, I am blown away by the improvements in speed and memory management in 3.0.  I honestly did not enjoy the Firefox 2.0 Mac experience, and used Safari as much as I could.  Windows users on the other hand, should already be using Firefox (boo, Internet Explorer), and 3.0 should be an upgrade.

The Firefox download site was down earlier today (did they not expect the traffic?!?) but we managed to get access by the end of the day.  I couldn’t wait that long and used BitTorrent to download what turned out to be an Italian version of 3.0 (I’ve sense switched back to English).

I’ve already stated my initial reactions.  The new look is great, too, it really opens up some more screen real-estate, which is something we always wrangle with as designers.

Compatibility-wise, there are updates availble for the Google Toolbar, Web Developer Toolbar, and the YSlow Firebug extension.  Firebug itself has a beta that works with 3.0, but the Firebug site has been down for the past few days.  You can find a mirror that has the code and a list of Firebug mirrors here.

Other than that, I’ve been enjoying the new experience.  I’m sure other AWP-ers will chime in over the next few days.

Did I mention boo Internet Explorer?  (explanation of previous link).

We use the Blueprint CSS Framework a lot here at AWP. It’s saved us untold amount of time worrying about Cross-browser compatibility issues (I’m looking at you, IE6), and the typography settings are fantastic.

There’s a lot of times, though, where the standard Blueprint setup just doesn’t work. Maybe you want a site thinner than 950 pixels, or need larger spacing between columns, or any number of issues that are a pain with the standard Blueprint setup. Usually, to change things like this, you have to go and recalculate your column sizes widths and margins, and then write them all in by hand.

But hey, someone went and did the hard work for you, and though this is linked off of the Blueprint Code site, it needs to be better known: a javascript page to generate your own Blueprint CSS Grid. Just type in your max size, number of columns, desired margins, etc, and it creates it all for you, it even has a compressed version.

Nice.

So if you have called our shop this week you’ve noticed our new phone options. We’re excited to be able to direct callers to their appropriate destination. You can still reach us in the same direct manner (our extensions haven’t changed, so keep hitting 26 if you want me!).

But now you receive a destination based on the following:

Press 1 – new projects!

Press 2 – hosting & email help

Press 3 – website & webtree support

Press 4 – billing

We think this will improve the each and every call and get you to the person best-suited to talk to. We’ve also changed our hold music to match the new theme….which means we’ve let go of our old hold music: the orchestral Mario Bros. medley! Thanks to all the callers who recognized the theme music and pointed it out to us. You are wonderful.

Give it a try: 607.277.2757

I ran across two annoying problems when setting up a new Trac project on our xserve today. Thought I’d share my solutions in hopes of helping someone. Our xserve runs OS X Server 10.4.11, and we’re using Trac version 0.11b2.

(more…)

I just ran into this today while I was updating the TinyMCE editor in WebTree. I noticed that any drop-down menus created from the “Select Style” or “Select Formatting” options would create a 1-pixel wide “menu” instead of an actual menu in Firefox. Awesome! I looked at the HTML it was generating, and it seemed to include an inline style setting the menu DIV to be 0 pixels wide with a 1px border.

I’m not sure why it was doing this.

In Safari, it would generate the menu correctly the first time you clicked on it. Subsequent clicks to show the drop-down menu resulted in a increasingly narrow menu-width, until about the 5th click, at which point we’d hit the 0 pixel limit.

After much wasted time looking through the source code and finding nothing, I found a hint to an alternate solution in the API to the function that writes out the menu. There’s a new setting, called use_native_selects; that apparently was just added in this version. It looks like it is set to true by default, which was causing it to attempt some unnecessary crap writing out a JS menu instead of the browser-specific drop-down menu.

I added this line to my tinyMCE.init({}) settings:

use_native_selects: true,

And the problem was solved. Not as uniform an experience, but that’s ok. It’s functional, and that’s all I really care about. Not sure if there’s any other reports about this bug, but hopefully this will save you some time. Pretty annoying new feature, though, isn’t it?