GigglingCorpse

Dear Diary,

With the onset of HTML5 becoming increasingly supported among the many browsers out there, there are going to be a number of important changes coming to the way things work. Things such as… the MathML and SVG support, a large number of new elements and deprecation of some older obsolete ones, and most importantly (for the purposes of this article) an important change to the history API functionality!

Unfortunately, HTML5 isn’t supported in every browser… largely because older versions of browser either can’t support it or just aren’t being updated to support it. People should update their browser anyway… so many unnecessary headaches caused by having to go back and debug some random old version of IE or Firefox because someone is reluctant to update. I will say, props to Chrome for silently updating itself to the latest version and indicating that a core app restart is required with those little coloured arrows!

Due to this lack of support in all browser, *glares at IE*, another solution is required to properly combat this looming headache menace! One of the best tools at our disposal as web developers is the History.js HTML5/HTML4 wrapper.

You can find it here: https://github.com/balupton/history.js
…and a demo here: http://balupton.github.com/history.js/demo/

Straight from the description on github: “History.js gracefully supports the HTML5 History/State APIs (pushState, replaceState, onPopState) in all browsers. Including continued support for data, titles, replaceState.”

The key thing that the History.js adds is complete cross browser support for history behaviour on all websites. Of course, browsers that support HTML5 have a much nicer experience, but it still works very neatly in general. Thankfully, it also includes plugins for major javascript frameworks, including jQuery, Mootools and Prototype.

An implementation using History.js

One of the tasks I was working on at work was to transition an aging web application which was still using a frameset for it’s layout into a single-page application. The catch was that part of the page load was an EXTREMELY heavy client side javascript menu. As a result, simply loading the entire page each time while navigating around the application was a bit of a performance issue, resulting in page load times nearly doubled.

My solution was to implement a chromeless loading system based around caching pages in the DOM and utilizing HTML5 history API calls wherever possible to allow for fast page transitions going back and forward in the browser.

I quickly found that HTML5 wasn’t fully supported (as expected), and also that it there was still inconsistent behaviour between different browsers. After a bit of searching around online, I came across History.js, realized its potential, and began implementing it into the application.

The basic idea behind what I wanted to do was keep enough meta information about each page the user navigated to such that I could determine if it was either cached already and could be swapped in, or if it needed to be requested and cached again. This was particularly important, because closing the browser would typically cause you to lose your history for that session, but it is possible to keep track of your history even between browser loads with History.js.

As a result, the general behaviour was to to either push a new page on to the history when performing new navigation, replace an existing cached page when a forced load was required (stale data or no longer cached due to browser reload), and wrap normal browser back and forward with a history state change event.

I actually found a funny little bug while working on this solution (which may be fixed now, I haven’t bothered to confirm), where if you are using the amplify.store.js storage solution for page caching via History.js, after 1000 page loads it would simply go into an infinite loop because it couldn’t find the next “unique” page identifier to use. Page identifiers were generated by selecting a number at random between 1 and 1000… and of course testing this on development, I would constantly be reloading pages and changing states… which lead to some fun times debugging the infinite loop.

Ultimately I had to skip using the storage system, and I implemented a version of it myself in the DOM itself. I like this solution better anyway, because it gave me direct control over what was cached and how it was manipulated more so than the storage system would.

At any rate, here are a few simple code snippets of how I was using History.js:

// set up history change event
var History = window.History;
History && History.Adapter.bind(window, 'statechange', function(){ … });
 
// pushing new state data (History.pushState and History.replaceState have identical syntax)
History.pushState({
	state: customState,
	timestamp: pageLoadTimestamp,
	page: pageKey,
	extraData: dataObject
}, pageTitle, pageUrl, false);
 
// state change event
var onHistoryStateChange = function(e){
	var HistoryState = History.getState();
 
	// access the custom data you've assigned to the history state
	// HistoryState .data.state;
	// HistoryState .data.timestamp;
	// HistoryState .data.page;
	//
	// handle state change by either loading new page or loading cached page etc ...
}

And lastly for more reading about manipulating the browser history, Mozilla Dev has a nice article that I found useful on it here:

https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history

Your friend,
Jeff

On June 2, 2007, I received an e-mail requesting that I add 128×128 and 256×256 pixel icons to the .ICO resource Bradicon creates. I added them on Bradicon’s dev site, and replied that same day, but have yet to receive an email back. I didn’t end up publishing the changes to Bradicon.

That was a long time ago!

Luke brought it up again last night, and I started to think about it. The changes to the code would be super, super easy. I am a little worried that people may be upset if their icons are suddenly ~22 times as large in file size, which is a substantial increase. ~0.3 MB seems excessive for a favicon.

It really comes down to what people are using the icons for, and it looks like a lot of them are as custom shortcuts for their desktops. For many of these people, the additional sizes will be useful and the increased file size should not be an issue.
On the other hand, I use Bradicon to create favicons and, on rare occassions, application icons. I’m sure some percent of people use it for this same purpose, but (based on the sites that link to Bradicon) I suspect that percent is small.

One option is to add a checkbox that says something along the lines of Add large icons, and have it default to checked. While this offers more flexibility, it will also increase the complexity of the interface. I’ve always kind of felt that one of Bradicon’s strong points was its ease-of-use.

I’ve added a box to Bradicon asking people if they’d welcome the addition. Rather than find a poll system, i’ve added some javascript to the links which will send result page views to Google Analytics.
When users click the links, nothing happens. This is something I should probably change. I could perhaps, replace the links with a Thanks for your input-style message.
I probably won’t do this. If someone really wants their input taken, and clicks the link a bunch of times, I think I am cool with that. That seems like semi-useful information. Also, I am lazy.

A project I’m working, for a company in far-away London, has to do with reporting. But who knows which web browsers they prefer there? I certainly don’t, which is why I’ve been testing in Firefox, Chrome, Safari, Opera, and IE. To be honest, it’s just something i normally do.

And what’s a report without a few graphs? Probably boring!
I decided to use Google Visualization to generate the graphs. Not such a big deal, since I used it as recently as two posts ago.

But things didn’t go quite as I’d expected.

Being fairly reasonable, I started with a single graph. It displayed in Chrome, Safari, Opera, and IE, and everything was going well. But then I checked Firefox, and where the graph was meant to be there was a depressingly empty iframe.
The graph didn’t show up at all in Firefox.

I went about figuring out why, so that I could fix it and for other reasons. There was testing, and even more testing, and I’m sure some lucky combination of logic and prayer.
And now it works!

What the system does:

1. A base page is loaded, complete with your choice of whose report you’d like to view
2. Javascript ajaxs over that guy’s report dashboard, which is mostly made up of data range selector
3. Javascript ajaxs over the graphs based on your range selection

These loads initially happen without the user’s direct input. The system stores their settings, and uses those to figure out what to load, or it loads based on the defaults. If a setting is changed, it retrieves everything after that in the list.

When the call to graph the data (which is received in step 3) took place in step 3, Firefox loaded an empty iframe.
When I moved it to a function returned in step 2, which triggered the retrieval of step 3 (in the ajax’s success handler) everything worked fine.

Weird, but works now!

There was another issue (unrelated to Google Visualization) that I came across in Opera and IE, but it was less strange and pretty easy to fix.

People tend to over-react. I’m not sure why; they must derive some enjoyment from it.

And I could definitely see that being the result of this: web2.0collage.com.

If pleasure from paranoia is your thing, that’s cool we can still be friends. But you should probably skip the rest of this post because I will point out that it cannot see which websites you’ve visited, so much as detect whether you’ve visited a website. A small, but in my opinion, very important distinction. The two would be equivalent if it checked every possible URL.

It works as follows:
There is a specific a tag. CSS defines its :visited style, so that when it points to a page you’ve been to it changes colour and size. Javascript then goes through a list, and for each entry points that tag to the corresponding URL. It then checks the style the browser has applied to it. If it matches that defined in the css’s :visited, it decides you’ve been there. If not? Maybe you hate that site and avoid it at all costs.

Nothing really special, just a clever-ish if ugly-ish (sorry) use of Javascript and CSS.