jQuery Bookmarklet
February 26th, 2010Inject the latest version of jQuery into your page. All in handy bookmarklet form!
Drag the link below to your toolbar and you’re set:
jQueryify
Inject the latest version of jQuery into your page. All in handy bookmarklet form!
Drag the link below to your toolbar and you’re set:
jQueryify
Here’s a fun, major example of a cross-browser bug in the wild. It seems that, for certain users of the Safari 4 beta (latest update after the Mac OSX release), logging into Facebook is totally hosed. If I try to log in, Safari gives me a cursor with a lovely blue ball. It doesn’t even spin like the beach ball of death.
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.
Versions of the YUI Selector utility prior to 2.7.0 won’t work with IE 8. There’s a bug in there somewhere that breaks className selectors.
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.
Have a look at that lovely Learn and Explore section on NikonUSA.
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.
If you’re running an animation for 250 ms and you need a function to execute after that, make sure you either run it as a call back or set a timer that’s longer than 250 ms…
Kind of a thought experiment. You have one HTMLElement with a bunch of unknown style properties set on an ID selector or Element selector, and you need to get them over to another, completely different Element.
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;
Data not going through? Try adding a call to s.tl() to flush things out and make sure they’re sent to Omniture. It seems to not want to send certain custom events by default.
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.
Bit of an odd one. It seems that in between the beta version of CakePHP 1.2 that I’ve been using and the full release, Helpers now must have lower-case filenames or they go missing.
You’ll wind up with a null object error otherwise.
I wonder if I did something wrong?
I’m doing a bit of work with cookies, so I figured that I’d give YUI’s Cookie utility a try. Got it up and running on a proof of concept with no problem and it worked pretty well. However, once I moved off the proof of concept, it seemed like my cookies were only living for one page.
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.