While the first feature of drag and drop uploading I figured out quite easily, this drag out feature was a doozy.

How did I figure it out?

There were two clues which got me started. One it only works in Chrome so it had to be an extension to the current Drag and Drop API. Two, after some poking around in gmail, there was a custom attribute on the attachment link called download_url which colon separated the attachments mime type, file name and download link.

Since Gmails JavaScript is obfuscated to within in an inch of its life there was no easy way to attach the built in debugger to anything that might give it away. So I tried downloading the script and running it through various unobfuscaters which made it format nicely but I still had to work with function names like vHG etc.

My last hope was chromiums bug tracker and searching to see if any bugs or feature requests were filed that could help give it away. I knew the download_url attribute played a role and it would be set using setData method on the dataTransfer object. So I searched high and low on Chromiums bug tracker for matches to “download_url”, “downloadurl” & “downloadurl setData” nothing nada, zip. So I turned to the webkit bug tracker, still nothing! So I thought maybe Mozilla had discussed it on their bug tracker, a long shot but worth a try. Bingo! This bug led me to this bug, on webkits bug tracker don’t ask why the search didn’t bring this up, and then onto this proposal. We’re in business!

How does it work?

So we’ve found the details let’s play with it.

Update: I’ve rolled out drag to desktop across my site for all my demo source files. If you’re using Chrome 5+ just drag the “Download the source files” link to your desktop!

The above demo will, in Chrome 5+, allow you to drag any of the items to your desktop and save them without having to go through the usual save dialog process.

var file = document.getElementById("dragout");
 
file.addEventListener("dragstart",function(evt){
    evt.dataTransfer.setData("DownloadURL",fileDetails);
},false);

From the code above you attach an ondragstart event listener to something you want to “drag out” and save to your file system. On the dragstart event you set the data using the new “DownloadURL” type and pass file information to it.

In order to pass the correct information to the event we access the download_url attribute and use that for our setData call. I’ve made one change that is slightly different to how Gmail sets and gets the attribute.

<a href="Eadui.ttf" id="dragout" draggable="true" data-downloadurl="
    application/octet-stream
    :Eadui.ttf
    :http://thecssninja.com/gmail_dragout/Eadui.ttf">Font file</a>

Instead of creating a new attribute I have instead used the new custom data attributes specified in the HTML5 spec. While not officially supported by Chrome yet we can still use it and add a simple test for support and fork the code either way.

The custom attribute needs three things specified that are separated by colons in order for it to work. The files mime type, the name you wish it to be saved as (this can be anything) and the url to where the file can be downloaded from.

var fileDetails;
 
if(typeof file.dataset === "undefined") {
    // Grab it the old way
    fileDetails = file.getAttribute("data-downloadurl");
} else {
    fileDetails = file.dataset.downloadurl;
}

Above I do a check to see if the element supports the dataset attribute if not use getAttribute to grab the value.

A cool finding

Playing around with this new functionality I did find a cool side effect that if I drag a file that’s set the DownloadURL type on the setData method into a page using Firefox 3.6+ that will capture a drop event the dataTransfer file attribute will act as though it’s captured a local file and can be manipulated with the FileAPI e.g. In my font dragr web app if I drag a font file that’s been attached to an email it will render the font as though I’ve dragged it from my local file system! Doing the same with Chrome 6, which also supports file attribute on the dataTransfer property, will ignore the drop.

Predicting the next challenge from Google

So what do I think the Gmail team will do next? Since they announced, and are now starting, their 6 week release cycle of chrome. I foresee the ability to upload folders not just individual files, being able to capture a photo from your web cam straight into an embedded picture using the proposed media capture proposal. Whatever it is I’m sure it’ll knock everyone’s socks off and make me rack my brain in trying to figure it out.

Short URL: http://cssn.in/ja/028

In the above demo I’ve recreated a mock Gmail UI that works the same as the actual Gmail with drag drop uploading. It feature detects the browsers capabilities and depending on it will use the File API or another method, which I will delve into. The beauty of feature detection is once Chrome and other browsers add support for the File API the alternative method will become defunct and would require no maintenance for the code.

I have intentionally left out the File API code that would allow Firefox to function as I wanted to focus on Chrome’s implementation.

So how does Chrome do it?

Using a bit of CSS trickery we can create the illusion of having File API support and still allow users to drag and drop files from the desktop into Gmail. I accomplish this by having the drop zone, which becomes visible on a dragenter event, contain an invisible file input with a 100% width and height of the drop zone area. The file input also has the attribute multiple on it allowing a user to drop multiple files.

<div id="drop">
    <h1>Drop files here</h1>
    <p>To add them as attachments</p>
    <input type="file" multiple="true" id="filesUpload" />
</div>

The drop zone is hidden by default and only appears when the body detects the dragenter event.

#drop {
    position: relative;
}
#drop input {
    position: absolute;
    width: 100%;
    height: 100%;
    top: 0;
    left: 0;
    opacity: 0;
}

The file input inside the drop zone has position absolute, width and height of 100% and its opacity set to 0 so it can still be interacted with but not seen.

Handling the drop

Unlike Firefox 3.6 we don’t bother listening for the drop event in the drop zone as Chrome is using the file input. We instead attach a change event to the file input which will trigger when a file is selected through the browse screen or in our case when a file is dropped on the input, and since we added the multiple attribute we can drop more than one file at a time.

dropArea.addEventListener("change", TCNDDU.handleDrop, false);
 
TCNDDU.handleDrop = function (evt) {
    var files = evt.target.files;
    dropArea.style.display = "none";
    for(var i = 0, len = files.length; i < len; i++) {
        // iterate over file(s) and process them for uploading
    }
};

The function that handles the change event looks at the javascript event target to access the files array which contains the dropped file(s) name, size and type. From there we can iterate over the files and queue them to be uploaded.

Uploading the file

I’ve updated the demo to now upload the file. Using XHR2 and the upload attribute to attach progress events so we can do a real progress bar that indicates to the user how much the file has uploaded.

Drop the file or files into the drop zone in Chrome or Safari and the files will be uploaded.

Have a read of Andrea Giammarchi Safari 4 Multiple Upload With Progress Bar article. I used the PHP from that article to handle the upload.

Why doesn’t it work in Safari?

Technically it does work in Safari but only if you drop one file at a time which isn’t what users would expect. Dropping multiple files will populate the files array in the file input, but selecting say 3 files and dragging them into Safari will register 3 files have been dragged but if you iterate over the files array those 3 files will all be the same file…

To explain it better let’s say you have 3 files each one called a.jpg, b.jpg and c.jpg selecting those 3 files and then clicking and dragging on the b.jpg file will add 3 files to the input. The file you did the drag operation on will be added 3 times to the input and it will ignore the other files, iterating over the files array will have b.jpg 3 times?!

To add to the strangeness if I have an input that is visible and I click the choose file/browse button and select multiple files in the dialog box upon clicking open the files array will correctly be populated with all the files selected and won’t have the duplication issue.

That folks is why I believe Safari isn’t supported in the new drag and drop upload feature in Gmail. I’m sure Google has tapped Apple on the shoulder to get that fixed.

Update: Paul has filed a ticket in webkits bug tracker.

A work around?

The only work around that Google could do is to break out of the loop if they detect multiple instances of the same file being referenced. This work around would limit Safari to only 1 file per drag and drop operation.

TCNDDU.handleDrop = function (evt) {
    var files = evt.target.files;
 
    for(var i = 0, len = files.length; i < len; i++) {
        if(i != 0 && files[0].fileName === files[i].fileName) continue;
    }
};

Checking the first file name against other file names and making sure they don’t match, if they do skip that iteration and go to the next. If the file names are all the same only the first will be processed but you still get the benefit of drag and drop action in Safari. Not ideal and an error message could be shown to the user letting them know why only 1 file appears.

Still sometime to go

From my investigation it seems Safari isn’t far off from getting some drag and drop love, they just need to push out a fix for the bug mentioned above or Google could limit drag and drop to first file only for Safari.

I don’t expect to see this functionality in any version of IE until they support the File API. Dragging and dropping a file into a file input doesn’t work nor does IE have a files array for the file input.

Opera is a long way from having this functionality they have yet to implement the Drag and Drop API and their file inputs work the same as IE.

Our best bet of getting cross browser drag and drop uploading is with the Drag and Drop and File API. Let’s hope we see some other browser vendors add this soon.

Short URL: http://cssn.in/ja/027

I’ve been sitting on this little idea for a while and as a bit of fun I finally got around to putting it together and properly testing it. Basically on an iPhone with geolocation support (3.0+), I have set up a little web app that will get the speed from the GPS and move the speedometer needle according to your current speed in kilometres.

But speed returns null?

When I originally played around with the geolocation API on the iPhone checking the speed attribute always returned null, what I failed to actually do was test this value while actually moving. The speed attribute is capable of getting speeds as low as 2km/h so walking with the phone will start to register speeds.

So we can get the speed let’s use it

if(navigator.geolocation) {
    navigator.geolocation.getCurrentPosition(getSpeed, handleError);
}
function getSpeed(pos) {
    updateStats(pos);
 
    var coordsListener = navigator.geolocation.watchPosition(updateStats, handleError);
}

Here we get the current position and upon success tell it to execute the getSpeed function. Inside that function I call another function which does all the hard work which I’ll explain below, next I call the watchPosition method and pass it the same updateStats function so we can get constant updates from the GPS about our speed and adjust our speedometer needle.

function updateStats(pos) {
    var speed = pos.coords.speed,
         speedVariation = 3.6,
         currentSpeed = Math.round(speed*speedVariation),
         angleVariation = 0.8,
         initSpeedAngle = -105,
         speedAngle = initSpeedAngle + (currentSpeed * angleVariation);
 
    needle.style.webkitTransitionDuration = '500ms';
    needle.style.webkitTransform = "rotate(" + speedAngle + "deg)";
    speedVal.textContent = currentSpeed + "km/h";
}

var speed = pos.coords.speed,
     speedVariation = 3.6,
     currentSpeed = Math.round(speed*speedVariation);

When I get my initial position and my subsequent position updates through the watchPosition method, I access the current speed, in metres, through the coords attribute. To work out the rough speed I times the speed by the speedVariation var which is 3.6 which will give me the speed in km/h, for miles/hour the variation is 2.237. I do this calculation inside the Math.round function so I get a whole rounded number with no decimal places.

var angleVariation = 0.8,
     initSpeedAngle = -105,
     speedAngle = initSpeedAngle + (currentSpeed * angleVariation);

To calculate the corresponding angle to the equivalent speed we are currently getting from the GPS I had to work out the angle variation per kilometre. I knew there was 16° between each 20km/h block. The angle variation then could be worked out to be 0.8° per kilometre, I also needed to have the starting angle of 0km/h and that is exactly -105° from our middle point. With those 2 values plus the currentSpeed I could then work out the angle so the speedometer needle could be correctly rotated to the right spot.

needle.style.webkitTransitionDuration = '500ms';
needle.style.webkitTransform = "rotate(" + speedAngle + "deg)";
speedVal.textContent = currentSpeed + "km/h";

To move the needle when the speed changes and to make that change animate between the two points I use CSS3 transforms and transitions. By setting our -webkit-transition-duration any changes done using the -webkit-transform property will be transitioned smoothly between the current angle and the new angle. The last bit is just to print out the speed so we can compare the needle position to the actual speed being read.

Some CSS3

I’ve added some extra CSS3 to the speedo including animations and box-shadow

#dial #needle
{
    -moz-box-shadow: 1px 1px 3px #ffd712, -1px -1px 3px #feb018;
    -webkit-box-shadow: 1px 1px 3px #ffd712, -1px -1px 3px #feb018;
 
    -webkit-animation-name: speedorgo;
    -webkit-animation-duration: 2s;
}

To add the slight glow around speedo needle by using a dual box-shadow so it appears on both edges. The -webkit-animation- properties allows me to specify a predefined animation that can be applied to different elements.

@-webkit-keyframes speedorgo {
    0%   { -webkit-transform: rotate(-105deg); }
    20%  { -webkit-transform: rotate(41deg); }
    100% { -webkit-transform: rotate(-105deg); }
}

By using webkits @-webkit-keyframes rule and giving it a unique name which we applied to our speedo needle in the previous CSS using the -webkit-animation-name property we can do some pretty cool animations. Inside this animation rule I set up the animation to rotate any element it’s applied to to go from -105° to 41° then back to -105° when you rotate the phone into landscape mode it’ll trigger the animation and do the animation over a 2 second period.

Pfft! Who needs the internet…

Well technically we initially need the internet but after we load the web app for the first time no connection is required for this to work. By taking advantage of the application cache we can store all our assets on the phone, and since the GPS can still work without a network connection the speedo will still function fine.

A clear sky

In order to pick up a consistent speed reading from the GPS you will need to have the phone with a good clear view of the sky. I’ve found when using it while walking the speed reading will fluctuate quite a lot, going from 0 to the actual speed your doing and back to 0 and back up etc. It becomes more reliable the faster you are moving. I’m sure with some adjustments to the code getting a more consistent speed reading will be possible.

Go forth and hack

We have a fun little tech demo that shows what can with some simple JavaScript and CSS3. I don’t see why this couldn’t work on an Android, Palm Pre or a Blackberry with the new webkit browser, all of these should or should very soon support the features required for the web app to work. If you get this working in any other smart phone please leave a comment.

Short URL: http://cssn.in/ja/024

Web Notifications allows users to get updates on a webpage even if they’re not looking at it, shown to them through small notification boxes, think growl. This opens up some great potential for the current web apps out there. When you get a new email it could popup a little notification much like our desktop email clients do now or your twitter page could let you know when new @replies have come in, the possibilities are endless.

Interaction with your web app no longer needs the focus of the user to be informed that something has occurred, I know I would find notifications very useful.

Since this is a proposal and neither a working draft nor an agreed upon API, anything written about in this article is almost guaranteed to change. I will however try to make updates when changes are made. We have our first bug. If you’re using the latest dev version (5.0.317.2) Web Notifications will crash the browser, all previous versions still work fine.

You’ve got mail

I’ll go through a few examples I have put together on how to setup and start using notifications today.

This is what a notification looks like using the createNotification() method

Everyone loves the classic “you’ve got mail” voice, so let’s go through how to do that with Chromes Web Notifications.

TCNWN.myNotifications = window.webkitNotifications;
 
TCNWN.setup = function() {
    if(TCNWN.myNotifications.checkPermission() === 1) {
        // 1 = Permission is uknown so we request permission
        TCNWN.myNotifications.requestPermission();
    } else if(TCNWN.myNotifications.checkPermission() === 0) {
        // 0 = Permission has been granted to show notifications
    } else {  
        // 2 = Permission has been denied	
    }
};

A few things are happening here, for notifications to ever work you need to ask the user for permission. So we use the checkPermission() method to see what status web notifications are in and act on the status accordingly. Once permission has been granted notifications can then be used. Update: checkPermission() has been changed to permissionLevel() in the spec, this hasn’t been pushed out in any release of Chrome so checkPermission() still works.

A bizarre bug with web notifications is asking for permission by calling the requestPermission() method within the page will throw a security exception and won’t display the permission window where the user can either deny, allow or ignore the notifications request. To get around this I have to run the requestPermission() method as either a javascript: URL as this code only works when run in the address bar a javascript: link or by using an onclick function, but still cannot be called programatically (see Issue 31736). That’s why you need to click the first link in the demo. Once permission has been granted we no longer need to resort to that god awful hack, hopefully this is fixed ASAP. You’ll also notice the notifications object is prefixed with webkit, for similar reason why they prefix new CSS3 properties.

Once permission is allowed the requestPermission() method has a callback parameter where we can setup all our notifications. In this case we pass a function to display our got mail message.

TCNWN.gotMail = function() {
	if(TCNWN.myNotifications.checkPermission() === 0) {
		TCNWN.notification = TCNWN.myNotifications.createNotification(
			"http://www.thecssninja.com/demo/web_notifications/icon.png",
			"You've got mail",
			"The CSS Ninja has sent you an email"
		);
		TCNWN.notification.ondisplay = function() {
			var audio = new Audio("youvegotmail.mp3");
			audio.play();
			window.setTimeout("TCNWN.notification.cancel()", 5000);
		}
		TCNWN.notification.show();
	} else {
		alert("You need to allow web notifications for this to work");
	}
};

In the callback function we create our new notification object using createNotification() method which accepts an icon url, title and body text. To display nothing for any one of these parameters passing in empty quotes (“”) will work, otherwise it will display undefined. We then attach an ondisplay event listener so we can run some code when the notification displays. For this demo we load an mp3 to play “you’ve got mail” using HTML5 audio. We then create a setTimeout function to close the notification after 5 seconds. Lastly we execute the show() method so the actual notification displays.

Custom notifications

Along with the createNotification() we also have the createHTMLNotification() method which allows us to pass an url to a html page to be displayed as the notification. The second example on the demo page will load a notification that fetches a new tweet every 15 seconds and dynamically updates the content.

Using createHTMLNotification() method, we can pass a url to be loaded in the notification window

TCNWN.loadTweet = function() {
    if(TCNWN.myNotifications.checkPermission() === 0) {
        TCNWN.notification = TCNWN.myNotifications.createHTMLNotification(url);
        TCNWN.notification.show();
    } else {
        alert("You need to allow web notifications for this to work");
    }
};

The only difference here is we specify 1 parameter for the createHTMLNotification() method which is the url for the notification we wish to display. I won’t be going into detail on loading the tweets, to touch on it quickly it uses a JSONP call.

Some observations

Since playing around with this and trying to figure out how it works I have come across some quirks/bugs.

If you go to the first example that does the “you’ve got mail” notification and click back in the browser before the audio finishes playing, it will stop the audio and the setTimeout function that closes the notification will never fire.

As discussed earlier in the article you can’t actually request permission to display web notifications from within your code, you have to create a javascript: link that will execute the code. I tried programmatically changing the window.location to a JavaScript url which would fire the requestPermission() method but that wouldn’t work.

Bringing focus back to the window that called the notification, as stated in the proposal by using window.opener.focus(), doesn’t currently work.

Finally the last quirk I came across with the twitter demo is that for some tweets with long unbroken strings it will cause the notification window to flicker uncontrollably. Setting white-space: pre-wrap to force long string to be broken can help fix the issue.

Looks promising

Web notifications do look like a promising addition to the browser land and can create some really useful feedback to a user. With today’s web applications pushing the limits of the current technology available in the browser, I’m sure many developers will embrace web notifications in clever and exciting new ways.

I have updated my previous drag and drop upload demo to reflect the API changes, as of Firefox 3.6b3 the API supports both the original API and the updated one. The older model will eventually be dropped, it’s only in there for legacy purposes. To use the demo you will need Firefox 3.6 installed. You can also watch the screencast of it in action.

The biggest change is with the file handling, it is now processed asynchronously with progress events so we can attach listeners. The advantage of this is if a user drags in many files or a large file the UI won’t be locked up while it’s processing the data, much like XmlHttpRequest works.

The File object

The File object has been updated to reflect the new specs changes and has deprecated all the previous methods we used to get the file in various formats e.g. getAsDataUrl(), getAsText(), getAsBinary(). We now handle these methods in the new FileReader object.

It has also renamed the 2 properties for accessing the files name and size from fileName/fileSize to name/size respectively.

The FileReader object

This new object allows us to asynchronously read the contents of a file from a drop event.

var reader = new FileReader();
 
reader.addEventListener("loadend", TCNDDU.buildImageListItem, false);
reader.readAsDataURL(file);

Instead of locking the UI while we wait for it to loop through all the dropped files and then convert them to a DataUrl. The FileReader does this asynchronously. We attach to the onloadend event handler which will fire once the current file has been read into the result attribute. Upon the event firing we then take the event result and add the DataURL to the source of the image to be displayed to the user while it uploads.

Send the binary data

Once we have the file we send it to be processed for an XHR call so we can upload it to the server. Same as above we need to create a file reader and attach to the onloadend event which we then pass to the sendAsBinary() method.

var getBinaryDataReader = new FileReader();
 
getBinaryDataReader.addEventListener("loadend", function(evt){xhr.sendAsBinary(evt.target.result);}, false);
getBinaryDataReader.readAsBinaryString(file);

Similar code we used for the image display handling, but we use the readAsBinaryString() method to return the files binary data for uploading.

Further reading

As the 3.6 final release date is coming closer Mozilla has been ramping up demos and documentation about the File API. Some good documentation on handling files in web applications.

The hacks blog has recently put up some great information about the File API along with an excellent demo extracting EXIF data from an image.

Now we just need webkit to push out the File API to their nightly builds.

In conjunction with Mozilla’s official announcement for the Web Open Font Format (WOFF) and continuing the wanky tradition of removing vowels from web app names, I introduce font dragr.

What is it?

Font dragr is an experimental web app that uses HTML5 & CSS3 to create a useful standalone web based application for testing custom fonts, once you visit it for the first time you don’t need to be online to use it after the initial visit. It allows you, in Firefox 3.6+, to drag and drop font files from your file system into the drop area. The browser will then create a data URL encoded copy to use in the page and render the content in the dropped font.

See it in action

Encoded files

I went about testing out a few theories on how I could dynamically add a dropped font to be used in the page. I saw this article on embedding custom fonts using a base64 encoded string. In the file API we have the getAsDataURL() method to return a file as a data url for using in a page, I used the same method in my drag drop upload demo to display the images.

Inserting into the stylesheet

The next hurdle was taking that data url and inserting it into the style sheet referenced on the page.

var styleSheet = document.styleSheets[0],
	fontFaceStyle = 
	"@font-face{font-family: CustomFont;src:url("+files[i].getAsDataURL()+");}";
 
styleSheet.insertRule(fontFaceStyle, 0);

In the above code we reference our style sheet using document.styleSheet[0]. We then build our style from the dropped file that we want to insert, notice the files[i].getAsDataURL() is where the magic happens and the current file is converted to a dataURL. We then use the insertRule method to prepend it to the style sheet.

Getting file information and applying the font

We also get the fileSize of the font and the fileName so we can populate the list item that we create on drop. With the file name I also do some crude validation and I also sanitise the file name in case there is any non alpha numeric characters, it will stop the font from being applied to the container if we have invalid characters.

acceptedFileExtensions = /^.*\.(ttf|otf|svg|woff)$/i
 
droppedFileName = droppedFullFileName.replace(/\..+$/,"");
droppedFileName = droppedFileName.replace(/\W+/g, "-");

For the validation I have a regexp of accepted file extensions so it will only accept font types that work in Firefox. I remove the file extension from the fileName and then replace any non alphanumeric characters, \W, with hyphens.

Once we have a semi-friendly name we use that to apply the font family style to the newly created list item and the content container.

displayContainer.style.fontFamily = droppedFileName;

International font friendly

Dragging in an international based font file will cause the text to render in a default sans serif font. To fix that I have made the main content area editable, you can type some text in your own language which should render in your international based font, this hasn’t been thoroughly tested. I would appreciate any feedback on using this demo with international fonts.

Work in progress

I am still very much actively refining and adding more features to this web app. If you have any of your own features/ideas please feel free to suggest/request any improvements or changes. Some I’m working on now.

• Using localStorage object to store users dropped fonts and save edits to main content area. Main content edits are now stored in localStorage, hit size limit capacity with dropped fonts will look into webDB for font storage.
• Better indicating to the user that the content can be edited
• Making the drop area highlight on drag

I built this to fill a need I had, to quickly test custom fonts, and the idea has grown in to something much bigger and better than I thought it would be. I can see this as not only something cool to show off where HTML5 is heading but something genuinely useful.

I did a post a while back on how Google Chrome is changing the browser, the landscape is rapidly progressing thanks to Google and the likes of Mozilla, Webkit & Opera. This plugin helps push that final frontier into fruition bringing the next set of tools to all major browsers.

This demo was slightly modified from the awesome work of http://iterationsix.com/posts/16 particle fountain.

How does it work?

The above demo uses the HTML5 canvas tag to simulate particle effects. If you load this in IE you will be prompted to install Chrome Frame. Setting up a site to make it render using Chrome Frame is a simple meta tag.

<meta http-equiv="X-UA-Compatible" content="chrome=1">

Look familiar? It’s the same meta tag that IE uses to force IE8 to render in compatibility mode.

If IE goes to a site that has this meta tag it will kick-in and render the page using Chrome Frame giving the full power of Google Chrome in IE. Pretty simple and incredibly powerful.

IE8 vs IE8 with cf: protocol to force use of Chrome Frame

Prompt the user to install Chrome Frame

What if the user doesn’t know about or have the Chrome Frame installed on their machine? There’s a solution for that. Using a script available on Google Ajax APIs

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/chrome-frame/1/CFInstall.min.js"> </script>
 
<script type="text/javascript">
CFInstall.check();
</script>

The above code will check if Chrome Frame is installed if not it will prompt the user to install it by loading up an iframe with the Chrome Frame site. The check method gives you quite a few options all of them are optional the previous link gives a good run down of all the options and what they do.

Force it

If your are keen to use it before sites start adding the meta tag you can force the site to render using Chrome Frame by appending the cf: protocol to the beginning of any url e.g. cf:http://bespin.mozilla.com/ if loaded in IE with Chrome Frame installed it will force the website to render using the Chrome engine.

Early stages

Right now this plugin is in early development stages but I’m sure it will move along rapidly to coincide with Google Wave public release.

This is truly an exciting plugin that opens the flood gates to a massive user base being able to use the latest and greatest web apps.

One of those powerful things we can do with it is create a file uploader where the user can drag & drop multiple files from their desktop straight into the browser avoiding the previous method of using the file input creating the ultimate killer feature that browsers so badly need.

The below demo only works in Firefox 3.6 Alpha 1 if you don’t want to install it you can watch the screencast below.

Drag & drop it like it’s hot

Now I’m sure a few people would have seen this functionality already if they watched the Google Wave presentation where they demonstrated drag and drop file uploading, but they used Google Gears to accomplish this. They did mention they will be working on a draft spec to get this functionality into HTML5. This hasn’t happened yet and instead Arun Ranganathan of Mozilla wrote the first draft spec for such functionality to be possible.

Video will automatically start at 15m22s, where the drag drop is shown

The File API

The File API is what makes this whole thing possible, on the dataTransfer object it has been extended with the file attribute so it can read and convert the files you are dropping which then sends the file information as binary using an xhr upload attribute creating a desktop like behaviour but in the browser, opening great possibilities and much needed functionality that a user will find more intuitive.

XMLHttpRequest 2

The second revision of the XMLHTTPRequest specification adds further functionality so we can actually send our dropped files to the server asynchronously. There are several additions which I use in this demo such as the upload attribute and the progress events like progress and load. With those events we can give the user some detailed feedback such as a percentage loader used in this example.

How it works

This example uses a few emerging technologies such as xhr2, local file access and the drag and drop API. The order in which the events happen are as follows:

• The user drags images from their desktop to the drop area in the browser and fires the TCNDDU.handleDrop function.
• The dataTransfer object passes through the local files dragged over through the files attribute
• Using the getAsDataURL method we can convert the file to a base64 encoded string create an image and sets its source to that string.
• The file is then passed into an xhr request where we use the new sendAsBinary method available since Firefox 3.0 and pass in the file as binary data using the getAsBinary method
• We attach some progress events to the upload attribute so we can create a progress bar with percentage feedback and a load progress event so we can remove the progress bar once the image has uploaded successfully

I’ll go through some of the code in the demo to explain a few things in more detail.

for (var i = 0; i < count; i++) {
	domElements = [
		document.createElement('li'),
		document.createElement('a'),
		document.createElement('img')
	];
 
	domElements[2].src = files[i].getAsDataURL(); // base64 encodes local file(s)
	domElements[2].width = 300;
	domElements[2].height = 200;
	domElements[1].appendChild(domElements[2]);
	domElements[0].id = "item"+i;
	domElements[0].appendChild(domElements[1]);
 
	imgPreviewFragment.appendChild(domElements[0]);
 
	dropListing.appendChild(imgPreviewFragment);
 
	TCNDDU.processXHR(files.item(i), i);
}

This for loop is inside the TCNDDU.handleDrop function which will loop through the files, the count var in the for loop is pointing to event.dataTransfer.files.length so we know how many files we are working with.

domElements[2].src = files[i].getAsDataURL();

This line sets the source of the image as a base64 encoded string so we can display the local file to the user straight away.

fileUpload.addEventListener("progress", TCNDDU.uploadProgressXHR, false);
fileUpload.addEventListener("load", TCNDDU.loadedXHR, false);
fileUpload.addEventListener("error", TCNDDU.uploadError, false);

These lines are in the TCNDDU.processXHR that gets fired for each file dragged into the window. The fileUpload points to a new XMLHttpRequest().upload which we attach a few event listeners for progress, load and error so we can give useful feedback to the user.

xhr.open("POST", "upload.php");
xhr.overrideMimeType('text/plain; charset=x-user-defined-binary');
xhr.sendAsBinary(file.getAsBinary());

Here we post the data to the PHP file for possible further processing etc. We also use the overrideMimeType method to user defined binary and finally use the new sendAsBinary method which has the local file passed in as binary.

TCNDDU.uploadProgressXHR = function (event) {
	if (event.lengthComputable) {
		var percentage = Math.round((event.loaded * 100) / event.total);
		if (percentage < 100) {
			event.target.log.firstChild.nextSibling.firstChild.style.width = 
			(percentage*2) + "px";
 
			event.target.log.firstChild.nextSibling.firstChild.textContent = 
			percentage + "%";
		}
	}
};

For the progress event we attached earlier we can check if it will return the right information so we can do a progress bar by checking for the lengthComputable property if that’s available we know the progress event will return two values of loaded and total from there we can work out the percentage that has loaded and adjust our visual cues, in our case a progress bar.

event.target.log.firstChild.nextSibling.firstChild

This line allows us to get access to the current container of the image that is being calculated. event.target will always point back to the xhr object in the TCNDDU.processXHR we added a link to the container by adding log to event.target and pointing it to container variable.

Not without issues

There are two issues I came across with this demo and most likely are something I have done wrong or it could possibly be a bug.

The first issue I came across was the event.target.log suddenly losing its reference to itself and no longer being able to update the progress bar as the link to the current container is suddenly undefined, this also causes the load event to never get fired and the progress bar never gets removed.

The other issue is the progress event won’t fire if the file size is below around 140-150kb so no feedback will be given to the user. I’m not sure if this is intentional or a bug. I hope it’s the latter as feedback on any sized file would be necessary. You can see this happening on the toucan image in the screencast above.

I took a sceencast of the issues you can watch below.

Heading in a great direction

This functionality is exactly what the web needs going forward and will hopefully see it in other browsers very soon, Google Wave could benefit from this greatly and would make one of their coolest features work without any need for external plugins.

Resources

This article was inspired from a few examples I have seen throughout my searches for such functionality, what sparked my imagination and got me developing a drag and drop uploader was this demo found on the Mozilla bug list.

A few people have already figured out and demonstrated multiple file uploading in safari 4 and a similar version that works in Firefox 3.5, although you can’t select multiple files you can upload more than one at a time. That example I used a slightly modified version in this demo to send binary data to the server.

There is also another great article on uploading files and posting forms using Ajax. This articles demo works in Firefox 3+.

This demo will need the iPhone 3G with the 3.0 firmware update or Firefox 3.5 in order to work. The iPhone will give the better results as it has access to the GPS where as Firefox depends on the hardware available.

Some hurdles

You may have noticed that I’m not using Google or Yahoo Maps APIs to plot my location, this is due to both having restrictions on using it in conjunction with real time locations. In Google Maps Terms of Use.

use the Service or Content with any products, systems, or applications for or in connection with (i) real time navigation or route guidance, including but not limited to turn-by-turn route guidance that is synchronized to the position of a user’s sensor-enabled device; or (ii) any systems or functions for automatic or autonomous control of vehicle behaviour.

Yahoo’s terms are a bit different they still restrict use of real time location abilities to be no younger than 6 hours, essentially making the safari’s location awareness a no go zone for these 2 services.

…use the Yahoo! Maps APIs with location information that is less than 6 hours old and derived from a GPS device or any other location sensing device;

CloudMade to the rescue

Thanks to CloudMade who is putting a rock solid set of tools and API’s in various languages so we can access the OpenStreetMap map data. Only difference is that these maps are created by the community and are licensed under the Creative Commons Attribution/ShareAlike licence, version 2 which means there are no such restrictions that we would of had with Google or Yahoo maps. I highly recommend you read where they are heading in terms of their licensing and help in giving back to their community by creating maps.

How it works

Now we have a maps API where we won’t be abusing the terms of use by using it in conjunction with real time locations. We’ll get stuck into how to use the W3C Geolocation API.

Request the users location

navigator.geolocation.getCurrentPosition(success, fail);

The above line will try to obtain the users current location using the getCurrentPosition method this can be passed up to 3 arguments; the success callback function, the error callback function and the position options: enableHighAcurracy, timeout & maximumAge.

Upon successfully obtaining the users location the success function will get passed the position object which will contain the coords and timestamp attributes. The coords attribute is the one we need to extract information about the user location and has the following properties available:

• latitude
• longitude
• altitude
• accuracy
• altitudeAccuracy
• heading
• speed

navigator.geolocation.getCurrentPosition(success, fail);
// success callback, gets passed position object
success(position) // 'position' can be named anything
{
	alert("Your latitude: " + position.coords.latitude + "longitude: "
 		+ position.coords.longitude);
}

Not all of the geolocation information in the coords attribute is available to the iPhone, heading and speed currently return null but I suspect that both will be functional in the iPhone 3G S thanks to the compass and coreLocation updates. Both these attributes still return null on the iPhone 3GS which is surprising. Speed can alternatively be calculated by using the Haversine formula to obtain the distance travelled between two points which can then be used to compare time and distance to make a pretty accurate speed approximation.

The options available as the 3rd argument that can be passed to the getCurrentPosition method are:

• enableHighAccuracy
• timeout
• maximumAge

These options can help in forcing the error callback and having a fallback option if the request cannot be obtained before the timeout ends or the location wasn’t obtained within the maximumAge set. enableHighAccuracy will force the GPS to get the most accurate results possible this will take longer and chew through the battery.

navigator.geolocation.getCurrentPosition(success, fail,{maximumAge: 300000, timeout:0});

Both maximumAge and timeout are expressed in milliseconds. This is basically saying get the last known location that is no older than 5 minutes, if no position is found timeout immediately and fire the error callback function.

Updating location

Getting the users initial location is great and all but what we really need is a way to get constant updates of any changes in the users’ location. Thankfully the geolocation API also has the watchPosition method which will fire upon a change in the users’ location.

var updateLocation = navigator.geolocation.watchPosition(success, fail);

This, like the getCurrentPosition method, takes the same arguments the only difference above is that I have stored the watchPosition method in a variable, this is so we can cancel it at anytime if we no longer need to watch for any changes in position.

navigator.geolocation.clearWatch(updateLocation);

This will cancel the watchPosition and stop it from firing the success or error callback. It works in much the same way the clearTimeout method works for the setTimeout method.

Handling errors

If something goes wrong with obtaining the users location e.g. the user decides not to share their location to your web app. We have the error callback so we can handle the situations that might occur and present useful actions or information back to the user.

The PositionError interface has 4 possible scenarios:

• UNKNOWN_ERROR (code 0)
• PERMISSION_DENIED (code 1)
• POSITION_UNAVAILABLE (code 2)
• TIMEOUT (code 3)

We have 2 attributes on the error callback available which are code & message these will return either the code number 0-3 or the message.

navigator.geolocation.getCurrentPosition(success, fail);
// fail callback, gets passed error object
fail(error) // 'error' can be named anything
{
	switch(error.code) // Returns 0-3
	{
		case 0:
			// Unknown error alert error message
			alert(error.message);
			break;
 
		case 1:
			// Permission denied alert error message
			alert(error.message);
			break;
		... etc
	}
}

Just the beginning

The iPhone 3.0 release isn’t the only browser to support Geolocation API, currently Firefox 3.5, Opera 10 beta and Opera Mobile 9.7 beta though this is speculation. I’m sure the other browser vendors will follow in their new releases.

Documentation on the application cache feature supported in safari iPhone 2.1+ is scarce and of that documentation it doesn’t go into great detail. The best place to learn about this is on the Safari DevCenter under the mobile section, there it has 2 documents introducing the user to offline webapps; the first is a quick rundown on just the manifest file and the second article touches on a few more features available to offline webapps such as the javascript events for updating the cache when the user is online. We’ll delve into these later in the article but first let’s take a look at a working example.

To see the offline webapp in action, load the demo on your iPhone, then turn Airplane Mode on, re-open Safari and reload the demo. This time it will fetch the files from the cache that was created on the initial load.

How does it all work?

To get a basic offline webapp up and running is incredibly simple but it does have one caveat which tends to get a lot of people frustrated quickly when for some reason the offline feature isn’t working. We’ll explain that issue shortly.

The first thing we need to do is create what is called a cache manifest file which has references to all the resources we want to save. Whether it be JavaScript, CSS, images or html, below we can view the manifest file used in the demo.

CACHE MANIFEST
 
# Offline cache v1
# html files
article.html
 
# css files
assets/_styles.css
 
# js files
assets/_javascript.js
 
# images
assets/ico_ninja-star.gif

The manifest file is a simple plain text file that holds the file names you wish to cache, the paths are relevant to where you saved the manifest file which is recommended to be in the root of the site. This file will be saved as filename.manifest, where filename is anything you wish. Lines that start with a # are comments and are ignored by the cache.

Referencing the cache file

We now have our cache manifest file setup and named, the next thing we need to do is reference that file in the html so this offline access will function for the specified files in the manifest.

<html manifest="thecssninja.manifest">

The manifest file is referenced in the html tag through the manifest attribute and just points to the filename.

Now the one issue that catches a lot of people when trying this out is not setting up the mime type correctly in their chosen web server. Whether it be IIS, Apache or something else, you’ll need to make sure that the .manifest file is fed through as text/cache-manifest. For example in IIS the .manifest mime type is actually already declared to serve .manifest files as application/x-ms-manifest for offline webapps to work this will need to be changed to mime type text/cache-manifest.

For Apache you can add the text/cache-manifest to the mime.types file found in the conf folder in apache and add the following to the bottom of the file.

# html 5 application cache - offline access
text/cache-manifest			manifest

For IIS open up the IIS manager found in Control Panel > Administrative Tools > Internet Information Services double click the Mime Types icon in the manager and scroll down the list until you find the .manifest file and edit the mime type to have text/cache-manifest.

That’s it, to get a basic offline webapp to work is incredibly simple all it takes is the manifest file to specify which files to cache, declare it in on the <html> tag using the manifest attribute and you have yourself a site still accessible even if the user has no network connection.

UPDATE: GeoNomad in the comments suggested a great tool to make sure your manifest file is being fed through with the correct mime type, Web Sniffer. I put my manifest file through the Web Sniffer tool, you can see that the Content-Type is set as text/cache-manifest.

Updating the cache

If you want to update the cache you either need to change/add file references to the manifest and then tell the cache to update. Updating a file that the manifest calls will not make the cache reflect the changes. The mozilla developer article on applicationCache makes a good suggestion to version your manifest file as the JavaScript events described below will only fire if there is a change to the manifest file. To update the cache we have:

window.applicationCache;

This object has various stages depending on what the cache is doing which can be checked by using the .status method. There are 6 different stages:

• Status 0 (UNCACHED) is returned which means that there is no cache available
• Status 1 (IDLE) is returned means the cache you have is currently the most up-to-date
• Status 2 (CHECKING) is returned means there is a change in your manifest file and it is checking it for changes
• Status 3 (DOWNLOADING) is retuned means changes have been found and they are being added to your cache
• Status 4 (UPDATEREADY) is retuned means your new cache is ready to be updated and override your current cache
• Status 5 (OBSOLETE) is returned means your cache is no longer valid meaning it has been removed

These available statuses can be attached to the applicationCache object with event listeners so we can tell the web app what to do on what status. In our case we want to update the cache to reflect changes we have done.

var webappCache = window.applicationCache;
 
function updateCache()
{
	webappCache.swapCache();
}
 
webappCache.addEventListener("updateready", updateCache, false);

In the above example we attach an event listener to the applicationCache looking for the updateready status which means there is a change to the manifest file and our cache is ready to be updated we do so by using the swapCache() method.

There is 2 more event handlers which do not appear in the window.applicationCache.status these are part of the event summary. Those are error & progress. We’ll take a look at how to use the error event, the progress event is basically the same as the downloading event handler.

var webappCache = window.applicationCache;
 
function errorCache()
{
	alert("Cache failed to update");
}
 
webappCache.addEventListener("error", errorCache, false);

All the error event handler does is return the specified function we attached in the event listener when the cache is not available or does not exist.

Event summary

In the applicationCache we have various events available so when the cache is being updated, or as mentioned above when something goes wrong. We can attach to those events and keep the user informed on what is happening. These events will execute in specific order based on what is happening with the cache and therefore give us useful hooks to represent that back to the user.

Pete who commented below and needed a way of indicating to the user that the cache was downloading prompted me to look further into the events that get fired and which ones would be useful in this scenario. I created a demo which will indicate to the user that the cache is downloading by showing a loading icon and once the cache had finished downloading, the loader would be hidden.

The event order for this example was as follows:

• checking – The page loads and the cache is checked for any changes.
• progress – The download event actually gets fired before this but we don’t need to hook into that. The progress event will fire for each file that is referenced in your manifest until the cache has finished downloading.
• cached – The cache has successfully downloaded and the cached event is fired so we utilise that to hide the loader.
• updateready – This event is fired so we can then swap the old cache with the newly downloaded one.

In the above mentioned demo we also attached event listeners to the error and noupdate events so we can handle errors and if the cache is already up-to-date.

Is the user online

There is also a new method on the navigator object called onLine which returns a boolean value if there is a network connection or not.

navigator.onLine

In the article example the onLine method is used to update the title if the user is on/offline.

Only the beginning

The applicationCache is not yet finalised and is of course subject to change with newer and refined features. I’m sure there will be additions in the upcoming iPhone OS 3.0 release. If there are updates unfortunately these cannot be discussed until the NDA is lifted. But of course this won’t stop us speculating.

Some of the features available in applicationCache on firefox 3.1 and safari 4 will inevitably be added in future releases of the iPhone OS. Such as the NETWORK: and FALLBACK: sections in the manifest file, these allow for the developer to specify a file they wish to never cache or to have a file load if something fails with the first option.