• The CSS file. It’s 2.1mb, so be careful.
• Examples

I use icons very liberally on all my projects; they’re classy and aid in usability. I typically start with a “.icon” class that configures the correct padding/background details for the element, followed by a “.icon-*” class, which sets the background-image property to that of the desired icon. For example, this CSS:

.icon { background-position:left; background-repeat:no-repeat; padding:3px 0 3px 19px }
.icon-pdf { background-image: url(/images/icons/pdf.png) }

Applied to this anchor element:

<a href="#" class="icon icon-pdf">Download PDF</a>

Produces:  Download PDF

Can you dig it? The same .icon-pdf class in base64 looks like this:

.icon-pdf { background-image:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABGdBTUEAAK/INwWK6QAAABl0RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAAHhSURBVDjLjZPLSxtRFIfVZRdWi0oFBf+BrhRx5dKVYKG4tLhRqlgXPmIVJQiC60JCCZYqFHQh7rrQlUK7aVUUfCBRG5RkJpNkkswrM5NEf73n6gxpHujAB/fOvefjnHM5VQCqCPa1MNoZnU/Qxqhx4woE7ZZlpXO53F0+n0c52Dl8Pt/nQkmhoJOCdUWBsvQJ2u4ODMOAwvapVAqSJHGJKIrw+/2uxAmuJgFdMDUVincSxvEBTNOEpmlIp9OIxWJckMlkoOs6AoHAg6RYYNs2kp4RqOvfuIACVFVFPB4vKYn3pFjAykDSOwVta52vqW6nlEQiwTMRBKGygIh9GEDCMwZH6EgoE+qHLMuVBdbfKwjv3yE6Ogjz/PQ/CZVDPSFRRYE4/RHy1y8wry8RGWGSqyC/nM1meX9IQpQV2JKIUH8vrEgYmeAFwuPDCHa9QehtD26HBhCZnYC8ucGzKSsIL8wgsjiH1PYPxL+vQvm5B/3sBMLyIm7GhhCe90BaWykV/Gp+VR9oqPVe9vfBTsruM1HtBKVPmFIUNusBrV3B4ev6bsbyXlPdkbr/u+StHUkxruBPY+0KY8f38oWX/byvNAdluHNLeOxDB+uyQQfPCWZ3NT69BYJWkjxjnB1o9Fv/ASQ5s+ABz8i2AAAAAElFTkSuQmCC) }

With this strategy in mind, I took each Silk icon and created a .icon-* class, where * is the name of the icon (underscores replaced with a hyphen). Each icon has a background-image property of the base64 encoded image.

The Code

The code to convert a directory of icons into base64 representation is very straightforward and revolves around ColdFusion’s fileReadBinary() and toBase64():

<cffunction name="base64CSS" output="false" returntype="void">
	<cfargument name="imgdir" required="true" type="string" hint="the directory of images to base64 convert" />
	<cfargument name="destination" required="true" type="string" hint="the path and name to dump the css file" />
	<cfargument name="examples" required="false" type="string" hint="the path and name to dump the example html" />
	<cfset var images = "" />
	<cfset var icon = {} />
 
	<!--- read the image directory --->
	<cfdirectory name="images" directory="#arguments.imgdir#" />
 
	<!--- write our CSS and example files --->
	<cfset filewrite(expandpath(arguments.destination), "") />
	<cfif structkeyexists(arguments, "examples")>
		<cfset filewrite(expandpath(arguments.examples), "") />
	</cfif>
 
	<!--- loop through each image --->
	<cfloop query="images">
 
		<!--- read the image and convert it to base64 --->
		<cfset icon.data = toBase64(fileReadBinary(directory &'/'& name)) />
 
		<!--- famfamfam icons separate words with an underscore.  hyphens look better in CSS --->
		<cfset icon.name = replace(replace(name, "_", "-", "all"), '.png', '') />
 
		<!--- create the actual CSS and HTML --->
		<cfset icon.css = ".icon-" &icon.name& " { background-image:url(data:image/png;base64," &icon.data& ") }" />
		<cfset icon.html = '<div><span class="icon icon-'&icon.name&'">' & icon.name & '</span>' />
 
		<!--- append to the css file --->
		<cffile action="append" file="#expandpath(arguments.destination)#" output="#icon.css#" />
 
		<!--- append to the examples file --->
		<cfif structkeyexists(arguments, "examples")>
			<cffile action="append" file="#expandpath(arguments.examples)#" output="#icon.html#" />
		</cfif>
	</cfset></cfloop>
</cffunction>
 
<cfset base64CSS("/home/ehynds/Assets/icons/silk/", "icons.css", "examples.htm") />

I started by creating a “base64CSS” function which accepts three arguments: a path to a directory of images, the CSS file to generate, and the examples HTML file to generate. cfdirectory reads the image directory, the two CSS/example files are created, and then I loop through each image in the directory. Each image is read as binary data and converted to base64, given a name (separated with hyphens instead of underscores), and the CSS and HTML is generated. Finally, the CSS is appended to the CSS file and the HTML to the examples file.

Simple, right? Does anyone else use some kind of icon class? I’d like to see other approaches!

Related posts:

1. CFIMAGE resize after CFFILE upload

I’ve been working on a multiple select plugin on and off for the past couple months and finally have it stable enough for a first release. When I started this project my intentions were only to re-factor Cory LaViska’s MultiSelect implementation, but it quickly turned into a complete re-write with a focus on speed and ThemeRoller support. This plugin turns an ordinary HTML select control into an elegant drop down list of checkboxes.

• Current version: 0.4.1 (02/15/2010 – Changelog)
• View demos
• Download source (11.7 kb) or minified (6.5 kb), and the CSS file.
• Follow this project on GitHub

Features

• Full ThemeRoller support.
• Optgroup support with clickable labels.
• Optional header with check all / uncheck all / close links.
• Degrades gracefully.
• Keyboard support (albeit, somewhat shaky at this point).
• Ability to hook into 5 different event callbacks.
• Display the checked options in a list with a configurable maximum.
• Easily change the position, fade speed, scroll container height, links text, and input text.
• The widget width inherits from the original element, but is also configurable as a parameter.
• Pre-selected & disabled option support.
• bgiframe support.
• Only 6.5kb minified.

Compatibility

MultiSelect is compatible with jQuery 1.4.0+ and all themes from jQuery UI 1.7+. This plugin is known to work in (but not limited to):

• Firefox 2 – 3.6
• IE 6 – 8
• Chrome Beta/4
• Safari 4
• Opera 10

Usage

First ensure you’ve included jQuery 1.4, a jQuery UI theme of your choice, and the jquery.multiselect.css file. You don’t need the jQuery UI library itself, just the theme files. The simplest use of MultiSelect is to bind the widget to your select box:

<select id="MySelectBox" multiple="multiple" name="MySelectBox">
<option value="1">Option 1</option>
<option value="2">Option 2</option>
</select>

$(document).ready(function(){
    $("#MySelectBox").multiSelect();
});

Do not forget to set your select boxes to multiple="multiple" if you want this plugin to degrade gracefully. Any option tags with the selected="selected" attribute will automatically be checked by default, and any option tags with the disabled="disabled" attribute will automatically be disabled by default.

Inside the onOpen callback, this refers to the container holding the header and checkboxes. If you want to gather all the checkboxes inside the multiselect that just opened, for example:

$("#MySelectBox").multiSelect({
	onOpen: function(){
		var $checkboxes = $(this).find('input');
	}
});

Inside the onClick callback, this refers to the checkbox that received the event. Example:

$("#MySelectBox").multiSelect({
	onClick: function(){
		if(this.checked){
			alert("I was just checked!");
		}
	}
});

Options for this plugin are exposed in $.fn.multiSelect.defaults, so you can override the default options for all instances like such:

// set the minWidth parameter for all instances to 500 pixels
$.fn.multiSelect.defaults.minWidth = 500;

Options

This plugin is configurable with the following options:

Known Issues

This is the first stable release, but there are a few outstanding issues to be resolved:

• No onClose callback yet.
• Keyboard support isn’t 100% where I’d like it to be.
• The position should automatically change if the current position will prevent the options menu from showing. E.g., if the input is at the bottom of the page, the options should appear not appear below the input.
• In IE, the shadow parameter increases the width and height of the container, rendering it a few pixels wider than the input and throwing off the alignment. You can easily edit the CSS file and remove the IE-specific shadow filters, however, or opt not to use it.

Related posts:

1. jQuery Related (Dependent) Selects Plugin

When inside a jQuery method’s anonymous callback function, this is a reference to the current DOM element. $(this) turns this into a jQuery object and exposes jQuery’s methods. A jQuery object is nothing more than a beefed-up array of DOM elements.

Digging a little deeper

As you begin to nest functions the context of this changes:

<a href="#"><span>Hello World</span></a>
 
$("a").click(function(event){
	var self = this;
 
	$(this).find("span").each(function(){
		console.log(self, this);
	});
 
	event.preventDefault();
});

In this example I save this to the variable “self” so it can be referenced inside the each() loop. Otherwise it’s impossible to reference this as the anchor element inside the loop, because this is now the “span” DOM element.

Depending on what you’re doing, using this is sometimes easier and always faster than $(this). I’m not talking about scraping jQuery altogether, but rather recognizing that a lot of DOM interaction (especially the simple stuff) can just as easily be done in vanilla JS using this; you are not required to use the jQuery API. Example:

<a href="test.htm">Test</a>
 
$("a").click(function(){
	var href = this.href; // the href property can be accessed through 'this'
});

A more verbose example demonstrating the uses of this and $(this) to get an anchor’s href value. These statements are equivalent:

$("a").click(function(){
	var href;
	href = this.href; // sets "href" to "test.htm"
	href = $(this).attr("href"); // also sets "href" to "test.htm" after going through the jQuery attr() method.
 
	// because $(this) is really just a beefed-up array, we can pull off the DOM element using array notation.
	href = $(this)[0].href;
});

The point here is that turning this into a jQuery object and using the attr() method is more time consuming than just referencing the “href” property of this. When manipulation is involved the performance implications are even greater.

Benchmarks

To quantify my claims, I wrote a profiling function that calculates the execution time of looping a block of code 50,000 times:

var profile = function(label, code, iterations){
	var start, total, i = iterations = iterations || 50000;
 
	start = (new Date).getTime();
	while(i--){ code.call(); }
	total = (new Date).getTime()-start;
 
	console.log(label + ': %d ms (looping %l times)', total, iterations);
}

I then setup a page with one anchor element and a click event to call the profile function:

$("a").click(function(event){
 
	// save $(this) and 'this' - their reference change inside the profile function!
	var $this = $(this), self = this;
 
	console.log('Accessing the href attribute of a link:');
 
	profile('$this.attr("href")', function(){
		href = $this.attr("href");
	});
	profile('self.href', function(){
		href = self.href;
	});
	profile('self.getAttribute("href")', function(){
		href = self.getAttribute("href");
	});
	event.preventDefault();
});

Update 1/7/2010: JAlpino pointed out in the comments that the getAttribute(“href”) method can be called on this to gain an additional +/- 350ms, as opposed to using this.property syntax. I’ve added this method to the benchmarks & results. Thanks, JAlpino!

The results using jQuery 1.3.2 and 1.4a2 respectively on Firefox 3.5.6:

self.href provides a 270% improvement when using jQuery 1.3.2 and a 200% improvement when using 1.4a2. Using the getAttribute() method provides an additional 72% boost over self.href! Keep in mind that in ‘the jQuery way’ these numbers do not include the time it takes to convert this into a jQuery object; we’re caching that outside the profile function, and thus are only benchmarking the performance of the attr() method. How does this perform over $(this) when used for manipulation? I ran the profiler again, this time changing the link color to red:

profile('the jQuery way', function(){
	$this.css("color", "#ff0000");
});
profile('vanilla javascript', function(){
	self.style.color = "#ff0000";
});

We’re looking at a 632% improvement under jQuery 1.3.2 and a 206% improvement under 1.4a2. Pretty good for changing one line of code.

Putting this into context

You can pass an optional second argument called context to the jQuery object constructor, which gives jQuery a starting point when searching the DOM for your selector. The context can be either a DOM element or jQuery object, but ideally should be a DOM element – like this! Given the markup below and what we know about this and $(this), the “span” child of the anchor can be found four ways:

<a href="testing.htm"><span>test link</span></a>
 
$("a").click(function(){
	// these statements accomplish the same thing
	$(this).find("span");
	$("span", this);
	$("span", $(this));
	$("span", $(this)[0]);
});

The first example turns this into a jQuery object and calls the find() method. The second example looks for a span element using this – a reference to the anchor DOM element – as the starting point. Because the context argument in the third example is a jQuery object, jQuery internally converts the statement to $(this).find(“span”), which is equivalent to the first example. We’re about to see that this is the slowest method, however, probably due to the overhead in converting the context to a find(). The fourth method is equivalent to $(“span”, this), except that this is first converted into a jQuery object, and then the DOM node is pulled off the array.

My original plan going into this blog post was to show you the performance benefits you can gain when using this as the context argument to the jQuery constructor as opposed to $(this), but my results show otherwise. Note that I ran these tests 20,000 times instead of 50,000 (Firefox got cranky):

$("a").click(function(event){
 
	// cache $(this) and 'this'
	var $this = $(this), self = this;
 
	profile(' $this.find() ', function(){
		$this.find("span");
	}, 20000);
 
	profile(' $("span", this) ', function(){
		$("span", self);
	}, 20000);
 
	profile(' $("span", $this) ', function(){
		$("span", $this);
	}, 20000);
 
	profile(' $("span", $this[0]) ', function(){
		$("span", $this[0]);
	}, 20000);
 
	event.preventDefault();
});

When using jQuery 1.3.2, $(this).find() was 4% faster than providing a DOM element as the context and 53% faster than using a jQuery object – pretty negligible. 1.4a2 shipped with some nice speed improvements; the performance of all four are about the same, but $(this).find() is still a bit faster.

To reiterate, I’m not saying skip jQuery and code everything in plain JS because it’ll make your site faster. The speed improvements I pointed out are trivial but can absolutely add up, especially in larger applications. There are a number of good reasons to use $(this) over this; cross-browser compatibility is one, the extreme ease of use another, but just be aware this exists.

Click here to see the code and run these benchmarks yourself.

These two examples accomplish the same thing:

// HTML:  <p><a href="">Click me</a></p>
 
// vanilla jQuery
$('p').find('a').click(function(e){
	alert('hello!');
	e.preventDefault();
});
 
// dynamically calling a method
var theMethod = 'find';
$('p')[theMethod]('a')['click'](function(e){
	alert('hello!');
	e.preventDefault();
});

Good to know.

// uncached length property
for(var x=0; x < myArray.length; x++){}
 
// cached length property
for(var x=0, len=myArray.length; x < len; x++){}

I saw this tip and didn’t think twice about it; I’ve always been told that caching the length property is indeed faster. I then saw a couple comments saying otherwise:

Anyway, the loop performance is not as big deal as you present. Of course, it’s nicer and more professional to preassign the array length instead of testing it again in every step. But the performance is not such problem. The Javascript basic operations are very fast, making the difference quite unnoticeable. Those two loops performance will differ only in milliseconds for a million-iterations loop in today’s average computer. This means the same loop traversing an array containing a million items will take about 15 ms if the array.length is tested every time, and about 10 ms if the length is preassigned. So, we are talking about saving nanoseconds per a thousand-iterations loop. This makes no sense from the performance point of view.

And:

These are nearly Identical in performance. Even if the loop does nothing, so that the time spent in the loop is all spent incrementing i and checking its value, it is STILL hard to detect the performance difference. And if you do anything of substance in this loop, the time spent checking against someArray.length is dwarfed by the loop body. This is a stupid complaint.

I have always blindly assumed that the performance hit was due to the interpreter calculating the .length value each time it is referenced, but after talking to some javascript folk (#javascript irc.freenode.net), I discovered that .length is actually a stored value. Since JavaScript doesn’t need to re-calculate it on every iteration of the loop, where would the performance hit come from? Anyway, I thought it would be fun to run some benchmarks of my own to see the difference. Below is little script I put together, but please take it as a grain of salt because JavaScript time is not accurate.

var array = [], start, diff;
var results = { nocache:[], cached:[] }
 
// build array to loop over
for(var x=0; x < 1000000; x++){
	array[x] = x;
}
 
// run tests 25 times
for(var x=0; x < 25; x++){
 
	// length not cached
	start = new Date().getTime();
	for(var y=0; y < array.length; y++){}
	results.nocache[x] = new Date().getTime() - start;
 
	// length cached
	start = new Date().getTime();
	for(var y=0, len=array.length; y < len; y++){}
	results.cached[x] = new Date().getTime() - start;
}
 
// output results
document.write( '<p>No cache time: ' + avg(results.nocache) + ' Values: ' + results.nocache.join(',') + '' );
document.write( '<p>Cached time: ' + avg(results.cached) + ' Values: ' + results.cached.join(',') + '</p>' );
 
// logic from http://javascript.about.com/library/blaravg.htm
function avg(arr){
	var av = 0, cnt = 0, e, len = arr.length;
 
	for(var i = 0; i < len; i++){
		e = +arr[i];
		if(!e && arr[i] !== 0 && arr[i] !== '0') e--;
		if (arr[i] == e){ av += e; cnt++; }
	}
 
	return av/cnt;
}

The code first builds an array with 1,000,000 items, records the execution time of looping over the array 25 times using both methods, and then figures the average. Here are the results:

The results are what I expected except in the Windows versions of Firefox 3.5.2/3.5.5. In all other browsers I tested it is faster to cache the .length value, but in FF3.5 for Windows it is actually faster not to cache. Internet Explorer receives the most benefit with a ~30% increase in performance when caching, with Opera (Linx) and Chrome (Linux) in fourth and fifth place respectively. The amount of time is indeed negligible, but every millisecond counts, right?

If nothing else it is interesting to see how long it takes different browsers to loop through a large array. Firefox and Safari FTW!

Related posts:

1. jQuery and Performance: What is ‘this’?

I’m still undecided whether or not I want to add caching. I thought about it when I first wrote it and a user suggested it, but I cannot picture a use case where caching would be necessary; people are likely to choose an option and either decide it was incorrect and change it, or stick with it. In either of these cases, caching doesn’t do anything other than add overhead. If a user selects an option and then continuously changes/reverts back to it, caching would be helpful, but how often is this likely to happen?

Anyways, here’s she is:

• Examples
• Download & documentation
• jQuery plugin project page

Related posts:

1. jQuery Related (Dependent) Selects Plugin

• Demos & examples
• jQuery plugin page
• Source & documentation @ GitHub

From the GitHub docs:

jQuery Related Selects is a plugin that allows you to create any number of select boxes whose options are determined upon the selected value of another. You pass an array or object of select box names, and the select boxes will depend on each other in the order in which they are passed in.

When a select box is changed an AJAX request is sent to the file specified in the onChangeLoad property, passing the selected value of each select box as parameters. For now the data must be returned in JSON format. An <option> must have a legitimate value in order to trigger the script. An <option> where the value is blank (value="") is used for the defaultOptionText option (see below).

This script provides a high level of customization. You can set the options once for each select to use, or set the options on a select-by-select basis. You can also start your markup with pre-populated options and selected values.

Usage

A basic example. Changing the "stateID" select updates the "countyID" select and so on. The values of all four select boxes are serialized and passed to datasupplier.php, which returns data for the next select box in JSON format.

<form>
	<select name="stateID">
	<option value="">Choose State</option>
	<option value="MA">Massachusetts</option>
	<option value="VT">Vermont</option>
	</select>
	<select name="countyID"><option value="">Choose County</option></select>
	<select name="townID"><option value="">Choose Town</option></select>
	<select name="villageID"><option value="">Choose Village</option></select>
</form>

$("form").relatedSelects({
	onChangeLoad: 'datasupplier.php',
	selects: ['stateID', 'countyID', 'townID', 'villageID']
});

Options

selects

Required. An array or object of select boxes you want to be dependent. Each one will depend on each other in the order in which they are passed in. If you want to override any of the options below on a select-by-select basis you can pass this as an object. See examples.

onChangeLoad

Required. The file to call to retrieve data when a select box is changed. Data must be returned in JSON format for now.

loadingMessage

Optional. The text to change the sibling select box to during the AJAX request.

defaultOptionText

Optional. The text inside the default <option> tag after AJAX populates a select box. This is typically the text where you instruct the user to choose an option. If this option is not provided and an <option> tag with a blank value attribute exists in your markup, that text will be used.

onLoadingStart

Optional. A callback to fire when the AJAX call starts.

onLoadingEnd

Optional. A callback to fire when the AJAX call ends.

onChange

Optional. A callback to fire when a select box is changed.

11-18-2009: Bug fix & new features update

I’ve fix a bug where refreshing the page makes all selects become active, and added a new option and callback:

disableIfEmpty

Set this option to true to keep the next select disabled if the previous does not return any results.

onEmptyResult

Optional. A callback to fire when no results are returned after changing a select.

12-2-2009: Update: Return data in HTML format

Data can now be returned in HTML format by using the new dataType option. Set it to either ‘html’ or ‘json’ (default).

Related posts:

1. jQuery Related Selects Plugin 0.3

Essentially, if a user is considered idle after a certain period of time, a message appears informing him/her that the session is about to timeout and offers a link to continue the session. "Idle" is a state where the following events have not been fired after a specified period of time: mousemove, keydown DOMMouseScroll, mousewheel, and mousedown. If the user clicks on the link to continue, an AJAX request is fired off that will keep the session alive. I am not sure about other programming languages, but in ColdFusion calling a .cfm or .cfc file will reset Java’s internal session timeout clock back to zero.

The code is fairly straightforward thanks to Paul Irish’s idleTimer plugin which I use to handle the idle detection. The rest involves interacting with the idle state and recovering from it when the user is no longer idle.

You can see an example here.

The (heavily commented) code:

$(function(){
 
	var $bar = $("#idletimeout"), // id of the warning div
		$countdown = $bar.find('span'), // span tag that will hold the countdown value
		redirectAfter = 30, // number of seconds to wait before redirecting the user
		redirectTo = 'timeout.htm', // URL to relocate the user to once they have timed out
		keepAliveURL = 'keepalive.php', // URL to call to keep the session alive, if the link in the warning bar is clicked
		expiredMessage = 'Your session has expired.  You are being logged out for security reasons.', // message to show user when the countdown reaches 0
		running = false, // var to check if the countdown is running
		timer; // reference to the setInterval timer so it can be stopped
 
	// start the idle timer.  the user will be considered idle after 2 seconds (2000 ms)
	$.idleTimer(2000);
 
	// bind to idleTimer's idle.idleTimer event
	$(document).bind("idle.idleTimer", function(){
 
		// if the user is idle and a countdown isn't already running
		if( $.data(document,'idleTimer') === 'idle' && !running ){
			var counter = redirectAfter;
			running = true;
 
			// set inital value in the countdown placeholder
			$countdown.html( redirectAfter );
 
			// show the warning bar
			$bar.slideDown();
 
			// create a timer that runs every second
			timer = setInterval(function(){
				counter -= 1;
 
				// if the counter is 0, redirect the user
				if(counter === 0){
					$bar.html( expiredMessage );
					window.location.href = redirectTo;
				} else {
					$countdown.html( counter );
				};
			}, 1000);
		};
	});
 
	// if the continue link is clicked..
	$("a", $bar).click(function(){
 
		// stop the timer
		clearInterval(timer);
 
		// stop countdown
		running = false;
 
		// hide the warning bar
		$bar.slideUp();
 
		// ajax call to keep the server-side session alive
		$.get( keepAliveURL );
 
		return false;
	});
});

The idleTimer plugin fires a custom event called idle.idleTimer which this plug-in binds to. As long as the countdown is not already running, the countdown value is set (starts at 30), the warning bar slides down, and a timer is created using setInterval. This timer fires every second until either the link is clicked to stop it, or the counter reaches 0 and the user is redirected. If the link is clicked, the timer is stopped, the warning bar slides back up, and a server-side file is called that will actually keep the session alive.

Again, you can see a demo here and view source to see the structure/styling of the warning bar.

Next, open up your terminal and issue this command:

wget -r --level=10 --delete-after -nd http://www.mydomain.com/

wget will crawl through the site and retrieve just about everything 10 levels deep (change --level=10 to however many levels you want). -r searches recursively, --delete-after deletes the wget’d files right after downloading them, and -nd prevents wget from creating directories locally.

Once done, check your log files and see what it found. If you’re impatient like me, you can tail -f your log files on the server to stream new data.

The reason is because computer janitor removes the adobeair package while corrupting the adobe-certs package. Run the commands below to fix, but as a disclaimer, my ~/.appdata and ~/.adobe directories had nothing important in them. I’m not sure if AIR holds application data in either, so you might want to back it up first.

1. Open synaptic package manager and remove the adobeair and adobe-certs packages if they exist.
2. Delete anything to do with AIR: sudo rm -rf /opt/Adobe\ AIR/ /var/opt/Adobe\ AIR/ ~/.adobe/ ~/.appdata/
3. At this point you can do a sudo dpkg -l | grep "Adobe" and if you still see the adobe-certs package, run sudo dpkg --purge adobe-certs
4. Close your browser and sudo ./AdobeAIRInstaller.bin to reinstall.