Drag the link below to your toolbar and you’re set:
jQueryify

Running the Safari Developer tools error console yields the following errors on Facebook’s end:

Unsafe JavaScript attempt to access frame with URL http://www.facebook.com/home.php? from frame with URL
http://static.ak.facebook.com/common/redirectiframe.html. Domains, protocols and ports must match.

Unsafe JavaScript attempt to access frame with URL http://www.facebook.com/home.php? from frame with URL
http://0.channel14.facebook.com:80/[snip...]. Domains, protocols and ports must match.

Basically, it looks like Facebook’s trying to send a request during the login process from a subdomain of their site. Safari’s flagging it as breaking the AJAX “same origin” URL policy and preventing the request from completing. By acting correctly - Facebook’s requests are indeed breaking the same origin policy - Safari’s also blocking me (and a whole bunch of other people) from being able to login. (Now, I could be wrong here with the exact cause of the behavior, but the bottom line is something on Facebook is still totally breaking login in Safari 4.)

Is the new Safari being too strict? Why can I login in Firefox and Google Chrome? Is this an odd use case in a browser with a small market share (I’m guessing less than 4% of Facebook’s base) that wouldn’t be caught during testing as it’s not part of Facebook’s test platform, or is it a legitimate cross-browser bug that will be solved?

Clearing my cache (holding SHIFT and pressing the refresh button in the address bar or holding CONTROL + F5 / CONTROL + FN + F5 on a macbook) seemed to do the trick: the requests still showed up as failing, but I was able to log in. But, I’m still interested to see if this winds up being a fairly high-profile example of cross-browser development’s pitfalls on a really big stage.

Very, very odd.

So, something like div.bd won’t return any results.

The solution is to upgrade to 2.7.0. I’m working on a site on which I can’t upgrade the whole package; it would take too much QA time. So, I tried dropping Selector 2.7.0 over the existing file (in my case, an ancient 2.5.2 version). The result: seems to work like a charm, so it’s worth a try.

EDIT: Also just saw that IE8 likes to detect our internal dev servers as intranet sites and throw itself into IE7 compatibility mode. Make sure you use developer tools on whatever site you’re testing (production, in my case), and then reset them wherever you’re developing.

Copious uses of the YUI library and a whole bunch of lightbox / media player functionality that I hacked together. My favorite part: the in-page glossary (nice little RegExp there) and the little lava menu I worked up on any of the Glossary pages.

Paul and I came up with this:

// transfer an element's styles to another element.
// adam mcintyre & paul irish
// public domain, bitchezzz.

// we'll start with an h1.
var el = document.getElementsByTagName('h1')[0];

var cStyle = ''; 

for(var i in el.style){      

  if(typeof el.style[i] != 'function'){ 

    cStyle += i.replace(/([A-Z])/g,'-$1').toLowerCase() +
    ':' +
    (document.defaultView.getComputedStyle(el,null)
      .getPropertyValue(i) || 'none') +
    ';'
  }
}

// at this point cStyle is a big long string of
// display:block;opacity:1;css-text:none;parent-rule:none;azimuth:none;....

// h3's will grow up big and strong like h1's!!!!
document.getElementsByTagName('h3')[0].style.cssText = cStyle;

QUICK TAKE: Stay up to date on the latest news from Nikon, producer of much-heralded cameras, scanners, and other imaging

Nikon site ranked #13 in the Top 100 photo sites. Not too shabby.

You’ll wind up with a null object error otherwise.

I wonder if I did something wrong?

A quick inspection with Firecookie revealed that the Cookie utility was creating a huge number of cookies with the same name and binding them to a single page by default. (At least in 2.5.2). If you’re on that branch (I can’t upgrade a production instance, for example), make sure you add a path to the cookie you’re creating if you’d like the cookie to be readable and writable by more than the page you’re on. That would look something like this:

        YAHOO.util.Cookie.set('someName','someValue, {
            expires : new Date('January 1, 2010'),
            path : "/"
        });

That will make your cookie readable beyond a single page and might save you a headache.