Best practices: Browser Stuff: Posts

There is a new “Facebook” application that utilizes CNETs great API system. This app that was developed is called “My Tech”.
Apart from the great technology use, it is a fun way to show off your latest tech gear to your friends. The best part is you can show your disdain for certain tech products if you absolutely hate it… Good times

“Tag line from app profile”
This application allows you to let everyone know about the latest tech gadgets available using MyTech powered by the CNET API. Facebook users can find it at: http://mytech.cnet.com

CNET Report on CNET MYtech

via Ajaxian:

Daniel Kantor has implemented a Back button solution in Streampad and has shared it with us.

One of the main gripes against AJAX webapps is how they break the back button in a typical browser. There have been a few solutions (notably Brad Neuberg’s Really Simple History) but none have got it working in Safari. GMail still does not have a working back button in Safari.

They say the third time is the charm and I have tried to get a Back button thing in Streampad twice before. I do not want to use someone else’s library as they are usually more complex than I need and I did not want to put something in place until I had Safari working. I tried a few different techniques, but when I got it working in Safari, it would break in Firefox or IE.

I finally figured out a way to get this working in Firefox, IE and Safari.

While Daniel struggled with this, he found that the back button support caused a slow down in the entire app performance. He came up with a new solution that didn't suffer from the performance issues:

The general concept is this: You load a page into an iframe that calls parent.goBack() and then changes its own location to a new page (a blank page will do). Because the page jumps to a new location, it now has a history. If you click the back button, it will load the page again (calling parent.goBack()) and then spring forward to the dummy blank page.

PLAIN TEXT

JavaScript:

var historyArray = Array(); // create an empty array to hold the history
var historyCounter = -1; // initialize the array pointer to -1

function historyAdd(f){
  if (historyCounter == -1){  // the first time this is called it will change the iframe location
  document.getElementById(’hFrame’).src = “/historySpring.php”;
}

var o = historyArray[historyCounter];
if (f != o){ // don’t put in consecutive duplicates
  historyCounter++
  historyArray[historyCounter] = f; // add function to history
}

function goBack() {
  if (historyCounter> 0){ // don’t want to call it if there is nothing in history array
    historyCounter– // set the pointer back one
    var f = historyArray[historyCounter]; // get the function from the history array
    f = f+”()”;
    eval(f); // call the function
  }
}

via ajaxian: IE7: Twice as performant as IE6, but half as slow as FF 1.5
Ross Dargahi of Zimbra complained about IE 6 performance. Since IE 7 is here, he decided to retry his tests and see how Microsoft had done:

Microsoft's IE team has clearly been hard at work on improving their browser's memory management and JavaScript performance. IE 7 has made some significant leaps forward based on some initial in house testing here at Zimbra. We are in general observing about a 2x performance improvement with IE 7 vs IE 6 when using the Zimbra Web Client (ZWC). | Read the rest »

via ajaxian:

Abe Fettig knows that we need to start detecting the difference between IE6- and IE7+, because a lot of the hacks that we were using for IE are no longer needed.

He didn't want to grok the user agent, as that is very brittle, so he came up with:

if (typeof document.body.style.maxHeight != "undefined") {
// IE 7, mozilla, safari, opera 9
} else {
// IE6, older browsers
}

Any other thoughts?

| Read the rest »

Want several copies of IE running side by side? Want to test out IE 7 but don't really want to zorch your IE 6 that you also need to test? No problem.

via Ajaxian:

Patrick Fitzgerald posted a nice screencast explaining how he diagnosed and fixed an IE memory leak in his tabifier library. He walks through using the free tool Process Explorer to watch IE's memory grow with each page refresh. | Read the rest »

Bill Graham was asking me about where to put javascript events today. window.onload? At the bottom of the html document? Attached to the onload event of an image somewhere in the page?

Here's an article by Dean Edwards on an interesting solution that works for IE and Firefox.

For the life of me, I can't find the article that I read a week or so ago on this topic that outlined numerous strategies on dealing with window.onload issues, but one option to consider is using event monitoring in prototype to monitor the browser for an element to be present before performing an action on it.

Part of Yahoo's library release includes their browser support ethos. It's worth a read.

| Read the rest »