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

This is for Dennis, because he couldn’t find it on the internet:

HTML

<table border="1">
	<tr>
		<td>0</td>
		<td>
			<table border="1">
				<tr>
					<td>0</td>
					<td>
						<table border="1">
							<tr>
								<td>1</td>
							</tr>
						</table>
					</td>
				</tr>
			</table>
		</td>
		<td>0</td>
	</tr>
</table>

So basically just three tables nested.

CSS

td td td:hover { background-color: #aeaeae; }

td td td:hover means that when the mouse is over a td tag, that is a descendant (within) of a td tag that is a descendant of a td tag this style is active.

I wrote a flash gallery front-end a week or so back. There’s a picture of it above. Just kidding it’s an actual instance! Some of the thumbnails might take a while to load. That is because they are not thumbnails but giant, giant images.

It uses ExternalInterface and Javascript to display the descriptions in the HTML. I’ll post the relevant code with an explanation next time, but let me tell you right now – having more than one gallery per page doesn’t pose a problem ( programmatically ).

The gallery is described by XML, and added to a page with a simple Javascript call.

The statement that Flash TextAreas ( TextFields, etc. ) can display HTML can be deceptive. They can certainly display a subset of HTML. But this is a very limited subset, and for good reason.

While it’s easy to understand why this is the case, it can still be frustrating. Say, for example, you’re building an image gallery and would like to have some of Paypal’s buy-now buttons in image descriptions. A Paypal button can be perhaps a deceptive thing – it’s tiny forms whose only visible element is the buy-now image – which cannot easily be accurately displayed by Flash.

But don’t worry, especially if your Flash will be displayed within a browser, for that is a thing built to display HTML. In fact, it’s one of its primary and most useful purposes.

The trick here is to get Flash to communicate to the browser what HTML to display, and how to do it. It turns out this is relatively easy to accomplish.

Here we make the following assumption: Your SWF file knows what HTML to display, and when. In my mind, this is a pretty safe assumption to make.

Okay, so I’ll break the method down into steps:
Step 1: Flash tells javascript to display some HTML.

Okay that’s about it.

You’ll have to write the Javascript to display the HTML where you want it, but that’s easy enough.

Flash provides an External Interface class ( flash.external.ExternalInterface ) that allows for communication between Actionscript 3 and the Flash Player container – in this case the web page and its Javascript.

You’ll have to include the ExternalInterface in your class file, and there are some checks you can (and probably should) diligently perform, but the important Actionscript 3 is:

import flash.external.ExternalInterface;
...
var html:String = "<p>This is some html.</p>";
if (ExternalInterface.available) {
	ExternalInterface.call("writeHTML", html );
}

The Javascript function writeHTML will be called with the parameter html. So it’d probably be good if there was such a function:

function writeHTML( str ) {
	document.write( str );
}

A better Javascript function would be, well.. better.. but, you know, brevity and all that.

That’s basically all there is to it. Next time blog I’ll provide a more concrete example of ExternalInterface in use (one that uses multiple parameters in its Javascript call). And if you want, post the applicable code?

As a side note: if you’re loading the HTML via XML, always remember to wrap it in CDATA.