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:before
{
    background: url(gr_custom-inputs.png) 0 -1px no-repeat;
    position: absolute;
    z-index: 2;
    left: 16px;
    content: "\00a0\00a0\00a0"; /* 3x   */
    overflow: hidden;
    width: 16px;
    height: 16px;
    margin: 0 3px 0 -16px;
}

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 there suggestions this now uses a sprite image. Rather then 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.

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:before {
    background-position: -32px -73px;
}

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.

input[type=radio]:hover + label:before,
input[type=radio]:focus + label:before { 
    background-position: -32px -19px; 
}
input[type=radio]:hover:checked + label:before,
input[type=radio]:focus:checked + label:before { 
    background-position: -32px -91px; 
}
input[type=radio]:hover:disabled + label:before,
input[type=radio]:focus:disabled + label:before { 
    background-position: -32px -55px; 
}
input[type=radio]:hover:disabled:checked + label:before,
input[type=radio]:focus:disabled:checked + label:before { 
    background-position: -32px -127px; 
}
input[type=radio]:active + label:before { 
    background-position: -32px -37px; 
}
input[type=radio]:active:checked + label:before { 
    background-position: -32px -109px; 
}

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.

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 (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 4+*
• iPhone/iPod Safari**
• Chrome 4+

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).

** To get the iPhone to work with this demo I had to apply the pointer-events CSS property.

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

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.

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+.

To continue my effort to accomplish tasks in CSS that are usually reserved for JavaScript, such as my Futurebox and CSS based iPhone orientation detection. I have developed a CSS based version of the popular “accordion effect” that utilises the webkit CSS transitions. Like the Futurebox demo I’m utilising the CSS3 :target pseudo class to know which item to show based the URI fragment identifier (the # in the url).

It should be noted that this works best in a webkit based browser such as Safari 3+, Chrome or iPhone. Other browsers that support the :target pseudo class will still function on the core level but won’t animate the showing and hiding. The following browsers have been tested and work with this demo.

• Firefox 1.5+
• Opera 9.6+
• Safari 3+
• Chrome 1+
• IE6+ – IE solution

The xhtml

<dl>
	<dt><a href="#Section1">Section 1</a></dt>
	<dd id="Section1">
		<p>
			Lorem ipsum dolor sit amet...
		</p>
	</dd>
	<dt><a href="#Section2">Section 2</a></dt>
	<dd id="Section2">
		<p>
			Lorem ipsum dolor sit amet...
	</dd>
	...
</dl>

We setup the accordion using a definition list to create the foundation so we can show and hide the definition data (dd) tag when the user clicks the anchor link inside the definition title (dt) tag.

The CSS

dl
{
	padding: 10px;
	min-width: 960px;
}
	dl dt
	{
		-webkit-border-radius: 5px;
		-moz-border-radius: 5px;
		border: 1px solid #cccccc;
		margin: 0;
	}
		dl dt a
		{
			color: #ffffff;
			font-weight: bold;
			text-decoration: none;
			padding: 10px;
			display: block;
		}
	dl dd
	{
		margin: 0;
		height: 0;
		overflow: hidden;
		-webkit-transition: height 1s ease;
	}
		dl dd p
		{
			padding: 10px;
			margin: 0;
		}
	dl dd:target
	{
		height: auto;
	}
 
@media (-webkit-transition) {
	dl dd:target
	{
		height: 6.667em;
	}
}

Pretty simple CSS involved, the dd tag is hidden by setting the height to 0 and the overflow to hidden.

-webkit-transition: height 1s ease;

This property on the dd tag lets webkit browsers know we wish to transition the height value over 1 second period using the ease timing function this transition will only happen when the height of the dd tag is changed. We can also express this in a long hand version.

-webkit-transition-property: height;
-webkit-transition-duration: 1s;
-webkit-transition-timing-function: ease;

To change the height we use the :target pseudo class to set the height of the dd tag to auto so the right content will show based the URI fragment identifier. For webkit browsers it’s a little different.

Webkit media queries

In webkit browsers there are additional media queries available so we can target browsers that support the extended features such as transitions and not affect other browsers. In this demo I use the @media (transition) media query.

Webkit implements this feature by using their -webkit vendor extension so the media query looks like the following

@media (-webkit-transition) {
	dl dd:target
	{
		height: 6.667em;
	}
}

Unfortunately setting the height of the dd tag to auto will not make it animate although this would be ideal and much more capable of catering for different sized content it’s not possible at the moment. For now we have to set the height to an actual value, to keep the height in line with any text resizing I set the height using em based value so if the user has larger text the height will adjust and won’t cut of any content. The height is 80px we divide by the base font size, which is 12, and we get 6.667em.

What about IE

Unfortunately IE doesn’t support the :target pseudo class and won’t work as describe above, but that didn’t stop me! Take a look at working example that functions in IE6 and up.

This is quite hacky and involves a bit of IE conditional comments.

IE xhtml

<dl>
	<!--[if IE]>
		<a href="#Section1" class="ie"><div>
	<![endif]-->
	<dt>
		<!--[if !IE]>-->
			<a href="#Section1">
				<!--<![endif]-->Section 1<!--[if !IE]>-->
			</a>
		<!--<![endif]-->
	</dt>
	<dd id="Section1">
		<p>
			Lorem ipsum dolor sit amet...
		</p>
	</dd>
	<!--[if IE]>
		</div></a>
	<![endif]-->
	...
</dl>

As you can see there is conditional comments so I can wrap the dt and dd tag in an anchor so we can get it functioning in IE using the following CSS. I also use the conditional comments to hide the anchor that appears in the dt tag only for IE browsers. IE6 was not functioning with just the anchor around the dd & dt so I added a div inside the anchor. In IE6 the first anchor would surround all the items, the div fixes that. Demo, demo files and example code has been updated to reflect that.

IE CSS

dl a.ie { text-decoration: none; }
	dl a.ie dd { display: none; }
 
/* Fix IE6 hover bug */
dl a.ie:hover { background-color: #606061 !important; }
 
dl a.ie dt
{
	color: #ffffff;
	font-weight: bold;
	text-decoration: none;
	padding: 10px;
	display: block;
}
 
dl a.ie:hover dd,
dl a.ie:active dd,
dl a.ie:focus dd
{
	height: auto;
	color: #cccccc !important;
	display: block;
}

Pretty simple stuff, set the text-decoration so the content isn’t underlined. We need to hide the dd tag as it causes issues in IE7 and below when trying to hover over any items below the first section. Next a background-color is applied to the :hover pseudo class of the surrounding anchor to fix an issue in IE6 that won’t trigger a hover unless something like a background-color is applied it. To make it work in IE we utilise the :hover, :focus and :active pseudo classes. That way when the user hovers in IE the content gets revealed, we also simulate a “click” by using the :active pseudo class. The :focus pseudo class allows us to make it work by using keyboard navigation, tabbing to the anchor will reveal the content. All the mark-up is XHTML 1.0 Strict complaint.

I think this is a pretty good attempt and best of all it works in all major browser so it can be potentially be used in a production environment.

writing-mode which is currently in the CSS3 draft specification allows us to accomplish text rotation without using propriety properties, effectively future proofing the concept as more browsers adopt the CSS3 draft spec.

The CSS

p { writing-mode: tb-rl; }

That’s it incredibly simple CSS technique that will eventually work with all browsers as their CSS3 support gets better. This is one of the handful of CSS3 supported properties in IE. The tb-rl value tells the browser to display paragraphs with the text flowing from top to bottom, right to left. Essentially rotating the text 90 degrees clockwise and aligning to the right.

This properties true intention is for displaying other languages in their correct “writing mode” such as Japanese right to left or Arabic & Hebrew which display right to left & top to bottom (rl-tb).

Support

At the moment IE is the only browser to support it starting from IE5.5 and up, IE8 adds further values through using the -ms extension. There are 4 values available from IE5.5+ and an additional 4 values for IE8+ through the -ms extension.

• lr-tb – This is the default value, left to right, top to bottom
• rl-tb – This flows the text from right to left, top to bottom
• tb-rl – Flows the text vertically from top to bottom, right to left
• bt-rl – bottom to top, right to left
• tb-lr – This and the followings value are only available in IE8+ using -ms-writing-mode. Text flows top to bottom, left to right
• bt-lr – Bottom to top, left to right
• lr-bt – Left to right, bottom to top
• rl-bt – Right to left, bottom to top

Rotate text in other browsers?

As stated in Snooks’ article we can do this in Webkit based browsers and Firefox 3.5+ using the transform property.

-webkit-transform: rotate(90deg); 
-moz-transform: rotate(90deg);

For both we need to use the vendor extensions -moz & -webkit. As for Opera it neither yet supports transforms or writing-mode properties but I’m sure that will change with the upcoming release of version 10.

In the article example we need to position the element differently for browsers that support the transform property compared to ones that support writing-mode as the elements rotated still exist as horizontal elements where as with writing-mode the element is truly rotated, see screenshot below.

Element that is rotated is outlined and highlighted, writing-mode on left transform on right

.datebox span:nth-child(3)
{
	right: 0px;
	top: 0px;
}

To target the browsers that potentially support the transform property we use the CSS3 nth-child() psuedo class.

A pretty cool alternative to an already great idea by snook.