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

Another demo, another bug

Everything I seem to investigate lately seems to present itself with an annoying bug/feature in various browsers. Last time it was the inconsistency between browsers and generated content on form elements. This time it is WebKit not being able to apply styles using the checked pseudo-class in conjunction with a general sibling combinator (E ~ F) or chained adjacent sibling combinator (E + F + F). Making it very hard, and probably the reason I haven’t seen a CSS solution that works in WebKit browsers. I did come across this demo but due to the bug mentioned above doesn’t work in WebKit browsers.

So I soldiered on and came up with a pretty decent attempt, and remember folks I’m not a designer so be kinder this time with design critiques all I’m doing is showing you how to do the technique . With that out of the way let’s dig into the inner workings and road blocks I faced.

General sibling combinators are flaky

The CSS3 selector module has a very useful addition to compliment the CSS2.1 adjacent sibling combinator. Unlike the adjacent selector the general selector gives us some flexibility in that it will match a sibling that isn’t immediately preceded by our first element.

Great, I have 3 elements an <input>, <label> & <ol> the general sibling combinator is the perfect tool to do things like input:checked ~ ol. Check Firefox, awesome works, Opera too! Woo! Surely WebKit will have this…nope nothing. Let me try input ~ ol, yep works across the board, *face palm*.

So I dug into WebKits bug tracker and came out with this bug which has been around since 2007. Stating that general sibling combinators in combination with dynamic CSS, ala :checked, won’t reflect changes. Nor will it do chained adjacent combinator which was going to be my next solution.

However doing :checked with a single adjacent sibling combinator works fine in post 2008 WebKit browsers. So using this information I went about and built a working demo that has good browser support.

The demo is built using an ordered list (ol) nested with further ordered lists to naturally represent a basic folder structure.

<ol>
    <li class="file"><a href="document.pdf">File 1</a></li>
    <li>
        <label for="subfolder1">Subfolder 1</label>
        <input type="checkbox" id="subfolder1" />
        <ol>
            <li class="file"><a href="">File 2</a></li>
            <li class="file"><a href="">File 2</a></li>
            <li class="file"><a href="">File 2</a></li>
        </ol>
    </li>
</ol>

As you can see, in order to get around the general combinator issue in WebKit based browsers I have switched the label to come first then the input so the “folders” could be expanded/collapsed by checking/unchecking the checkbox.

li input
{
    position: absolute;
    left: 0;
    margin-left: 0;
    opacity: 0;
    z-index: 2;
    cursor: pointer;
    height: 1em;
    width: 1em;
    top: 0;
}
li label
{
    background: url(img) 15px 1px no-repeat;
    cursor: pointer;
    display: block;
    padding-left: 37px;
}

To sit the input and label in the right visual order I absolutely positioned the input and applied a left padding to the label to push it out. That way changing the styles of the child ol, when the input is checked, can be done using the adjacent sibling combinator. I’ve also set the cursor to pointer when hovered over the input or label to visual show they’re clickable.

li input + ol
{
    background: url(toggle-small-expand.png) 40px 0 no-repeat;
    margin: -0.938em 0 0 -44px; /* 15px */
    display: block;
    height: 1em;
}

Unlike my custom radio and checkbox article where I added the background image on the label, this time I had to do some trickery and apply it to the direct sibling ol of an input. Applying a sprite image to the ol wouldn’t be possible in this situation due to it being applied to the ol which would make it difficult to effectively hide other images within the sprite image.

To position the ol correctly I use a negative margin to pull it into the right location so it will sit next to the label and underneath the invisible checkbox.

li input + ol > li
{
    height: 0;
    overflow: hidden;
    margin-left: -14px !important;
    padding-left: 1px;
}

To hide the sub folders so they don’t appear when the parent folder is collapsed I target the child list items and set them to a zero height and hide any overflow.

li label
{
    background: url(folder.png) 15px 1px no-repeat;
}
li.file a
{
    background: url(document.png) 0 -1px no-repeat;
    color: #fff;
    padding-left: 21px;
    text-decoration: none;
    display: block;
}

To differentiate between folders and files I applied a background image to either the label or to an anchor within a list item for files.

li
{
    position: relative;
    margin-left: -15px;
    list-style: none;
}
li.file
{
    margin-left: -1px !important;
}

To pull out the folder list items I apply a larger negative margin so the folder will line up with any of the file icons, and for file based list items I reset the left margin so they sit flush.

Change icon based on file extension

With some CSS3 attribute selectors we can determine an anchor links file format and change the icon accordingly.

li.file a[href $= '.pdf']     { background-position: -16px -1px; }
li.file a[href $= '.html']   { background-position: -32px -1px; }
li.file a[href $= '.css']    { background-position: -48px -1px; }
li.file a[href $= '.js']      { background-position: -64px -1px; }

Using the $= CSS attribute selector allows us to check the end of an attribute exactly ends in .pdf, .html etc.

If for some reason you attribute doesn’t end with your file extension, your anchor may have a query string on the end. We can still match file types.

li.file a[href *= '.pdf']   { background-position: -16px -1px; }
li.file a[href *= '.html']  { background-position: -32px -1px; }

The *= will match a substring that contains .pdf or .html anywhere within the attribute and if a href has a query string we can still match our file extension without issue. This does have the slight disadvantage that it will match it anywhere e.g. if you have a file called file.html.pdf it will match both file types and the one with the higher CSS specificity will be applied or incase of the example above their CSS specificity is the same so the html background will be applied.

Checkbox attributes

In the demo by default the first folder is open, this is done by adding the checked attribute to the checkbox which will trigger our styles thanks to the checked pseudo-class and reveal its sub files and folders.

We can also add the disabled attribute to the checkbox to stop a user from opening a folder as the input can neither be checked or unchecked.

Lastly using a combination of both disabled and checked will allow us to reveal the sub files and folders but not allow the user to close the top level folder.

Browser support

Based on testing this will work in any CSS3 selector supporting browser. The following have been tested and known to work

• Firefox 1+
• Opera 9.6+
• Safari 4+
• iPhone/iPod Safari
• Chrome 1+
• Android
• IE9+

This could very well work in IE8 but would require some JavaScript to get IE8 to interpret the checked pseudo-class, which I won’t be going into.

Right now I use conditional comments to hide the stylesheet from all versions of IE and another conditional comment to load the stylesheet for IE9 and greater.

<!--[if gte IE 9 ]>
    <link rel="stylesheet" type="text/css" href="_styles.css" media="screen">
<![endif]-->
<!--[if !IE]>-->
    <link rel="stylesheet" type="text/css" href="_styles.css" media="screen">
<!--<![endif]-->

Highly scalable

This technique will cater for a large amount of sub folders and files. It’s governed by your screen real estate and even then it’ll apply scroll bars to the document when the tree structure gets too long or wide.

Any questions/comments/suggestions leave a comment.

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

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

But you’re thinking I’m mad, there can’t possibly be any other way to trigger a pure CSS overlay.

Radio buttons?!

Yep this technique uses radio inputs along with the checked CSS3 pseudo-class, which I described in my custom checkbox/radio inputs article, to show/hide the futurebox modals.

<ul>
    <li>
        <label for="futurebox01">
            <img src="image.gif" width="100" height="102" alt="The CSS Ninja" />
        </label>
        <input type="radio" id="futurebox01" name="gallery" />
        <div class="overlay">
            <label for="close" title="Close futurebox">
                <img src="image.png" alt="The Css Ninja" width="469" height="500" />
            </label>
        </div>
    </li>
</ul>

The mark-up differs from the original futurebox. The overlay now needs to appear directly below the image, the images are wrapped in a label as well as the overlay, we set the “for” attribute on the label so we can check the radio without having to actually click the radio. We also use that to our advantage so we can actually close the modal once it’s been opened by having the large image wrapped in a label with a “for” attribute to a hidden radio button.

Having the same name value on all the inputs makes sure only one of the radio buttons can be checked at any one time.

ul li input { display: none; }
ul li input:checked + .overlay { display: table; }

Since we don’t actually want or need to see the radio button we hide it. As mentioned before the “for” attribute controls the checking and unchecking of the input.

Unfortunately due to a bug in IE (you’ll need to login to view it, or just change your UA string to googlebot ) only labels with text trigger the input. Since IE9 is the first IE to support the checked pseudo-class if this bug is fixed this technique will work, until then it won’t. Let’s hope a fix makes it into IE9 final release.

The second line uses the checked pseudo-class to apply display: table to the inputs direct sibling with a class of overlay.

.overlay
{
    width: 100%;
    height: 100%;
    position: absolute;
    top: 0;
    left: 0;
    display: none;
    z-index: 999;
    background: rgb(0,0,0);
    background: rgba(0,0,0,0.7);
}
    .overlay label
    {
        display: table-cell;
        vertical-align: middle;
        text-align: center;
    }

The overlay styles don’t differ at all to the original demo, except that instead of an anchor tag wrapping the image it’s now a label. When the input is checked the overlay sibling of that input becomes visible, by setting it to display: table, as shown in the previous CSS block. The label has display: table-cell applied to it so it’ll act like a table cell and naturally fill all height and width available to it. Applying vertical-align: middle will make the image vertically center and to horizontally center the image we take advantage of the fact that images are inline elements and just set the label to have text-align: center.

Not just for images

Since futurebox was only ever originally meant for loading images I thought I would extend this new version to also load static and dynamic content (iframes). In the demo the second listing shows 2 examples of static content and 2 examples of loading an iframe.

Static content

In order to show static content within a futurebox overlay the mark-up differs slightly.

<ul>
    <li>
        <label for="futurebox01">
            <img src="image.gif" width="100" height="102" alt="The CSS Ninja" />
        </label>
        <input type="radio" id="futurebox01" name="gallery" />
        <div class="overlay">
            <label for="close" title="Close futurebox">
                <span class="content01">
                    <span class="inner_content">
                        // content goes here
                    </span>
                </span>
            </label>
        </div>
    </li>
</ul>

Rather than have the image we have 2 spans, although 1 is fine I used 2 to make the scrolling look nicer.

.content01
{
        display: block;
        width: 460px;
        padding: 20px;
        background: #fff;
        color: #000;
        margin: 0 auto;
        text-align: left;
        cursor: auto;
        -webkit-border-radius: 10px;
        -moz-border-radius: 10px;
        border-radius: 10px;
}
    .content01 .inner_content
    {
        display: block;
        height: 500px;
        overflow-y: auto;
    }

The content span I apply a base width and some padding along with applying some CSS3 to give the modal some nice rounded corners.

The inner content span I set a fixed height and apply overflow-y to auto so any content that extends further will show a vertical scrollbar otherwise if the content fits it will hide the scrollbar.

The reason I use spans and not divs is because a label is a inline element and putting divs inside it is not only invalid but will also cause render issues in some browsers. So using a span and setting it to display: block handles that dilemma.

Change the height of individual modals

Since the base height of the static content container is quite high putting in a small amount of content will create alot of empty white space. You can get around it by targeting specific futurebox modals and set the height to something else.

#futurebox07 + .overlay .inner_content { height: 265px; }

Each input has their own id so the “for” attribute will work on the labels, we can then use that id to target specific modals and change their height.

It’s an iframe

Loading static content has a lot of great uses but sometimes only an iframe can handle some situations such as submitting a form within a modal or loading an external resource.

The first iframe example loads up my contact page, feel free contact me, so you can submit a form without affecting the modal or causing a post back on the parent page.

The second iframe loads a Google search for futurebox.

Since iframes are naturally inline placing it inside a label isn’t invalid and won’t cause any browser issues.

.overlay iframe
{
    background: #ffffff;
    border: none;
    padding: 10px;
    -webkit-border-radius: 10px;
    -moz-border-radius: 10px;
    border-radius: 10px;
}

To give the iframe the same padding and rounded corners as the images and static content modals, we add a few styles to reset the iframes border, add some padding, set the background and apply some border-radius values to give it rounded corners.

Close buttons

I’ve also added close buttons on the static and iframe modals, these are purely for show and don’t technically close the modal since clicking anywhere on the overlay will close the modal. It’s purely there to give the user the feeling they are actually closing something by clicking a button, rather than the background.

<label for="close" title="Close futurebox">
    <span class="content01 content02">
        <strong class="closebutton" title="Close futurebox">X</strong>
        // content
    </span>
</label>

To add the close button I’ve added a strong tag within the content container. I’ve just added an X inside to represent the close action and added a title attribute so it makes sense.

.closebutton
{
    background: #606061;
    color: #FFFFFF;
    cursor: pointer;
    height: 24px;
    line-height: 24px;
    overflow: hidden;
    position: absolute;
    right: -12px;
    text-align: center;
    top: -12px;
    width: 24px;
    -webkit-border-radius: 12px;
    -moz-border-radius: 12px;
    border-radius: 12px;
    -moz-box-shadow: 1px 1px 3px #000;
    -webkit-box-shadow: 1px 1px 3px #000;
    box-shadow: 1px 1px 3px #000;
}

Since we have fixed width content it makes it possible to position it correctly while still keeping the futurebox horizontally centred, that’s the reason there is no close on the image based modals as the width can vary from image to image. To sit the button to the right of the futurebox I absolutely position it and set top and right to -12px so it will sit slightly offset from the container.

To create the circle effect I set the width and height to 24px and apply a border-radius of 12px for either side which will create our circle.

.closebutton:hover
{
        background: #318DF2;
        text-shadow: 1px 1px 1px #ccc;
}

When the user hovers over the close button I change the background-color and give the X a light drop shadow.

Mix it up

We can mix up the styles of the futurebox by adding a class to the parent ul, in the last list example I’ve added a class to do just that.

.theme01 .overlay
{
    background: none;
}
    .theme01 .overlay label > img,
    .theme01 .overlay iframe,
    theme01 .content01
    {
        border: 1px solid #ccc;
        -moz-box-shadow: 5px 5px 10px #000, -5px -5px 10px #000;
        -webkit-box-shadow: 5px 5px 10px #000, -5px -5px 10px #000;
        box-shadow: 5px 5px 10px #000, -5px -5px 10px #000;
    }

Instead of a semi transparent rgba background, I’ve reset the background to none and applied a dual box shadow to the overlay items.

Love it, hate it?

Think it’s awesome, think it’s an abomination? Let me know what you think or if you have any suggestions on how you think it could work better make sure to leave a comment.

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

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

It’s a bug, no it’s intended…well actually it’s still a draft

So upon my initial investigation of how doing something like this would be possible, I came across what I initially thought was a bug with Firefox and IE8. Applying CSS generated content to form elements doesn’t work, turns out Firefox and IE8 are following the CSS3 draft specification as specified in the CSS3 Generated and Replaced Content Module.

The box model defines different rules for the layout of replaced elements than normal elements. Replaced elements do not have ‘::before‘ and ‘::after‘ pseudo-elements;…

Form elements fall under the “replaced elements” category and therefore don’t allow :before and :after pseudo-elements on them. However Safari, Chrome and Opera all allow generated content on form elements. Further to the odd behaviour Chrome and Safari will only apply generated content on checkboxes, radios and file inputs whereas Opera will allow it for all form elements, see test case.

You can see my initial attempt at creating custom radios and checkboxes. This applied the generated content directly to the inputs themselves. Open up the demo in Safari or Chrome to see it working. This presented yet another problem this time with Opera, clicking the radio or checkbox directly would never actually check the box whereas with Chrome and Safari the box would be checked and the custom replacement would change state accordingly. But if you clicked the label, which uses the for attribute to create the relationship to the corresponding input, it would check the input in Opera and change the custom check state correctly.

I then thought I would see if I could fix it by using some JavaScript to check the input onclick, this worked for Opera but stopped it working in Chrome and Safari as it was putting it in an indefinite indeterminate state, as it was checked then quickly unchecked by the JavaScript.

document.body.onclick = function (evt) {
    var node = evt.target;
 
    if(node.nodeName === "INPUT") {
        var isChecked = node.checked;
        (isChecked) ?
            isChecked = false :
	    isChecked = true;
    }
}

As there was no safe obvious way that didn’t involve browser sniffing or using bad object detection to determine if the browser behaved in this way. And the fact it was taking away from the whole point of this demo, to create a CSS only solution for custom forms, I scrapped my idea and went back to the drawing board.

Selectors, pseudo-classes & pseudo-elements

As you can see from the demo each radio and checkbox is replaced with a custom one. The difference here from my initial attempt, and to get around the fact you can’t apply generated content to form elements consistently, is to apply the generated content to the label rather than the input itself, and using some clever selectors I can determine the state of the radio/checkbox is in and adjust the custom replaced one accordingly. I also set the original input opacity to 0 so it won’t show through our custom one.

<p>
    <input type="radio" value="male" id="male" name="gender" />
    <label for="male">Male</label>
</p>

The HTML isn’t bloated and needs no extra mark-up

p:not(#foo) > input + label
{
    background: url(gr_custom-inputs.png) 0 -1px no-repeat;
    height: 16px;
    padding: 0 0 0 18px;
}

Basically this selector is looking for a label that is immediately preceded by a sibling input, that is a child of a paragraph that doesn’t have an id of foo and lastly it has the :before pseudo-element so we can add our custom radio input. The reason for the not selector is to not apply these styles in IE8, I’ll explain why further down.

Update: Thanks to Lea and Mr.MoOx for their suggestions this now uses a sprite image. Rather than insert the image in the content property, I apply a background and insert 3 non-breaking space characters, since the content property doesn’t accept named entities I used the unicode equivalent of \00a0. The reason I insert 3 is because Firefox 1.5 won’t show the full background unless I put 3 in there and using a fullstop and applying color: transparent doesn’t work in FF 1.5.

To get this working in older browsers such as Firefox 3 and down I use a negative margin to get it to sit in the right place. Support for absolutely positioned generated content was only recently added in Firefox 3.5+. I then adjust the newer browsers by offsetting the left value to be equivalent of the left margin.

Update 2: Thanks to Marius for demonstrating that the :before pseudo-element is superfluous and adding the background directly to the label itself with a few adjustments works just fine and removes the hacky need for using the content property with 3 non-breaking space.

I moved the previous demo and it’s source files to a legacy folder so you can still get them if you want.

Now all the radios have been replaced by our custom versions we need to be able to tell if the radio is checked so we can adjust our custom state.

p:not(#foo) > input[type=radio]:checked + label {
    background-position: 0 -241px;
}

Again this is the same as the previous selector with one difference, we add the :checked pseudo-class available in the CSS3 selectors module to determine the radios state in CSS and change it upon the user checking the radio.

Of course the control doesn’t end there we also utilise the :hover, :focus, :active & :disabled pseudo-classes to change the radio on hover, when it has focus (for keyboard support), when the input is active (click and hold your mouse cursor to see this state change) and when it’s disabled. Mixing this with the :checked pseudo-class lets us control all possible states of the radio input and gives us great control and flexibility that doesn’t require a mouse nor JavaScript to control the states.

p:not(#foo) > input[type=radio]:hover + label,
p:not(#foo) > input[type=radio]:focus + label,
p:not(#foo) > input[type=radio] + label:hover { 
    background-position: 0 -181px; 
}
p:not(#foo) > input[type=radio]:hover:checked + label,
p:not(#foo) > input[type=radio]:focus:checked + label,
p:not(#foo) > input[type=radio]:checked + label:hover  { 
    background-position: 0 -261px;
 }
p:not(#foo) > input[type=radio]:disabled + label,
p:not(#foo) > input[type=radio]:hover:disabled + label,
p:not(#foo) > input[type=radio]:focus:disabled + label,
p:not(#foo) > input[type=radio]:disabled + label:hover,
p:not(#foo) > input[type=radio]:disabled + label:hover:active { 
    background-position: 0 -221px; 
}
p:not(#foo) > input[type=radio]:disabled:checked + label,
p:not(#foo) > input[type=radio]:hover:disabled:checked + label,
p:not(#foo) > input[type=radio]:focus:disabled:checked + label,
p:not(#foo) > input[type=radio]:disabled:checked + label:hover,
p:not(#foo) > input[type=radio]:disabled:checked + label:hover:active {
     background-position: 0 -301px; 
}
p:not(#foo) > input[type=radio]:active + label,
p:not(#foo) > input[type=radio] + label:hover:active { 
    background-position: 0 -201px; 
}
p:not(#foo) > input[type=radio]:active:checked + label,
p:not(#foo) > input[type=radio]:checked + label:hover:active {
     background-position: 0 -281px; 
}

Another addition I have made to the CSS is also changing the input states when the user hovers, clicks or focuses on the label it will now change the input to reflect those actions.

IE8 is almost there

IE8 can do everything, except it doesn’t support the :checked pseudo-class and therefore makes this technique useless. So I use the not() pseudo-class, which IE8 doesn’t support, to work around this unfortunate lack of ability. Let’s hope IE9 adds the CSS3 selector module¹. This of course degrades nicely in non-supporting browsers and fallback to the browser default form elements.

¹ IE9 does support the CSS3 selector module so this technique has across the board support for all major browsers.

Accessible and friendly

CSS generated content doesn’t get in the way of a screen reader and they have a clear view of the form elements CSS generated content is no longer used it’s now a background image on the label rather than doing it on the generated content see update (I would appreciate any accessibility experts or screen reader users to please comment to correct or agree with me). Users, who have trouble operating a mouse or, like me, prefer navigating forms with the keyboard as it’s faster, aren’t left out. Tabbing through the inputs changes the states, pressing spacebar to check a radio or checkbox also changes the state. I also change the label colour and give it a text-shadow to give a nicer indication that the current input has focus.

The disabled and checked attributes work as intended with this solution and don’t require any trickery to achieve that.

<p>
    <input type="radio" disabled value="male" id="male" name="gender" />
    <label for="male">Male</label>
</p>
<p>
    <input type="radio" checked value="Female" id="female" name="gender" />
    <label for="female">Female</label>
</p>

As you can see from the above mark-up adding the disabled or checked attributes (disabled=”disabled” & checked=”checked” also work) will allow us to target those states using the :checked and :disabled pseudo-classes. As well as change the style if we use JavaScript to disable any inputs based on users actions.

Browser support and notes

As of writing the following browsers have been tested and known to work with the demo:

• Firefox 1.5+
• Opera 9.6+
• Safari 3.2+*
• iPhone/iPod Safari**
• Chrome 4+
• IE9+

Will run this demo through browsershots and update it accordingly if the browser support works in any lower versions mentioned

* This would work in Safari 3.2 except due to a bug. The checked pseudo-class will work just fine if it has the checked attribute on the input but won’t change the input state if the user checks the input with their mouse or keyboard (the actual input will check but the CSS state won’t update the custom input image).

* This now works in Safari 3.2 but, and a big but, the behaviour is quite bizarre. Clicking a radio or checkbox will change the custom state but clicking it again to uncheck won’t show until you have hovered away from or taken focus away from the input. If you have Safari 3.2 installed try the new demo to get a better understanding of what’s happening.

** To get the iPhone to work with this demo I had to apply the pointer-events CSS property. Since the input is actually sitting on top of the background image we no longer need to apply pointer events to the label.

p:not(#foo) > input + label
{
    pointer-events: none;
}

Here for legacy reasons no longer needed for iPhone support

Since having the generated content sit over the top of the actual checkbox, iPhone Safari needed a kick up the bum with the pointer-events property so we could click through the custom checkbox to the actual checkbox. Desktop Safari works fine without it.

Drawbacks

Resolved see update above. This technique has only 1 drawback I can think of, IE support is not a drawback for me, you can’t use a big sprite image to save all the radio and checkbox states, they need to be individual images. Using CSS generated content to insert an image doesn’t give you control of the image position like a background image does. The images are small in size and the initial load of each state shouldn’t be noticed. If however you wish to preload all the images take a look at my CSS based image preload technique. That technique will create quite a few http request depending on how many images you preload but since they’re small in size it shouldn’t be a major concern.

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

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.

There’s a better way

The article instantly got me thinking on a potential alternate method to accomplish the same task, but using a widely available CSS2.1 property. Which if possible will up the browser support significantly. Thankfully the idea actually worked.

CSS generated content

In CSS2 a content property was introduced, which in conjunction with the :before and :after pseudo-elements allows us to generate content in a document. The most interesting value that can be used with the content property is url() which allows us to pass an image.

content: url(img01.jpg);

That’s all great than we can add a single preloaded image using the content property but what about multiple images? That’s where the content property shows its true power, we can pass multiple url’s.

content: url(img01.jpg) url(img02.jpg) url(img02.jpg)

Brilliant, we can now preload multiple images using one line of CSS. We have all the benefits of the CSS3 method without the CSS3 and the Browser support grows exponentially.

• IE8+
• FF2+
• Safari 3+
• Chrome 1+
• Opera 9.62+

Putting it all together

Now we know how to preload multiple images using CSS2, lets put it all together:

body:after
{
content: url(img01.jpg) url(img02.jpg) url(img03.jpg);
display: none;
}

Instead of creating an empty div with a class on it, we can utilise the requirement of the :after (or :before) pseudo-element. This needs to be there for the content property to work. We apply it to generate the content after the body tag and then set it to display: none, that way the preloaded images aren’t shown but are still loaded. We know have a pure CSS solution that requires no mark-up.

Almost perfect

IE6 and 7 do not support CSS generated content and therefore will not preload any images, but that’s a minor trade off. Users of IE6/7 will just have to load the images when they are called rather than getting them from the cache.

A possible work around for their lack of support is to use conditional comments to load the images. This solution will require extra mark-up.

• Images are lazy loaded so they are only called when the futurebox overlay is activated.
• You can scroll through using next/previous buttons
• Use the keyboard to activate or close futurebox. Overlays can be opened in any order using the keyboard.
• Generated content for image description and counters
• CSS transitions for webkit browsers

It’s back with a vengeance

The overall markup hasn’t been altered all that much compared to the original it just adds useful functionality.

<ul class="overlay_container">
	<li class="overlay" id="futurebox_img2">
		<a href="#close" title="Close future box"></a>
		<p title="Image description goes here">
			<a href="#futurebox_img1" rel="prev" title="Previous">&lt;</a>
			<a href="#futurebox_img3" accesskey="3" rel="next" title="Next">&gt;</a>
		</p>
	</li>
</ul>

The anchor tag is now empty as we load the image as a background. A paragraph tag containing our next and previous links along with a title attribute so we can give the image a small description. The rest of the markup and foundation CSS stays pretty much the same.

Due to the complex nature of this updated version browser support is not a great as the original version. I will run this through a browser screenshot service and confirm browser support. If you come across any weird behaviour please make a comment about it.

Lazy loading images

In the original demo the images were loaded in the page essentially slowing down the load time. I’ve fixed that by using a lazy load technique, rather than having an <img> tag I set a background on the overlay anchor tag. The image is only downloaded when the user clicks on a thumbnail.

.overlay:target > a { background: url(gr_cssninja_lrg.png) 50% 50% no-repeat; }

We use the #futurebox_img2.overlay selector for all other overlays to target each item so we can change the background image correspondingly.

Scroll through images

I have added ability to scroll forwards and backwards through the images using buttons. These form part of the markup in each overlay item essentially just applying the previous images id in the href and the same for the next button.

<a href="#futurebox_img1" rel="prev" title="Previous">&lt;</a>
<a href="#futurebox_img3" accesskey="3" rel="next" title="Next">&gt;</a>

On each next/previous link we use the rel attribute so we can target it in CSS using attribute selectors

.overlay > p a,
.overlay > p a[rel=next]
{
	/* styles here */
}
.overlay > p a[rel=prev]
{
	/* styles here */
}

Keyboard navigation

Along with navigation buttons to scroll through the images you can use the keyboard to scroll through in any order. Closing futurebox is also possible using the keyboard. This is done using accesskeys and controls vary in different browsers and platforms.

<a href="#futurebox_img3" accesskey="3" rel="next" title="Next">&gt;</a>

Using the numbers you can scroll through up to 10 images using the 0-9 numbers and the corresponding keyboard combination in your browser:

• Firefox Windows: Alt + Shift + 0-9
• Safari/Chrome Windows: Alt + 0-9
• Opera Windows: Shift + Esc (This brings up a menu where you press the accesskey you wish to activate)

To close futurebox the access key is x. If you know of any other keyboard combinations, especially the Mac equivalents, I’ll update the article.

CSS generated content

It is now also possible to add a small description below each image using the CSS content property.

.overlay > a + p:after
{
	content: "No. " counter(futurebox) " " attr(title);
}

That snippet will get the paragraph tag that is a direct sibling of the anchor tag that is a direct child of the overlay class. Using the :after pseudo-element is how we can append the content after the paragraph.

We also use generated content to do automatic numbering of each image using the counter-reset and counter-increment properties in conjunction with the counter() function used in the content property.

.overlay_container 	{ counter-reset: futurebox; }
.overlay_container > li 	{ counter-increment: futurebox; }

We first reset the counter so we know it will start from 1, we also give it a unique name e.g. futurebox but this can be anything. Then in the following line we increment the counter for each list item inside the overlay_container, we use the child selector to make sure it only counts top level list items. The counter increment idea came from this blog post about doing a css based gallery (it’s in Russian so you’ll need to run it through a translator).

Animation without the JavaScript

One of the most requested features for futurebox was using webkits CSS transitions property to animate scrolling between images. So in this version I have added fading between image overlays. In Chrome and Safari we animate the opacity of the image so it will fade in upon activation.

.overlay a
{
	opacity: 0;
	-webkit-transition: opacity 1s ease;
}
.overlay:hover a { opacity: 1; }

To setup the transition we set the opacity to 0 and tell the transition to ease the opacity over 1 second. The reason I activate the transition on :hover and not :target is that target will not transition upon activation, whether this is a bug will take some further investigation.

To stop issues in browsers that don’t support transitions. I wrapped the transition styles in a media query.

@media (-webkit-transition) {
	/* Styles here */
}

This will only target webkit browsers that support the -webkit-transition property. When Firefox & Opera add support for transitions hopefully they will add support for this media query.

Another issue with transitions is hover will fail to activate if you launch futurebox using the keyboard, moving your mouse will then trigger the transition to execute. Only the initial launch is affected using the keyboard to scroll through other images will trigger the transition correctly.

Some things to note

While this does have good browser support it won’t work in IE and I don’t see it working without considerable use of hacks. There is however a fantastic article over at Carsonified on creating a lighbox effect that works in IE.

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.