Note:

The stylesheet for the polyfill was not included correctly when this post was first published, and as a result, the examples below were not showing up correctly on IE7-8 and Safari 5.1+. The problem has been corrected.

Screenshots of HTML5 progress bars with different styles applied. Details given below.

The HTML: Simple

The HTML for a Progress bar is dead simple:

<progress max="100" value="60">
  <strong>Progress: 60% done.</strong>
</progress>

Note that the HTML inside the <progress> tag is the fallback for browsers that do not support it. That, unfortunately, includes all versions of IE and Safari so far, as well older versions of Firefox (5.x and lower) and Opera (10.x and lower). Although the fallback is acceptable, we can go a step further and use Lea Verou’s excellent <progress> tag polyfill, which adds pretty much full-support for all of these browsers except for Safari 5 and lower (so you should always put in the fallback HTML just to be on the safe side). Let’s take a look at these screenshots to see what how <progress> looks across the browserverse:

	Windows 7	Windows XP	Mac OS X	Ubuntu Linux
Firefox
Chrome
IE7+ (polyfill)		N/A
Safari 5.1+ (polyfill)				N/A
Opera

Note that:

• Firefox and Chrome will render the progress bar the same way that the host operating system would … except for Chrome for Linux, which uses it’s own custom style (thanks to Mounir Lamouri for correcting me on this exception).
• The color of the Opera progress value is always green (more on this later).
• The browsers that use the polyfill all render the progress bar with a nice bluish gradient effect

A progress bar can also have an “indeterminate” state, which happens when there is no value attribute.

<progress max="100">
  <strong>Progress: 60% done.</strong>
</progress>

This effect is used to show that the state of progress is currently unknown (e.g. how long it will take for a web server to initiate the download of a file if is generating it on the fly). How this looks varies from browser to browser as well.

	Windows 7	Windows XP	Mac OS X	Ubuntu Linux
Firefox
Chrome
IE7+ (polyfill)		N/A
Safari 5.1+ (polyfill)				N/A
Opera

Note that:

• Opera is the only browser that doesn’t distinguish between a progress bar with an indeterminate state and one with a value of zero.
• All of the other browsers (including the ones that use the polyfill) animate the indeterminate states. (I have opted to not show all the animations here to avoid readers getting seizures … I hear that would be a bad thing).

But I Want To Style Them My Way!

If you are particular in how you want your <progress> tags to look, the good news is that you can pretty much style them any way you want. You must, however, be aware about the browser quirks that can trip you up … and it isn’t all IE’s fault this time! Follow this three-to-four-step process, and you’ll be styling progress bars in your sleep in no time:

Step 1: Turn off default styling

The first step is to turn off the default styling in all browsers:

progress,          /* All HTML5 progress enabled browsers */
progress[role]     /* polyfill */
{

	/* Turns off styling - not usually needed, but good to know. */
	appearance: none;
	-moz-appearance: none;
	-webkit-appearance: none;

	/* gets rid of default border in Firefox and Opera. */
	border: none;

	/* Needs to be in here for Safari polyfill so background images work as expected. */
	background-size: auto;

	/* Dimensions */
	width: 400px;
	height: 60px;

}

/* Polyfill */
progress[role]:after {
	background-image: none; /* removes default background from polyfill */
}

/* Ensure fallback text doesn't appear in polyfill */
progress[role] strong {
	display: none;
}

Simple stuff: remove the border and add a specific width and height. I added the second rule to remove the background image inserted by the polyfill’s stylesheet, but if you wanted, you can modify the polyfill’s stylesheet directly (or leave it out completely if you elect not to use the polyfill). The final rule is to ensure the polyfill doesn’t display the fallback content — it assumes that is always wrapped in a <strong> tag, so this may be something you should keep in mind when setting the default content (if you don’t like using a <strong> tag as a wrapper for your fallback content, use whatever tag you like).

Note that the appearance property (and its vendor-specific brethren) are there to turn off the default operating-system styling on the progress bar — it doesn’t seem like it is really necessary, but I put it here for reference in case it becomes mandatory in the future.

Step 2: The Progress Bar Background.

Now let’s change the background color of the progress bar to a light red.

progress,                          /* Firefox  */
progress[role][aria-valuenow] {    /* Polyfill */
   background: #ffeeee !important; /* !important is needed by the polyfill */
}

/* Chrome */
progress::-webkit-progress-bar {
    background: #ffeeee;
}

Notice that with Firefox and the polyfilled browsers, all you need to do is change the background of just the progress tag itself, while in Chrome (and I assume future versions of Safari) it is necessary to use the -webkit-progress-bar pseudo-element. Note that even though the code inside these rules are the same, you cannot put all of these selectors in one rule: doing so breaks Firefox and Opera (so much for degrading gracefully).

Step 3: The Progress Bar Value

Now let’s change the color of progress bar value to black. The CSS is a wee bit longer than it really should be:

/* Firefox */
progress::-moz-progress-bar {
    background: black;
}

/* Chrome */
progress::-webkit-progress-value {
    background: black;
}

/* Polyfill */
progress[aria-valuenow]:before  {
    background: black;
}

Yes, three rules to rule them all! Again, putting them all together in one selector breaks every browser on the planet (including the polyfilled ones), so we have to write three separate rules with the same CSS properties in them! <sarcasm>Yaaayyy!!!!</sarcasm>

Note that there is no way that I know of to style the progress bar value in Opera 11.52 and lower. It just stays the same green no matter what you do. :-( If anyone is reading this and knows otherwise, I would be indebted to you to let me know how.

Step 4: The Indeterminate Value

This part is optional, and I would only put these rules in if I know I’ll need a style for the indeterminate value (not all applications need it):

/* Firefox */
progress:not([value])::-moz-progress-bar {
  background-image:  url(../images/indeter.gif);
}

/* Chrome */
progress:not([value])::-webkit-progress-bar {
  background-image:  url(../images/indeter.gif);
}

/* Polyfill - IE */
progress[role]{
	background-image: url(../images/indeter.gif) !important;
}

/* Polyfill - Safari */
progress:not([value])  {
	background-image: url(../images/indeter.gif) !important;
	background-size: auto;  /* Needs to be in here for Safari */
}

It even works in Opera! Note that the background-size must be set to auto in order to override the default style in the polyfill. :-)

See the above CSS in action in a “clean room” page

That’s Too Basic! I Want Fancy-Pants™ Progress Bars

So, now that you know the basics, let’s take a look at some more complicated and interesting progress bars:

Two Image Effect

This progress bar uses two versions of the same image (one grey-scale, one color) to differentiate between the progress bar background and value:

See the above example in action in a “clean room” page

Gradients

Note that not only can you use background-colors and -images, but also use the variety of gradients that are available for developers today in supported browsers (this does not include IE9 and lower). To prove this, I took Chris Croyer beautiful <div> style progress bars from his blog post on CSS3 based progress bars and HTML5-ified™ them here:

Unfortunately, due to CSS gradients being implemented by the browser vendors using vendor-specific prefixes, the CSS tends to be a wee long. Here is the CSS of the first example (scroll the code to see the whole lot of it):

/*
 * Gradient Shadow
 */

/* All HTML5 progress enabled browsers */
progress.example3 {

	/* Turns off styling - not usually needed, but good to know. */
	appearance: none;
	-moz-appearance: none;
	-webkit-appearance: none;
	/* gets rid of default border in Firefox and Opera. */
	border: solid #cccccc 5px;
	border-radius: 10px;
	/* Dimensions */
	width: 238px;
	height: 45px;
}

/* Polyfill */
progress.example3[role]:after {
	background-image: none; /* removes default background from polyfill */
}

/*
 * Background of the progress bar background
 */

/* Firefox and Polyfill */
progress.example3 {
	background: #cccccc !important; /* !important only needed in polyfill */
}

/* Chrome */
progress.example3::-webkit-progress-bar {
	background: #cccccc;
}

/*
 * Background of the progress bar value
 */

/* Firefox */
progress.example3::-moz-progress-bar {
	border-radius: 5px;
	background-image: -moz-linear-gradient(
		center bottom,
		rgb(43,194,83) 37%,
		rgb(84,240,84) 69%
	);
}

/* Chrome */
progress.example3::-webkit-progress-value {
	border-radius: 5px;
	background-image: -webkit-gradient(
		linear,
		left bottom,
		left top,
		color-stop(0, rgb(43,194,83)),
		color-stop(1, rgb(84,240,84))
	);
	background-image: -webkit-linear-gradient(
		center bottom,
		rgb(43,194,83) 37%,
		rgb(84,240,84) 69%
	);
}

/* Polyfill */
progress.example3[aria-valuenow]:before {
	border-radius: 5px;
	background-image: -moz-linear-gradient(
		center bottom,
		rgb(43,194,83) 37%,
		rgb(84,240,84) 69%
	);
	background-image: -ms-linear-gradient(
		center bottom,
		rgb(43,194,83) 37%,
		rgb(84,240,84) 69%
	);
	background-image: -o-linear-gradient(
		center bottom,
		rgb(43,194,83) 37%,
		rgb(84,240,84) 69%
	);

}

Note that I did not use the Gradient filter to polyfill CSS3 gradients in IE6-9. This is because Visual Filters don’t work in CSS3 pseudo-elements like :before or :after. Oh well.

See the above CSS in action in a “clean room” page

Monkeys!

What blog post about HTML5 progress tags would be complete without monkeys? These simians appear in all browser except for IE8 and lower (as explained below).

Apologies to the great Banksy — it’s not his monkey but one grabbed from this Animated GIF site and converted into a CSS sprite using André Gil’s super-cool Gif2TileSet tool. I took this sprite and animated the monkey using blitting whenever the progress bar changes values (thanks to my friend and colleague Noel Tibbles for turning me on to this technique).

Note the HTML has an extra <div> tag so the monkey has a place to live:

<progress class="monkey" min="0" max="100" value="60"></progress>
<div class="after"></div>

I wish that I could have used :after (or ::after) rules instead, but these pseudo-elements don’t work with the progress tags in any browser that doesn’t use the polyfill. And no, :before doesn’t work either. I have no idea why it doesn’t work, but it’s a shame — using them would be perfect to get rid of the extra markup.

The CSS that makes the monkey animate when the progress bar changes values is here:

progress.monkey[value="0"] +  .after{
	background: url('/blog/wp-content/uploads/2011/12/monkeyBlit.gif');
} 

progress.monkey[value^="1"] +  .after {
	background: url('/blog/wp-content/uploads/2011/12/monkeyBlit.gif') 0  -77px ;
}

progress.monkey[value^="2"] +  .after {
	background: url('/blog/wp-content/uploads/2011/12/monkeyBlit.gif') 0  -154px ;
}

progress.monkey[value^="3"] +  .after,
progress.monkey[value="100"] +  .after  {
	background: url('/blog/wp-content/uploads/2011/12/monkeyBlit.gif') 0  -231px !important ;
}

progress.monkey[value^="4"] +  .after {
	background: url('/blog/wp-content/uploads/2011/12/monkeyBlit.gif') 0  -308px ;
}

progress.monkey[value^="5"] +  .after {
	background: url('/blog/wp-content/uploads/2011/12/monkeyBlit.gif') 0  -385px ;
}

progress.monkey[value^="6"] +  .after {
	background: url('/blog/wp-content/uploads/2011/12/monkeyBlit.gif') 0  -462px ;
}

progress.monkey[value^="7"] +  .after {
	background: url('/blog/wp-content/uploads/2011/12/monkeyBlit.gif') 0  -539px ;
}

progress.monkey[value^="8"] +  .after {
	background: url('/blog/wp-content/uploads/2011/12/monkeyBlit.gif') 0  -616px ;
}

progress.monkey[value^="9"] +  .after {
	background: url('/blog/wp-content/uploads/2011/12/monkeyBlit.gif') 0  -693px ;
}

Each of these rules are applied when the first digit changes in the progress bar, which is done using the ^= attribute rules. This works because the progress bar goes from 0 – 100 and the progress bar increments by 10. They monkeys don’t appear in IE8 and under because of it’s lack of support of the ^= attribute selector (but it works well in IE9).

Note that this would be much easier if CSS allowed us to combine the CSS3 calc() and attr() attributes together like Lea Verou dreams about in one of her blog posts:

/*
 * Don't try this - it doesn't work in any browser, but it would be nice if it did.
 */

progress.monkey::after {
   background-image: url('/blog/wp-content/uploads/2011/12/monkeyBlit.gif');
   background-position-x: 0;
   background-position-y: calc(-77 * attr(value), 'px');
}

Hopefully this will come to pass in the future.

See the above CSS in action in a “clean room” page

Speedometer

My last example is radically different than the others. How about we apply the speedometer metephor to the progress bar with some fancy-pants CSS3? This example in all browsers except IE8 and lower (due to lack of support for native CSS3 transform)

The CSS is similar to the monkey example in that I add an extra <div> after the progress tag, except that it has an image of a pointer inside of it.

<div id="progressContainer">
  <progress id="rot" class="example_r" min="0" max="100" value="60"></progress>
  <div data-arrow-for="rot" class="arrow"><img src="/blog/wp-content/uploads/2012/01/hand.png" /></div>
</div>

I wrapped both these tags inside a relatively positioned container <div>. This is so I could absolutely position both the progress bar and the arrow in order for them to line up properly. I make the progress bar into a semi-circle by using border-radius and part of a photo from Flickr user ‘listener42′ …

progress.example_r {

	/* gets rid of default border in Firefox and Opera. */
	border: solid 1px black;
	display: inline-block;

	/* Produces the semi-circle */
	border-radius: 238px 238px 0 0;

	/* Dimensions */
	width: 238px;
	height: 126px;
	padding: 0;
}

… and make the arrow rotate as the progress bar increments by using CSS transforms:

progress.example_r[value="0"] + .arrow {
	-moz-transform: rotate(270deg);
	-webkit-transform: rotate(270deg);
	-o-transform: rotate(270deg);
	-ms-transform: rotate(270deg);
}

progress.example_r[value^="1"]:not([value="1"]):not([value="100"]) + .arrow {
	-moz-transform: rotate(288deg);
	-webkit-transform: rotate(288deg);
	-o-transform: rotate(288deg);
	-ms-transform: rotate(288deg);
}

progress.example_r[value^="2"]:not([value="2"]) + .arrow {
	-moz-transform: rotate(306deg);
	-webkit-transform: rotate(306deg);
	-o-transform: rotate(306deg);
	-ms-transform: rotate(306deg);
}

progress.example_r[value^="3"]:not([value="3"]) + .arrow {
	-moz-transform: rotate(324deg);
	-webkit-transform: rotate(324deg);
	-o-transform: rotate(324deg);
	-ms-transform: rotate(324deg);
}

progress.example_r[value^="4"]:not([value="4"]) + .arrow {
	-moz-transform: rotate(342deg);
	-webkit-transform: rotate(342deg);
	-o-transform: rotate(342deg);
	-ms-transform: rotate(342deg);
}

progress.example_r[value^="5"]:not([value="5"]) + .arrow {
	-moz-transform: rotate(360deg);
	-webkit-transform: rotate(360deg);
	-o-transform: rotate(360deg);
	-ms-transform: rotate(360deg);
}

progress.example_r[value^="6"]:not([value="6"]) + .arrow {
	-moz-transform: rotate(378deg);
	-webkit-transform: rotate(378deg);
	-o-transform: rotate(378deg);
	-ms-transform: rotate(378deg);
}

progress.example_r[value^="7"]:not([value="7"]) + .arrow {
	-moz-transform: rotate(396deg);
	-webkit-transform: rotate(396deg);
	-o-transform: rotate(396deg);
	-ms-transform: rotate(396deg);
}

progress.example_r[value^="8"]:not([value="8"]) + .arrow {
	-moz-transform: rotate(414deg);
	-webkit-transform: rotate(414deg);
	-o-transform: rotate(414deg);
	-ms-transform: rotate(414deg);
}

progress.example_r[value^="9"]:not([value="9"]) + .arrow {
	-moz-transform: rotate(432deg);
	-webkit-transform: rotate(432deg);
	-o-transform: rotate(432deg);
	-ms-transform: rotate(432deg);
}

progress.example_r[value="100"] + .arrow {
	-moz-transform: rotate(450deg);
	-webkit-transform: rotate(450deg);
	-o-transform: rotate(450deg);
	-ms-transform: rotate(450deg);
}

Again, the CSS would be much smaller in size if I could use calc() and attr() together, but again, oh well. Also note that this example doesn’t work in Opera very well because we cannot turn of the green in the progress bar value. :-(

See the above CSS in action in a “clean room” page

Summary of Gotchas

As mentioned before, there are a few annoyances I have found with they way the browsers have implemented HTML5 progress bars:

1. You cannot use :before/::before or :after/::after pseudo-elements on the progress element. Why this is not allowed is unclear to me, and I hope this is allowed in the future.
2. Safari 5.0 and lower cannot use the polyfill, so you should always use the fallback HTML inside the <progress> tag.
3. It seems like it is impossible to change Opera’s progress bar style to anything besides green.
4. There is a small bug in the polyfill when applying borders to the progress bar. I have a fix that has been submitted as a pull request and I assume being reviewed, but in the meantime, you can get my forked version of the polyfill (with the bug fix) on GitHub.

Help Me Keep This Page Up-To-Date!

If you find out more information about the HTML5 progress tag, I’d love to hear from you! Please let me know in the comments below. I will add relevant information to the above article and credit you fully. :-)

There have been many times I have come across the need to take an image and cut an irregular shape out of it. Normally, when a developer comes across this requirement, the only thing to do is to open the image up with your favorite graphics editor, use the select tool to cut out the shape you want, and then save the result as a PNG, since it is the only image format used by all web browsers that support alpha channels. The problem is that PNG images, while compressed, are not as small as JPEGs if the source image is a photograph, and the download time of a page can balloon to unacceptable levels if there are many of these types of image on a page. When I first came across this problem, I didn’t think there was an obvious solution, but after a lot of thought, I created a library that uses HTML5 canvas to clip a JPEG (or any other image for that matter). The library also supports older versions of IE (7-8) using the Excanvas JavaScript library which polyfills canvas using VML.

Okay, How Can I Do The Same Thing?

• Download my script from github (It includes jQuery 1.6.4 and excanvas release 3. It should work with later versions — if it doesn’t, please let me know and I’ll fix it ;-) ) .
• Include them into the head of your document.
  

    <script src="/path/to/js/jquery-1.6.2.min.js"></script>
  
    <!--[if lt IE 9 ]>
     <script src="/path/to/js/excanvas/excanvas.compiled.js"></script>
    <![endif]-->
  
    <script src="/path/to/js/polyClip-p.js"></script>
  

• Layout your page as normal, placing img tags where you want the clipped images to go:
  

  <div class="clipParent">
    <img src="images/image.jpg" />
  </div>
  

  Note the div tag with the class of clipParent. You must surround all the image tags with data-polyclip attributes set one. This is so you can style the image correctly, since the library will remove the image tag and replace it with a canvas element.

• For every image on your page that you want to clip, calculate the points of the shape you want to cut out of the image and place them in the data-polyclip attribute. For example, let’s say you have the following shape you want to cut out of a photograph:
  
  

  (487, 4)

  (500, 239)

  (19, 239)

  (43, 195)

  You would then just set the data-polyclip attribute to those points:

  <img src="image.jpg" data-polyclip="487, 4, 500, 239, 19, 239, 43, 195" />
  

  Note that the point co-ordinates are comma delimited. If you don’t want to calculate these numbers by hand, you can use your favorite imagemap generation tool to do generate the list of coordinates. Just remember to take the coordinates out of the imagemap code and stick it in the data-polyclip attribute (for the examples on this page, I used the on-line tool available at image-maps.com).

Why Should I Do This Instead of Using a PNG?

Compare the image above with a PNG clipped with the GIMP. Even when I compressed the PNG with my PNG optimization script, the 191K PNG file is huge compared to it’s tiny 18K polyclipped JPEG analogue (Note: file sizes refer to the size of the full image as displayed at the top of this article):

JPG using polyClip.js (18K)	PNG (191K)

You may ask whether the amount of JavaScript used in this solution is greater than the bandwidth saved by using JPEG compression. Not including jQuery, the amount of JavaScript clocks in at 2K or 13K, depending on the browser used (2K for the compressed polyClip script and 11K for excanvas, which will only be loaded by IE7-8). Although jQuery adds 91K to this equation, it doesn’t matter that much to me personally since I am probably using it for other parts of my page anyways. Even with jQuery, the amount of JavaScript downloaded outweighs using a PNG, especially if your are clipping a larger image or a huge amount of smaller images.

Download the latest version of polyClip.js from github.

A Few Caveats

• In IE7 and 8, the image may appear briefly as a black outline before the image appears. Other than that, it looks about the same as the other browsers.
• The image does not show up correctly in Opera Mini. Then again, a lot of things (e.g. CSS3 text-shadows, CSS3 Transforms, etc.) don’t show up correctly in Opera Mini. :-)

What are the issues?

IE has three issues related to oninput:

1. oninput is not supported at all in IE8 and lower.
2. IE9 does not allow referring to form fields directly in the oninput expression. For example, this code works in all browsers except IE9:
   

   <form name="f1" oninput="output.value = parseFloat(darkness.value);">
       Darkness Level:
       <input type="range" name="darkness" value="0" min="0" max="255">
       <output name="output">
   </form>
   

   This is not so bad, since one could refactor the event code like this:

   <form name="f1"
     oninput="document.getElementById('output').innerHTML = parseFloat(darkness.value);">
       Darkness Level:
       <input type="range" name="darkness" value="0" min="0" max="255">
       <output id="output">
   </form>
   

3. If you use the backspace key while entering in a value, IE9 doesn’t fire the oninput event. This, in my opinion, is really bad, because it does affect how the form behaves. For example, take the following form in IE9:
   

   Amount:
   Item:
   Tax:	45.00
   Total:	344.99

   As the user types in values for the amount and price into the form, the oninput event calculates the tax and total. However, if the user is entering a value into, say, the price and make a mistake and press the backspace, IE9 will not update the tax and total. Your application will give erroneous information, the user will be surprised at the total being larger than he expected, says “screw this” and leaves the application. Your company loses the big sale, your boss fires you, and next thing you know you are on a street, or worse, coding COBOL on a 30 year old IBM PC running MS-DOS 1.0 in some fishing tackle store. Not pretty.

Oh The Humanity! How Can I Prevent Such a Fate?

Since I hate COBOL, I decided to update my html5Widgets library to:

1. Add support for oninput for browsers that don’t support it (e.g. IE7 and 8)
2. Force IE9 to fire a form’s oninput when the backspace and delete keys are pressed inside any of the input nodes.
3. Force IE9 to fire a form’s oninput when the cut event is fired on any of the input nodes.

Using the link below, you can see an example similar to the one above using html5Widgets to fix these issues.

Let’s see html5Widgets give IE some oninput goodness

In order to do this, I used ideas from Daniel Friesen’s blog post, A HTML5 Browser Maze, Oninput Support (thanks to Paul Irish for pointing me into that direction). The result works rather well. Note that I did not fix the IE9 “cannot use .value, must use .innerHTML” bug described earlier. It’s a little bit more verbose, but for now it’s what a developer needs to do for true cross-browser oninput support. I have also kept onforminput support in the code, just in case anyone has used it in the past (e.g. me). To ensure the best experience, I wouldn’t use both events on the same page.

Note also I did not add support for oninput in any element other than form. I may do this after further research in the way it supported across browsers (for example, Firefox has an issue with oninput being used on textarea elements).

Download

Download the latest version of html5Widgets, which includes oninput support, from github.

Further Reading

• Daniel Friesen’s blog post, A HTML5 Browser Maze, Oninput Support.
• oninput event | input event from the Dottoro Web Reference
• Using the oninput event with onkeydown as its fallback by the ever talented Mathias Bynens.

Update:

Newer versions of all browsers support the form element’s oninput attribute, which replaces the functionality of onforminput, and as a result I wrote a related article Fixing oninput in IE Using html5Widgets. Thanks to Rob Crowther for setting me straight and providing a great example, which I have forked to work for IE9. I will refactor html5Widgets to support oninput in IE very soon. I will leave this article as is for the benefit of anyone who is Googling for onforminput and why it was deprecated.

I was just doing some regression testing on html5Widgets, and noticed that the onforminput event wasn’t working in Firefox 4. This didn’t make sense to me: I designed html5Widgets to detect if the output tag is supported, and if not, add support for it. I believed that if a browser supported the output tag, it also had to support the onforminput event, since I assumed that this was one of the main reasons of having the output tag in the first place. However, Firefox 4 supports the output tag, but doesn’t support onforminput. After doing a bit of light research, I came across this this bug report that seems to indicate that onforminput is deprecated. This article will discuss what onforminput does, why it is very useful to designers are not so strong in JavaScript, how one can add support for onforminput to browsers that don’t, and why I really hope someone in power adds it back to the HTML5 Forms specification, or at least something very similar.

Why Do I Care

For those that don’t know what this is, onforminput is an attribute that a web author can use on the output tag to do some calculations with the values in a form’s input fields and show that calculation to a user. Right now, Opera is the only browser that natively supports it, but in an earlier post I showed how one could use it with my html5Widgets polyfill library in all the other browsers. How does it work? To illustrate a very simple use case, let’s say I have a range input field:

(Note the range element is polyfilled with html5Widgets if your browser doesn’t support it).

The range input type is a slider widget, and we use it here so the user can choose a number between 0 and 255. The slider looks cool, but from a usability standpoint, there is no feedback of what value the user is sliding to. It would make more sense to show a number next to the slider. which gives feedback to the user as to what the slider’s value is. This is where onforminput comes in:

Immediate user feedback! Great user experience! And simple syntax! Even a person who is not familiar with JavaScript can figure it out. But it’s deprecated! So, even though the output tag is supported by Firefox 4, onforminput is not. Oh-noes!!!!

Luckily, my html5Widgets library adds support for it in browsers that don’t, including Firefox 4. I just made a small change that worked around an issue preventing Firefox from supporting it, and BAM! Instant support.

Another good (and common) example for using output would be a form for an online tool that calculates a total automatically. Enter in values into the following form and see the calculations magically appear:

But, why is it depreciated in the first place?

It seems the decision has been made to remove onforminput from the HTML5 specification since it’s purpose can be easily done with capturing events (at least, that’s what I understood from this thread about onforminput and onformchange on the public-webapps mailing list).

While this is true, I think keeping it in would be a huge help to designers and developers. I even think that having it declared inline like I do in the code examples above is useful. Even though it breaks the separation of document structure and behavior, it allows a developer with practically no JavaScript knowledge to implement this simple feature in a form. According to the Bug Report, designers shouldn’t have to use onforminput since they can do this instead:

<form name="f1">
Darkness Level:
    <script type="text/javascript">
      document.addEventListener("input",
        function(e) {
          if (document.forms.f1 == e.target.form)
            e.target.form.output.value =
              parseFloat(e.target.form.darkness.value);
        }, true);
    </script>

    <input type="range" name="darkness"
         value="0" min="0" max="255" />
    <output name="output">
  </form>

This is uglier than your Mom’s mood when you don’t call her on Mother’s Day (not that I’m speaking from any recent experience). Even though it is dead easy for a JavaScript programmer to implement this without onforminput, some web designers wouldn’t have the knowledge or the patience to do so. This is not a slight to those designers — after all, they can probably make better looking web pages than the average programmer. So I am keeping onforminput in html5Widgets. It is really convenient and easy to understand.

A Note To Those In Power

To anyone at the W3C who has the power to do so, I am politely asking to reconsider and please put onforminput back into the specification or at least replace it with something just as simple (the latter being attractive to those who want to continue separating the structure of the document (i.e. HTML) from the behavior (i.e. JavaScript)). As mention in the update on the top of the page, oninput is a great replacement for onforminput and it works in all modern browsers.

In my humble opinion, creating calculations the old-fashioned way with events and lines and lines of JavaScript is painful for designers who aren’t scripters. After all, isn’t this the reason why required and pattern were created?

Download the latest version of html5Widgets, which includes onforminput support, from github

Notes:

• This article was not rendering correctly in Firefox 4.x due to a change in how that browser handles MathML. This issue has now been fixed as of May 1, 2011.
• If you are not familar with 2D-Transforms, take a look at my other article Cross Browser CSS Transforms – even in IE

The Matrix Construction Set allows you to make a pixel perfect transformation by just dragging and dropping objects around.

The CSS3 transform property can do some really cool things - with it, web designers can rotate, scale, skew and flip objects quite easily. However, in order for deisgners to have fine-grained, pixel level control over their transforms, it would be really helpful to understand how the matrix() function works. With the matrix() function, designers can position and shape their transformations exactly where they want to.

The problem is, not many people actually understand what the numbers in the matrix filter actually mean. To solve this issue, I have created a tool, which I call the CSS3 Matrix Construction Set that can take any block-element, positioned anywhere on the page, transform it anywhere else on the page using the matrix() filter, and reveal the correct CSS code for this operation. Look at the tool now and if that is all you are interested in, you can stop there. However, if you what to know what the numbers in the matrix() function actually mean, and why you want such knowledge in the first place, read on. I'll try to explain this as simply as possible (and please feel free to use the feedback form if you have any opinions on how to make this article better).

Matrices: Why Should I Care?

Matrices are to transforms like RGB hex codes are to colors: they are representations that are easy for computers to understand, but not human beings. Sure, web designers can use the rotate(), skew(), scale() and translate() functions to fulfill their transformation needs ... why should we bother with matrix() at all? There are a few cases when you may want to:

Brevity:

Using matrices, it is possible to represent a complex string of 2D transforms like this:

#object {
    transform-origin: 0 0;
    transform: rotate(15deg) translateX(230px)  scale(1.5, 2.6) skew(220deg, -150deg) translateX(230px)
}

using one matrix() rule like this:

#object {
    transform-origin: 0 0;
    transform: matrix(1.06, 1.84, 0.54, 2.8, 466px, 482px)
}

(Note: I have ignored the vendor-specific variants (e.g. moz-transform, etc.) for the sake of brevity).

Pixel-Perfection:

If you know exactly how you want your transformation to look, it'll take a bit of fiddling around to get it to look how you want using the other transform functions, and it may not be pixel perfect if you lack patience (like I do). However, using a tool like the Matrix Construction Set, you can place the transform exactly where you want (This is analogous to using a color wheel to choose RGB colors for you, instead of using keywords like red, green or peachpuff).

JavaScript:

Revealing an object's transform information using JavaScript's getComputedStyle() function will yield a matrix() function in all current web browsers that support CSS3 transforms, even if it was rendered using other transform functions like rotate(). For example, the object below has been rotated 45° using transform: rotate(45deg):

This object has been rotated 45°

But this link, which shows the object's computed style will reveal that internally it stores a matrix() function.

Ok, What Does The Markup Look Like?

The matrix() function takes 6 parameters in order for it to work:

#transformedObject {
     -moz-transform:    matrix(1.4488, -0.3882, 0.3882, 1.4489, 400px, -100px);
     -webkit-transform: matrix(1.4488, -0.3882, 0.3882, 1.4489, 400, -100);
     -o-transform:      matrix(1.4488, -0.3882, 0.3882, 1.4489, 400, -100);
     transform:         matrix(1.4488, -0.3882, 0.3882, 1.4489, 400, -100);
}

Note the difference with the Firefox implementation of matrix() — the last two elements need the px units after it. For now, think of it is a difference in notation, but we'll explain why this is later.

But What Do The Numbers Mean?

In order to explain what they mean, I will have to define a few math-concepts here. Don't panic if you are mathematically challenged. These concepts are not that hard to understand, but there is a bit of explanation needed. Why should you torture yourself if you hate math?

If you are a designer:

Think of the stuff below as informational. If you use the Matrix Construction Set you won't need to calculate anything by hand (but wouldn't you want to have an idea what the numbers mean anyway?)

If you are a JavaScript developer:

This information will be invaluable when optimizing scripts that rely on transformation effects. Just try to understand the basic concepts here, and if you still need help, use the Sylvester JavaScript library to do the heavy lifting for you.

If you want to be an über-geek:

All those matrix jokes you hear at parties will suddenly start to make sense!

Finally you'll be able to understand why all the geeks at work find this XKCD comic so funny.

Terminology

Matrix

The easiest way to think of a matrix is as a group of numbers written in a rectangle or square. For our purposes, we will be dealing with 3x3 matrices, such as this one below:

That's nine numbers! So how come the CSS3 matrix() function only has six?

#transformedObject {
     transform:  matrix(1, 2, 3, 4, 5, 6);
}

Dot Product

Next we are going to explain what a dot product is. At first, this may not seem like this is related to matrices at all, but I promise it does ... just read on and you'll understand why in no time. Trust me. :-)

Let's say you have two (x, y) points, $\left(\begin{array}{cc}1& 2\end{array}\right)$ and $\left(\begin{array}{cc}4& 5\end{array}\right)$. The dot product of these two points (written $\left(\begin{array}{cc}1& 2\end{array}\right)$ · $\left(\begin{array}{cc}4& 5\end{array}\right)$) is what you get when you multiply the two x-coordinates, multiply the two y-coordinates, and then add them together:

Got it? It's pretty simple, right? Note that when we write (x, y) co-ordinates like $\left(\begin{array}{cc}\mathrm{x}& \mathrm{y}\end{array}\right)$, we call $\left(\begin{array}{cc}\mathrm{x}& \mathrm{y}\end{array}\right)$ a vector. Vector notation can be written horizontally, (e.g. $\left(\begin{array}{cc}\mathrm{x}& \mathrm{y}\end{array}\right)$) or vertically (e.g. $\left(\begin{array}{c}\mathrm{x}\\ \mathrm{y}\end{array}\right)$). When using them in 2D transforms, we always add an extra co-ordinate with a number 1 at the end. So (20, 90) would be written $\left(\begin{array}{ccc}20& 90& 1\end{array}\right)$ or like $\left(\begin{array}{c}20\\ 90\\ 1\end{array}\right)$ in vector notation.

Multiplicatying a Matrix with a Vector

So, what does the dot product have to do with matrices? Well the idea of the dot product can also be extended to matrices. Let's say you need to multiply the following together:

So, How Does This Relate To CSS3 Transforms?

#transformedObject {
     position: absolute;
     left: 0px;
     top: 0px;
     width: 200px;
     height: 80px;
     transform:  matrix(0.9, -0.05, -0.375, 1.375, 220, 20);
     transform-origin: 0 0;
}

What is the end result? Well, first let's take a look at the object without the transform CSS:

When the browser applies the transform to this block, it takes the matrix and multiplies it to each of the corner coordinates. For example, taking the bottom-right corner, (200, 80) or $\left(\begin{array}{c}200\\ 80\\ 1\end{array}\right)$, we get:

Let's look at the results for the other three coordinates. For (200, 0):

For (0, 80) test:

And finally, for (0, 0):

Here is the result:

I don't expect anyone to calculate these by hand on a regular basis (I personally don't). But now you know what these numbers mean. :-)

What About Internet Explorer?

Although transform-origin doesn't work with IE, it is possible to generate the matrix in another browser and use cssSandpaper to generate the shape of the transform in that browser. In order to fix the positioning, one can use Paul Irish's conditional stylesheet fix to position that block manually in IE only (it is what I used on this page so that the matrix transform in my example above appeared correctly in IE). I hope to have transform-origin working in cssSandpaper soon so that it will be unnecessary to do this.

Other Interesting Facts About Matrices

1. All the other CSS3 transform functions have equivalent matrix notation:

   scale(a)	scaleX(x)	scaleY(y)	translateX(x)	translateY(y)	translate(x,y)
   $\left(\begin{array}{ccc}\mathrm{a}& 0& 0\\ 0& \mathrm{a}& 0\\ 0& 0& 1\end{array}\right)$	$\left(\begin{array}{ccc}\mathrm{x}& 0& 0\\ 0& 1& 0\\ 0& 0& 1\end{array}\right)$	$\left(\begin{array}{ccc}1& 0& 0\\ 0& \mathrm{y}& 0\\ 0& 0& 1\end{array}\right)$	$\left(\begin{array}{ccc}0& 0& \mathrm{x}\\ 0& 0& 0\\ 0& 0& 1\end{array}\right)$	$\left(\begin{array}{ccc}0& 0& 0\\ 0& 0& \mathrm{y}\\ 0& 0& 1\end{array}\right)$	$\left(\begin{array}{ccc}0& 0& \mathrm{x}\\ 0& 0& \mathrm{y}\\ 0& 0& 1\end{array}\right)$

   skewX(x)	skewY(y)	skew(x,y)	rotate(θ)
   $\left(\begin{array}{ccc}1& tanx& 0\\ 0& 1& 0\\ 0& 0& 1\end{array}\right)$	$\left(\begin{array}{ccc}1& 0& 0\\ tany& 1& 0\\ 0& 0& 1\end{array}\right)$	$\left(\begin{array}{ccc}1& tanx& 0\\ tany& 1& 0\\ 0& 0& 1\end{array}\right)$	$\left(\begin{array}{ccc}cos\theta & -sin\theta & 0\\ sin\theta & cos\theta & 0\\ 0& 0& 1\end{array}\right)$

2. A list of transforms in CSS3 like this:

   #o1 {
      transform-origin: 0px 0px;
      transform: rotate(15deg) translateX(230px) scale(1.5);
   }
   

   is the same as multiplying the equivalent matrices together:
   $\left(\begin{array}{ccc}cos\mathrm{15°}& -sin\mathrm{15°}& 0\\ sin\mathrm{15°}& cos\mathrm{15°}& 0\\ 0& 0& 1\end{array}\right)$ · $\left(\begin{array}{ccc}0& 0& 230\\ 0& 0& 0\\ 0& 0& 1\end{array}\right)$ · $\left(\begin{array}{ccc}1.5& 0& 0\\ 0& 1& 0\\ 0& 0& 1\end{array}\right)$
   (I know, I didn't tell you how to multiply matrices together. Stephan Waner has written a good tutorial for matrix multiplication if you are interested.)
3. CSS3 2D-Transforms can only transform blocks into parallelograms. For example, it is impossible to transform a block into this shape:
   
   In order to do this, one must use CSS3 3D Transforms. This is why the Matrix Construction Set only has three control points to drag around, not four. If you would like to see a version of the Matrix Construction Set to use matrix3d(), please let me know by leaving a comment below.

In Conclusion

I don't expect anyone to be an expert in matrix artithmetic after reading this article. But at least you know what those pesky numbers mean, and this information may become useful in the future.

Acknowledgments

• The MathML markup used to display the mathematical equations in this article were rendered by MathJax, an excellent open-source JavaScript library
• The equations on this Physics Forum post was quite helpful in the creation of the Matrix Construction Set.
• The Matrix Construction Set uses the Sylvester JavaScript library written by James Coglan for performing matrix calculations. It also used my own DragDropHelpers library to smooth out the different browser implementations of HTML5 Drag and Drop.
• A blog post that has a bunch of math equations on it may be scary for web designers. My apologies.

An example of ruby text, from a photo by Flickr user eliazar.”

When talking about Ruby Annotations, I don’t mean Ruby on Rails, or anything related to the Ruby programming language. I am talking about ruby characters which are used to annotate text with supplementary information. For example if some readers wouldn’t know what the term “WWW” means, we can use ruby annotations to help them out like this:

The ruby base (in this case “WWW”) is annotated by ruby text (“World Wide Web”). In this case, the ruby text appears in a small font-size above the base. Traditionally, ruby annotations have been used in Chinese, Korean and Japanese text-books to help students of those languages sound out more complicated characters:

In the text above, the ruby base is written in Kanji, many of which are only readable by Japanese with a high-school education. The ruby text is written in Hiragana, which all Japanese grade-schoolers can understand.

I can hear you saying to yourself “Who cares? I’m not Japanese! I can’t read any of it!”. Ruby annotations can also be used to help those who don’t speak the language at all. An author can use ruby to help English speakers pronounce Japanese …

.. or, for that matter, any other language, like Ukrainian.

It can also allow an author to give translations on top of foreign words.

But I Have a Hard Enough Time With English!

Ruby text can also be used for help foreign students pronounce English words that may difficult to read:

It can be also be used to help English speakers read intimidating Eastern European surnames transliterated into English:

(An aside note to telemarketers: if you call my home and ask my to speak to “Mister Have —- um — uk” , “Mister Hawww — ahh — uhhh” or especially “Mr. Zoltar”, I will hang up immediately. If you actually pronounce my name correctly, I’ll give you at least five minutes of my time. I mean it.)

Okay, how is this coded?

Let’s take a look at the markup of the above example:

My name is Zoltan
<ruby>
   <rb>Hawryluk</rb>
   <rp> (</rp>
   <rt>how-real-luke</rt>
   <rp>) </rp>
</ruby>

Let’s break down what each of these tags do:

To illustrate the last point about the <rp> tag, copy and paste the following ruby text into notepad, vi or any other plain text editor:

You will see the following in your text editor:

My name is Zoltan Hawryluk (pronounced: how-real-luke).

This is because the of how the <rp> tags are defined:

My name is Zoltan <ruby><rb>Hawryluk</rb><rp> (pronounced: </rp><rt>how-real-luke</rt><rp>)</rp>

Browser Support

So what browsers support these tags? Originally, the <ruby> tag was a proprietary Microsoft tag that worked in IE 5+. Since then it has become a part of HTML5 and WebKit based browsers like Safari and Chrome now support it as well. In order for Firefox and Opera to join the party, I remixed a stylesheet developed for Prince XML by George Chavchanidze of Opera Software. Below are some screenshots of how the ruby text looks in the various browsers with or without the stylesheet.

	With stylesheet set	Without stylesheet set
IE 6.0+
Firefox 3.6+
Safari 5.0+
Chrome 7.0+
Opera 10.63+

Download the stylesheet used in the examples on this page

I took George’s excellent work and added a few additional features:

• It tells IE to ignore the Firefox and Opera styles (since they don’t look so good in IE)
• It makes the font size smaller in Chrome and Safari (a personal preference).
• It sets the <ruby> tag’s ruby-align CSS property to center, so that IE mimics the way the WebKit browser display ruby text by default (IE’s default seems to be distribute-letter, which looks horrible in a lot of situations).

Also note that without the stylesheet, the ruby text gracefully degrades in Firefox and Opera, so it is still readable, and illustrates the usefulness of the <rp> tags. This stylesheet occasionally cause some unusual rendering in some older browsers (such as Safari 4.0 for Mac), but on the whole it does a pretty good job.

Note that in order to make the stylesheet set to work correctly, you must replace the <body> tag with this variation of Paul Irish’s Conditional CSS design pattern:

<!--[if lt IE 7 ]> <body class="ie6"> <![endif]-->
<!--[if IE 7 ]>    <body class="ie7"> <![endif]-->
<!--[if IE 8 ]>    <body class="ie8"> <![endif]-->
<!--[if IE 9 ]>    <body class="ie9"> <![endif]-->
<!--[if (gt IE 9)]><body class="modern"> <![endif]-->
<!--[!(IE)]><!-->  <body class="notIE modern"> <!--<![endif]-->

Using this declaration of the <body> blocks the Firefox and Opera styles in IE.

Advanced Ruby Annotations

Using the stylesheet, it is possible to also break ruby text into parts (e.g. syllables) without using a separate <ruby> tag for each part. This is done with the <rbc> (ruby base container) and <rtc> (ruby text container). Here is an example:

Although Internet Explorer does not understand these new tags, it does degrade gracefully. Here is a comparison of how IE renders the above and how Firefox does.

Firefox 3.6	Internet Explorer 6+

Here is the code that generated the example above.

<ruby class="syllables unicodeRubyText">
  <rbc>
    <rb>com</rb><rb>mu</rb><rb>ni</rb><rb>ca</rb><rb>tion </rb>
  </rbc>
  <rp> (</rp>
  <rtc>
    <rt>kəm</rt><rt>myoo</rt><rt>nĭ</rt><rt><strong>kā</strong></rt><rt>shən</rt>
  </rtc>
  <rp>) </rp>
</ruby>

Note that the <ruby> tag is a member of the classes syllables and unicodeRubyText, which are defined in the stylesheet. The syllables class tells the browser to separate the ruby base text into syllables, separated by the “Interpunct” symbol, while the unicodeRubyText tells the browser to render the ruby text with a Unicode font, so that the pronunciation symbols are printed correctly (it seems that this is only a requirement in Explorer, since the other browsers handle this automatically).

Here is a rundown of these advanced tags:

Unfortunately, there is a bug in older WebKit browsers that gives very strange results. Here are screen shots of the above code as viewed in Chrome 7.0 for Windows, with and without my stylesheet:

Chrome 7.0 Windows (with stylesheet)	Chrome 7.0 Windows (without stylesheet)

This bug appears in Safari 4.x and lower and the current version of Chrome (7.0), for both Windows and Mac. Since this has been fixed in Safari 5.0, I am assuming that this will be fixed in the next version of Chrome as well.

Ruby CSS3 Properties

There are three main CSS3 properties that can be used today … but in Internet Explorer only. Here are a list of them, along with additional properties that the W3C put in their recommendation back in 2001.

Hopefully the other browsers will support these eventually.

And So, In Conclusion …

Here is a quick recap of the various things you should keep in mind when using Ruby Text:

• Firefox 3.6 and Opera 10.x need the stylesheet in order to show ruby text correctly.
• Recent versions of Safari and Chrome don’t need it, but using the stylesheet won’t harm the display of simple ruby text.
• IE doesn’t need the styleheet, but if you use the stylesheet to ensure cross-browser display of ruby text, you must use the special body tag declaration above.
• <rbc> and <rtc> are not recognized in any version of IE, but they will degrade gracefully.
• Ruby text inside of <rtc> tags doesn’t look right in Chrome 7 or Safari 4. Since they do show up right in Safari 5, I assume/hope this will be fixed in the next version of Chrome.
• The advanced CSS3 ruby- properties, such as ruby-align, ruby-overhang and ruby-position are only supported by IE5+.

Additional Reading

• [MS-RUBY]: Internet Explorer Ruby Annotation Standards Support Document from the MSDN Web Site.
• Ruby Rendering in WebKit from the Surfin’ Safari Blog archive
• The W3C Recommendation document for Ruby Annotations, dated 31 May 2001 with corrections made on 25 June 2008
• The W3C CSS3 Rub Module Working Draft dated 14 May 2003.. There is also an editor’s copy dated 04 March 2010.
• XHTML Ruby in Prince, the forum thread where the original stylesheet was developerd. Great to see as a reference.

Download the stylesheet used in the examples on this page

Updates:

• Sept. 10, 2010: This webforms2 script in the link below has been modified to fix validation issues with the newer versions of Safari and Chrome.
• Aug. 6, 2010: This article has been translated into Korean.
• May 12, 2011: html5Widgets has been updated to support the oninput event.

Calendars, colour swatches, sliding widgets, client side validation: this is the nirvana that the HTML5 forms module promises. Some would say “So what? I’ve seen this on the web for years!”, and they’d be right. There have been some really brilliant people coding some really interesting widget and validation frameworks, so why should we change?

• Ease the markup learning curve: HTML5 form widgets and validation have been built to be as dead simple to markup as a select box with no JavaScript knowledge required
• It’s a W3C standard: so you know that it’ll work for years to come and if you have problems, you could always ask almost anyone in the web development community for help.
• Cellular phone support: HTML5 form fields will have optimized user interfaces appropriate for the type of device. Blackberry already has optimized versions of the date/time and color widgets and, according to Mark Pilgrim’s article A Form of Madness, the virtual keyboards that appear when using HTML5 form fields are optimized for the data being input.
• Web development tools will have to support it: It’s a safe bet that Aptana, Dreamweaver, and all the other IDEs out there will have HTML5 support.
• It’s HTML5: when you tell your non-techie co-workers that you use it, you will be the envy of all — after all, it must be five times better than regular HTML, right? Your boss will be so impressed that you are now a guru in this futuristic technology with a cool numbered acronym that he or she will give you a big fat raise!!!

  (Okay, okay. Don’t try to laugh too hard … your co-workers will start to worry).

The Support Dilemma

Unfortunately, today’s support for the HTML5 Form Module is spotty with each browser supporting different parts of the specification. Take a look at Wikipedia’s HTML5 Forms comparison chart. You’ll see each browser supporting a different set of features, but the lowest common denominator they all support is rather small.

But I Want To Use It Now!!!

HTML5 Forms started off as WebForms 2.0 back in 2004, so I wasn’t surprised to see that a few developers had already coded some JavaScript implementations. Weston Ruter’s cross browser library, webforms2.js, implements a huge chunk of it, including parts that didn’t make the transition from WebForms 2.0 to HTML5 forms (e.g. Webform 2.0′s Repetition Model).

Since widgets weren’t implemented in webforms2, I created html5Widgets.js. This interface library is independent of webforms2 – if all you want is a cross-browser HTML5 form with validation, then all you need is the original webforms2.js. If you want special widgets that are not available for all browsers, include html5Widgets.js. Since I did not want to re-invent the wheel by creating widgets from scratch, html5Widgets.js uses some really nice third party JavaScript libraries to create them (more on that below). It also uses Modernizr to detect if there is native support for each of the HTML5 form widgets – if not, html5Widgets steps in to put the right widget in place. To save bandwidth, developers only need to include the third party libraries for the widgets they need.

In the rest of this article, I will go over different parts of the HTML5 specification and show how you can use them in your applications today, step-by-step. Each section will state which browser natively supports that part of the specification, and what is needed for browsers that don’t. Eventually, when the browser manufacturers catch up with the standard, you won’t need to use any JavaScript at all.

Form Validation Using the required and pattern Attributes

The required attribute makes an input field mandatory and forces the user to enter in a value in order to submit the form data. The markup is simple

<input type="text" name="firstName" value="" required="required" />

(Note:, you can also just use required on its own if you aren’t trying to be XHTML compliant.)

The pattern attribute forces the user to enter in a value using a specified format. It uses regular expressions to define this format. For example, if you want to force the user to input a U.S. Zip Code inside a form field, you would use the following markup.

<--
     zip code regular expression from
     http://www.breakingpar.com/bkp/home.nsf/0/87256B280015193F87256F6B005294C2
-->
<input type="text" name="zipCode" value=""
   pattern="\d{5}([\-]\d{4})?" required="required"  />

Note that required and pattern are independent from each other. You can have a pattern set on a form field without it being mandatory (i.e. the pattern would only be checked if the user enters in data into the field).

Opera 10+ (mobile and desktop editions) is the only browser that supports the validation routines natively. To use this in all other browsers, all you need is to include the following script tags in the head of your document.

<script type="text/javascript" src="/path/to/archive/js/weston.ruter.net/webforms2/webforms2_src.js">
</script>

Let’s take a look at how this looks visually:

Opera 10+ Windows	Firefox 3.6 with webforms2.js

Note the “starred” style of the form field — this is not the default look and feel of the required fields, but something I added with a simple amount of CSS:

input[required], select[required] {
	background: #ffffee url("../images/asterix.gif")  no-repeat left 2px;
	padding-left: 1.5em;
	width: 13.5em !important;
}

(This CSS does not work in Internet Explorer 6. Given that everything else in this article does, I hope the reader will overlook this one oversight considering that this browser should have entered retirement years ago (and have its driving license taken away, and shipped off to some really horrible nursing home watching really crappy talk shows all day and eating bad food …)

See an example of pattern and required in action.

Note that the same validation framework checks the values of inputs of type email, url and number to ensure that the values are in their respective valid formats. As an added bonus, if you are using the iPhone or iPad version of Safari, the virtual keyboard that appears will be optimized for these type of form fields (e.g. when editing a number field, the keyboard that appears contains only digits and the “+”, “-”, and “.” keys. This is native behaviour for iOS, and I hope other mobile browsers, such the Android’s, follow suit.

The autofocus Attribute

The autofocus attribute allows developers to choose which element has focus when the page is loaded. The Google front page has done this via JavaScript, and now, 12 years later, there is finally an HTML attribute to easily handle this.

<input type="text" name="fullName" value=""
  required="required" autofocus="autofocus" />

Safari, Chrome and Opera support it natively. To make it work in other browsers, include the webforms2.js library, as we did in the required and pattern examples.

See an example of autofocus in action

The placeholder Attribute

A placeholder is a great visual cue to communicate any special information about a field (e.g. a description
of the data to be input, if the field is required, etc).

An example of placeholder text. The text disappears when the field has focus or if the user types information into the field.

Syntax is simple:

<input type="text" name="fullName" value="" required="required"
   placeholder="Required information" />

Safari, Chrome and Firefox support this attribute natively. To make it work in other browsers, it is necessary to load the html5Widgets library, with the necessary supporting libraries:

<script type="text/javascript"
   src="/path/to/shared/js/modernizr.com/modernizr-1.5.min.js">
</script>

<script type="text/javascript" src="/path/to/shared/js/EventHelpers.js">
</script>

<script type="text/javascript" src="/path/to/shared/js/html5Widgets.js">
</script>

What do these libraries do?

• modernizr is used to detect which HTML5 attributes and tags are supported by the users’ browser
• html5Widgets is what actually does the placeholder logic, with EventHelpers.js providing cross-browser event-handling routines.

See an example of the HTML5 placeholder
tag in action.

The range Input Type and output Tag

Easily my favourite of the HTML5 widgets, range gives developers a sliding control to put inside their forms.

The syntax is simple:

<input type="range"  name="rangeEl" value="" min="0" max="150" step="1" />

The min and max attributes contain the minimum and maximum values, and step denotes by what increments the range slider increments by when moved. Note that you can use these attributes with the number input type as well, but instead of having the fancy interface, it will use the validation engine to ensure the value follows what these attributes dictate.

At the time of this writing, Opera and WebKit based browsers (like Safari and Chrome), support it natively, and html5Widgets uses the Frequency Decoder Slider Widget to implement it in unsupported browsers. To ensure cross-browser HTML5 range element goodness, place the following script tags in your document:

<!-- Needed for Range Element -->
<link type="text/css" rel="stylesheet" href="/path/to/shared/css/slider.css">

<!--[if lte IE 6]>
<link type="text/css" rel="stylesheet" href="/path/to/shared/css/slider_ie.css" />
<![endif]-->

<script type="text/javascript" src="/path/to/shared/js/frequency-decoder.com/slider.js">
</script>

<!-- Needed for Validation -->
<script type="text/javascript" src="/path/to/shared/js/weston.ruter.net/webforms2/webforms2_src.js">
</script>

<!-- Need for HTML5Widgets -->
<script type="text/javascript"
  src="/path/to/shared/js/modernizr.com/modernizr-1.5.min.js">
</script>

<script type="text/javascript" src="/path/to/shared/js/html5.js">
</script>
<script type="text/javascript" src="/path/to/shared/js/EventHelpers.js">
</script>

<script type="text/javascript" src="/path/to/shared/js/html5Widgets.js">
</script>

Take a look at the screenshots below. You will see that the way a range field varies among the browsers that natively support it, and even in some of the browsers that use html5Widgets:

	Explorer 6.x+ (html5Widgets support)	Firefox 3.5+ (html5Widgets support)	Safari 4.0+ (native support)	Chrome 3.0+ (native support)	Opera 10.0+ (native support)
Windows
Mac	Not Applicable
Linux	Not Applicable		Not Applicable

The output tag can be used to show the value of a field, or the result of an operation performed on a number of fields, using JavaScript expressions. Although the output tag may calculate fomulas referencing any form fields, it is useful especially for the range input type so users can see what value the range element is pointing to:

<output onforminput="this.value = rangeEl.value">-</output>
<input type="range"  name="rangeEl" value="" min="0" max="150" step="1" />

The contents of the output tag is the default value. Note the this.value syntax – I am not sure why the W3C HTML5 working group decided it was needed (why not just have the formula?), but it is. If there are other types of expressions supported in the final specification, they are not supported by html5Widgets at this time. Note that in order to apply CSS to the output tag in IE, it is necessary to use Remy Sharp’s HTML5 Enabling Script.

See an example of the range input being used with the output tag.

See an example of the output tag being used without a range field.

The datetime, datetime-local, date, week and week Input Types

At the time of this writing, Opera is the only desktop browser that supports HTML5 date fields. To support the other browsers, html5Widgets uses a slightly modified version of DynArch.com‘s Ex-”Coolest” DHTML Calendar (I decided not to use the coolest one because the Ex-Coolest has a more permissive license and it works really well). Now all browsers can support the datetime, datetime-local, date, month and week input fields, and submit these values in a consistent format.

Here are the scripts needed for the browsers that need it:

<!-- Needed for Date/Time Elements -->
<link type="text/css" rel="stylesheet" href="/path/to/shared/js/jscalendar-1.0/calendar-win2k-1.css" />
<script type="text/javascript" src="/path/to/shared/js/jscalendar-1.0/calendar.js"></script>
<script type="text/javascript" src="/path/to/shared/js/jscalendar-1.0/lang/calendar-en.js"></script>
<script type="text/javascript" src="/path/to/shared/js/jscalendar-1.0/calendar-setup.js"></script>

<!-- Needed for Validation -->
<script type="text/javascript" src="/path/to/shared/js/weston.ruter.net/webforms2/webforms2_src.js">
</script>

<!-- What glues all the above together -->

<script type="text/javascript" src="/path/to/shared/js/modernizr.com/modernizr-1.5.min.js">
</script>
<script type="text/javascript" src="/path/to/shared/js/EventHelpers.js">
</script>
<script type="text/javascript" src="/path/to/shared/js/html5Widgets.js">
</script>

Note that the calendar widget uses language packs and that I am using the English one (calendar-en.js. Other language packs are included.

Below is a comparison between Opera’s native date widget vs. the one provided by the DynArch/HTML5Widget combo:

	DateTime Widget	Month Widget
Opera Windows
Opera Mac
Firefox 3.5+ Windows (html5Widgets support)

It looks like the native calendar for Opera for Mac is a smaller than the Windows version – hopefully this is just on my copy of the browser.

The display formats, and they values that they submit to the server, are pretty much the same

See the HTML5 date widgets in action.

Note: In this example, The Opera Mobile Windows Emulator incorrectly displays the datetime and datetime-local calendars in the upper left-hand corner of the screen, but not the other ones. Since this is Opera’s own calendar widget, and not html5Widgets’, this bug will have to fixed by Opera.

Screenshot of Opera Mobile bug

The color Input Type

Currently none of the desktop browser manufacturers support the color input type (although the new WebKit based Blackberry browser seems to have a neat implementation). While we wait to see how the major browser manufacturers decide to implement color, you can use html5Widgets’ implementation which uses Jan Odvarko‘s jscolor. The script has been configured to allow only allow lower case hexadecimal rgb values to be entered, and that a blank value not be allowed, as per the W3C spec.

Here are the script tags needed to implement this in all browsers:

<!-- Needed for Color Element -->
<script type="text/javascript" src="../../shared/js/jscolor/jscolor.js">
</script>

<!-- What glues all the above together -->
<script type="text/javascript" src="../../shared/js/modernizr.com/modernizr-1.5.min.js">
</script>

<script type="text/javascript" src="../../shared/js/EventHelpers.js">
</script>

<script type="text/javascript" src="../../shared/js/html5Widgets.js">
</script>

Below is a comparison between the Blackberry’s implementation (grabbed from the Blackberry Development Blog) and HTML5Widget/jscolor’s.

Blackberry Web Browser	Firefox 3.5 with html5Widgets.js

See HTML5Widget’s implementation of the
color input type.

Note: Like other HTML syntax, color uses the unfortunate American spelling instead of the Queen’s Proper English (i.e. colour). Ensure you spell it incorrectly in order to make this work. ;-)

How Well Do These Libraries Handle the Official Specification?

I have done some testing on some existing examples that use HTML5 forms to ensure that it works the way developers expect. Here are a few examples that I have taken, with the necessary JavaScript added:

• A cool looking payment form by Inayaili de León (originally from her HTML5 forms tutorial)
• An HTML5 Form Demo by Richard Bradshaw (originally from his Fancy Forms: HTML5 + CSS3 – JS article)
• Another cool Example by Anne van Kesteren (originally from his article Improve your forms using HTML5! on the The Opera Developer Community Website).

However, the HTML5 Forms specification is large, and unfortunately, the webforms2 and html5Widgets libraries don’t implement everything … yet!!!! Since I am really motivated with what HTML5 forms can do, I am committed to completing support to most, if not all, of the HTML5 Forms specification. The version of webforms2 in this blog post has been modified from Weston Ruter’s original verison, but it will be merged with the official Google Code version in the next week or so and will include compressed versions of all the library. The html5Widgets library will also have a permanent home there.

Things that I will be working on in the near future are:

• Support for other HTML5 form elements, among other things, datalist, number, keygen, progress, time and meter
• Support for CSS styling of HTML5 form widgets as well as the ability to style form fields according to their validation state (e.g. :valid and :invalid psudo-classes). Opera seems to be the only browser currently supporting this.
• Default styling for some of the new input types, like tel, email, url. Opera for Mac and Opera Mobile are the only browsers I know of that support this for email and url.
  

  email and url form fields in Opera Mac

• Support for customizing the validation look and feel. This is one I would love to do, since I’m sure a lot of developers would want to change how validation errors appear on the screen. Unfortunately, the HTML5 specification doesn’t describe a standard way of doing this. It will be interesting to see how the browser manufacturers deal with this issue (To any browser developer reading this is working on the display form validation errors: I would love to know how you are doing this if you are willing to share. Hint, HINT! ;-))
• In Internet Explorer 7 and lower, the ability to style input types it doesn’t support natively with CSS code like input[type="range"]
• Enabling HTML5 forms validation on the server side to ensure data integrity for browser that don’t support HTML5 forms that have JavaScript disabled.
• Support for internationalization of the error messages used in webforms2. If anyone wants to help in the translation of these error messages, please drop me a line — I need help!

Below is a modified version of the Wikipedia’s HTML5 forms compatibility table and see what how things the support situation stands today.

Integrating With visibleIf To Make Even Cooler Looking Forms

The webforms2 and html5Widgets libraries are designed to co-exist well with visibleIf to create interactive forms with fields that only validate the ones that visibleIf is displaying.

See an example of HTML5 validation working with the visibleIf JavaScript library

Acknowledgments, Shout-outs and Kudos

• Faruk Ates and Paul Irish for the definitive HTML5 and CSS3 feature detector, modernizr.
• Weston Ruter for doing the insane amount of work on webforms2 years ago.
• Brian McAllister: for making the excellent Unobtrusive slider control which I used for the range element.
• Mihai Bazon for keeping the The Ex-“Coolest” DHTML Calendar around even though he has a paid product.
• Jan Odvárko for his rocking jscolor widget.
• Remy Sharp for his fine HTML5 Enabling Script so we can force IE to style things like the output tag.
• Inayaili de Leon, Anne van Kesteren and Richard Bradshaw for allowing me to show how easy it is to make their original HTML5 Form demos work with html5Widgets.

Further Reading

• The W3C HTML5 Forms Specification Working Draft: The Working Draft is in “Last call for comments” status, so there may be some last minute changes.
• A Form of Madness: Chapter 10 of Mark Pilgrim’s great reference on HTML5.
• Web Forms 2.0 Working Draft: The WHATWG spec that the W3C spec is based on. It includes the repetition model which didn’t make it into the W3C spec

Download

This archive is the temporary home for html5Widgets. It will soon be hosted at the webforms2 Google Code page. Both html5Widgets and webforms2 both have permanent homes at github (however, the html5Widgets github page contains a copy of webforms2 in it for your convenience). Weston Ruter has been kind to give me deciding rights over the destiny of this code. I will be updating webforms2 in the near future.

Download the latest version of html5Widgets, which includes webforms2, from github.

Update (July 28, 2010):

I have fixed a minor bug in this script to ensure compatibility with webforms2, part of a suite of scripts that implement cross-browser compatibility with the HTML5 forms specification.

I have been following the progression of the HTML5 Forms standard with great interest. It promises a whole slew of new visual and usability goodness to existing HTML forms (e.g. slider and calendar widgets), a client-side validation framework, and so much more. One of the things I was disappointed with, though, was that HTML5 cannot hide and show form elements depending on what the user has input into the form so far. To give a very simple example of what I am talking about, select a country of origin in the form below:

In HTML5, there is no way for a developer to tell the browser “only show me this block of HTML if country == 'Canada'“. This is not a criticism of HTML5 or its authors — HTML5 forms has a lot of awesomeness in it (some of which I will blog about in my next article) and we can’t expect it to do everything. However, I have been using custom JavaScript to do this kind of stuff all the time, and wouldn’t it be great if the JavaScript challenged could do so? In the ideal world graphic designers, J2EE programmers with minimal front-end experience, and even my 75-year-old mom should be able to do this.

As a result, I present a JavaScript library, visibleIf, which allows web developers to use HTML5 custom data attributes to define when blocks of HTML should be visible or invisible. Even if you are not a JavaScript genius, you will be able to make cool looking dynamic forms with very simple markup. For example, let’s take a look at the HTML of the example above:

<form>
    <table class="formTable">
        <tr>
            <th>Country of Origin</th>

            <td><select name="country">
                <option value="">
                    Select One...
                </option>

                <option value="Canada">
                    Canada
                </option>

                <option value="United States">
                    United States
                </option>
            </select> </td>
        </tr>

        <tr class="visibleIf" data-visibleif-rule="country == 'Canada'">
            <th>Postal Code</th>

            <td><input type="text" name="postalCode"
            value="" /> </td>
        </tr>

        <tr class="visibleIf" data-visibleif-rule="country == 'United States'">
            <th>Zip Code</th>

            <td><input type="text" name="zipCode"
            value="" /> </td>
        </tr>
    </table>
</form>

This example is rather simple: the Postal Code form field is shown when country == 'Canada' and Zip Code is shown when country == 'United States'. Note that in order to hide and show a block of HTML, you must set two attributes inside the containing tag:

• class="visibleIf": which lets the visibleIf.js script know that this block of HTML is to be hidden or shown according to the data-visibleif-rule
• data-visibleif-rule='rule expression': which contains the visibility rule. The rule variables are form element names, like country is in the above example. You can do simple equality rules like this, or complex ones like:
  

  <div class="visibleIf"
     data-visibleif-rule="country == 'Canada' && (city == 'Toronto' || city == 'Vancouver')">
    ...
  </div>
  

  If you know a little bit of JavaScript, you will note that you can use JavaScript functions to do interesting rules like:

  <div class="visibleIf" data-visibleif-rule="parseInt(total) > 100">
    ...
  </div>
  

Note that the above examples have visibleIf rules inside a tr tag, they can be used in any tag inside an HTML form.

Although the above example is quite simple, you can use visibleIf to make really complex forms — you can even put visibleIf blocks inside of visibleIf blocks. To illustrate this I have created a more interesting form that shows what can be done using visibleIf.

See a more complex visibleIf form example

Hidden Fields – To Clear Or Not To Clear

If the user does something that hides some form fields (e.g. clicks on a checkbox) and then reverses that action (in this case clicking on the same checkbox), the fields will reappear with any previously filled-in data erased. Developers can override this default behavior by setting the class of the fields that shouldn’t be erased to visibleIf-doNotReset. To illustrate this, I have created a page with two identical forms on it — one that erases the values inside hidden fields, and one that doesn’t. Play with the example and you’ll see what I mean.

See an example of a form with and without visibleIf-doNotReset fields.

Hidden Fields – Submit To The Server, Or Not?

Also note that by default, only the visible form elements are submitted to the server (this is because when a form element is hidden by visibleIf, its disabled attribute is set to true when the form is submitted). If developers wants to override this behavior, they can simply set the form’s class to visibleIf-submitInvisibleData.

See an example of a form with and without visibleIf-submitInvisibleData class set.

The Quick “How-To” Guide”

Setting up your existing forms to use visibleIf is a quick, three-step process:

1. Download the source from the visibleIf Project Page
2. Include the visibleIf.css stylesheet, EventHelpers.js and visibleIf.js JavaScript files into your web page:
   

   <link rel="stylesheet" href="/path/to/visibleIf.css" type="text/css" />
   
   <script type="text/javascript" src="/path/to/EventHelpers.js">
   </script>
   <script type="text/javascript" src="/path/to/visibleIf.js">
   </script>
   

3. Use the visibleIf rules as seen in the example above. Note that &&, || and other logical operators are allowed in the expressions, as are JavaScript functions (e.g. parseInt, parseFloat, etc).

A Note On The Use Of Custom Data Attributes

Why did I bother with custom data attributes when making visibleIf? Why did I just use the attribute data-visibleif-rule instead of just visibleif-rule or just rule to place the visibility rule? Wouldn’t that be simpler?

• data- attributes are HTML compliant: . Their use ensure that visibleIf will be compatible with future versions of HTML since data- attributes are reserved to be used for JavaScript libraries. As long as you use the HTML5 DOCTYPE, your forms should also validate.
• The data-visibleif- prefix will not collide with attributes used in other JavaScript libraries. There is a high chance that data-rule could be used by another library. Using the name of the library in the attribute significantly reduces that possibility.

Download

visibleIf.js v. 2.1 and example code (zip format)

Update (Feb 3, 2009):

• A bug in Webkit seems to be the culprit in the permissions form example below not working correctly in Safari 4. The code has been updated to work around this bug and the article below has been updated. Thanks to russbuelt for pointing this out.
• Apparently, an example made by Apple which I reported not working in Safari does work in Safari 4.0.4 for Mac OS X. Thanks for Scott Straker for this information.


Image Credit: Flickr user svartling

HTML5 Drag and Drop has been talked about a lot lately, but it’s hard to find really useful information about implementing it across multiple browsers. Mozilla, Apple and Microsoft all have pages describing how to use it, but their examples seem to work only in their particular browser (Apple’s example doesn’t even work in their own! Updated, Jan. 11, 2009: Although I have not been able to get this example working on Safari 2.0.4 and 3.1.2 for OS X and 4.0.4 for Windows, I have received word that it works on Safari 4.0.4 on OS X). Remy Sharp’s great article Native Drag and Drop was a good place for me to start — however, the examples didn’t work in Internet Explorer. I also thoroughly enjoyed JavaScript guru Peter-Paul Koch’s humorous and lengthy rant about cross-browser drag and drop headaches where he uses creative and colourful language to describe what he thought of the standard, the browser manufacturers, and the WHAT-WG.

When normal people see the author of the Compatibility Master Tables respond negatively to a web technology, they would probably assume it would be a good sign to stay away from it.

However, I am not normal. With a name like Zoltan, how could I possibly be normal? (and yes, it is my real name).

So, I decided to find out for myself how bad HTML5 Drag and Drop really is. Almost immediately, I understood Koch’s reaction – the browser vendors have not implemented all the same features, and there are even a few quirks in how the features that are implemented work. However, after doing a lot of research, I found a common denominator that works well, with the help of a small bit of JavaScript that smooths out the edges. Despite the implementation flaws, Future-proof HTML5 Drag and Drop is not too hard for developers to use in their own applications. This article will explain how to do this step by step with many examples along the way. By the time you are done, you will be able to write useful drag and drop scripts of your own like in this example:

See an example of HTML5 Drag and Drop in action.

Advantages Over Existing Drag and Drop Implementations

Koch mentioned in his blog post that “Web developers MUST NOT (in the sense of RFC 2119) use HTML 5 drag and drop. They should use old-school scripts instead”. I would argue that developers should use HTML5 drag and drop for the following reasons:

• JavaScript Framework Independent: Most other (but not all) drag and drop implementations are tied into 3rd party frameworks like Dojo, Prototype or jQuery.
• Built-in Browser Support: HTML5 Drag and Drop is supported in Firefox 3.5+, Chrome 3.0+, Safari 3.0+ and Internet Explorer 5.0 (Note: that is not a typo — HTML5 Drag and Drop is based on work done by Microsoft in 1999). Because it is part of HTML5, I assume Opera support should be inevitable.
• Integration With Other Web Applications: the HTML5 specification will allow developers to produce drag and drop scripts that work across frames, and across browser windows.
• Integration With Non-Web Applications: the HTML5 specification also allows users to drag and drop data to and from non-web applications

The Basics of Drag and Drop, Step by Step

In order to save other developers from the headaches I got deciphering cross browser drag and drop, I present the following guide that shows how to do in five easy steps. Every step will describe a set of related concepts, and will show examples, most of which are built on code from previous steps. At the end of each step, I will discuss any issues and interesting bits I came across.

Step 1: Defining a Draggable Object

First you need to define the HTML nodes that you want to drag. Firefox requires that these nodes have their draggable attribute set to "true", Internet Explorer requires that the node must be an <a> tag with (the href attribute set) or an <img> tag.

<a href="#" id="toDrag" draggable="true">This is a draggable item</a>

To show how this works, I have written a very simple page with a the above markup in the <body>:

<!DOCTYPE html>

<html lang="en">
    <head>
        <meta name="generator" content="HTML Tidy, see www.w3.org">

        <title>Test #1: A Simple Draggable Object</title>

      <script type="text/javascript" src="../../shared/js/EventHelpers.js">
      </script>
      <script type="text/javascript" src="../../shared/js/DragDropHelpers.js">
      </script>

        <link rel="stylesheet" type="text/css" media="screen" href=
        "css/test1.css">
    </head>

    <body>
        <h1>Test #1: A Simple Draggable Object</h1>

        <a href="#" id="toDrag" draggable="true">This is a
        draggable item</a>

        <p>Try to drag the red box around. You will see the
        draggable object cloned in every browser except Explorer
        and Chrome.</p>

        <a href=
        "http://www.useragentman.com/blog/2010/01/10/cross-browser-html5-drag-and-drop/">
        Go back to the User Agent Man HTML5 Drag and Drop
        article</a>
    </body>
</html>

Note that this HTML page has two scripts in the <head>:

• EventHelpers.js: this script implements cross-browser event handling routines without the need for a JavaScript framework. All the examples in this article use it, but feel free to refactor all the code in this article to use a third party framework like Dojo, jQuery or whatever framework you like.
• DragDropHelpers.js: among other things that I will get to later, will activate dragging on draggable="true" objects in Safari and Chrome using a built-in copy of Dean Edwards’ cssQuery. It does this by inserting the following CSS code into the HTML document:
  

  [draggable=true] {
    -khtml-user-drag: element;
    -webkit-user-drag: element;
    -khtml-user-select: none;
    -webkit-user-select: none;
  }

  The first two rules allow the dragging of the draggable="true" nodes, while the last two prevent the user from selecting the text within the node (which can cause some unexpected behavior in Webkit browsers). The -khtml properties work in older versions of Safari, while -webkit ones work in newer versions. Without these CSS properties, these nodes will not be draggable when using the Safari web browser

See Example #1: a draggable object

A couple of notes:

1. You’ll notice that when you hover the mouse pointer over the draggable item, it will change to (i.e. I the “move” cursor). This is not the default behavior of the web browser – it is something I added in DragDropHelpers, since I believe that it’s a nice visual cue to show users that an object is draggable (if you don’t want this behavior, it is possible to turn it off in your own scripts by setting DragDropHelpers.showMouseoverCue to false
2. How draggable objects look in the various browsers varies. Here are screenshots of how it looks in Windows web browsers (Note: although all screenshots were taken using Windows XP, similar results occur when viewing under Windows Vista or Windows 7):
   

   Firefox (Windows XP)	Safari (Windows XP)	Explorer & Chrome (Windows XP)

   Note the differences between these three browsers:

   • Firefox for Windows shows a cloned version of the draggable object underneath the mouse pointer when the object is being dragged, while Safari displays a grey box with the text “This is a draggable item” written inside. Explorer and Chrome don’t show any effect at all (We will address this issue later).
   • Since we have not established where we are going to drag our object, all Windows browsers will change the mouse pointer cursor to (a.k.a. the “not-allowed” mouse pointer). This is the expected behavior, and you will see later that it will help the user know where to drop the object.

   On OS X, Firefox and Safari look similar to Firefox for Windows, except that the “not-allowed” mouse-pointer doesn’t show up:

   Firefox (OS X)	Safari (OS X)	Chrome (OS X)

   The Linux browsers don’t have the “not-allowed” mouse cursor either. Also, the cloned version of the draggable object isn’t transparent using the Linux version of Firefox, and Chrome under Linux behaves pretty much the same as on the other platforms (Note: all Linux testing was done using Ubuntu 9.10 using the standard Gnome window manager).

   Firefox (Ubuntu)	Chrome (Ubuntu)

   The fact that Explorer and Chrome don’t have any visual dragging cues bugged me, so I put a “fix” inside DragDropHelpers.js which can be turned on by setting DragDropHelpers.fixVisualCues to true. Let’s look at a slightly refactored version of Example #1 where we insert the following code in the <head>:

   <!DOCTYPE html>
   <html lang="en">
      <head>
         <title>Test #1: A Simple Draggable Object (with visual cues added to Explorer and Chrome)</title>
         <script type="text/javascript" src="../../shared/js/EventHelpers.js"></script>
         <script type="text/javascript" src="../../shared/js/DragDropHelpers.js"></script>
         <script type="text/javascript">
         <!--
         DragDropHelpers.fixVisualCues=true;
         -->
         </script>
   
         <link rel="stylesheet" type="text/css" media="screen" href="css/test1.css" />
   
      </head>
      <body>
   
         <h1>Test #1: A Simple Draggable Object (with visual cues added to Explorer and Chrome)</h1>
   
         <a href="#" id="toDrag" draggable="true">This is a draggable item</a>
   
         <p>Try to drag the red box around.  You will see the draggable object cloned in all browsers.</p>
   
         <a href="http://www.useragentman.com/blog/2010/01/10/cross-browser-html5-drag-and-drop/">Go back to the User Agent Man HTML5 Drag and Drop article</a>
   
      </body>
   </html>
   

See Example #1a, a draggable object with visual cue fix for Explorer and Chrome

Voila! The visual cue now shows up. I’ll explain how this works at the end of the article.

Step 2: Setting Events on the Draggable Object

Now that you have defined an object as draggable, you should attach some events to it so the browser knows what to do while it is being dragged. There are three events that a draggable object can fire:

Event name	Description
dragstart	Fires when the user starts dragging of the object.
drag	Fires every time the mouse is moved while the object is being dragged.
dragend	Fires when the user releases the mouse button while dragging an object.

A developer would attach these events the way they would any other JavaScript event – I use EventHelpers.addEvent, but one could use jQuery’s bind() method, prototype’s Event.observe() or whatever you favourite framework provides for event handling. Developers can also use the old school inline events (i.e. <a href="#" id="toDrag" draggable="true" ondragstart="somefunction();">This is a draggable item</a>), but I try to stay away from using those to seperate document structure from behavior.

Let’s take the example in step 1 and change it so we can log when these events happen to the toDrag node:

<!DOCTYPE html>
<html lang="en">
   <head>
      <title>Example #2: a draggable object with events attached </title>
      <script type="text/javascript" src="../../shared/js/sprintf.js"></script>
      <script type="text/javascript" src="../../shared/js/EventHelpers.js"></script>
      <script type="text/javascript" src="../../shared/js/DragDropHelpers.js"></script>

      <script type="text/javascript" src="js/02-dragObjectWithEvent.js"></script>

      <link rel="stylesheet" type="text/css" media="screen" href="css/test1.css" />

   </head>
   <body>

      <h1>Example #2: a draggable object with events attached</h1>

      <p>Try to drag the red box around.  This page will tell you if the
      object is currently dragging, and will log all <code>dragstart</code>
      and <code>dragstop</code> events</p>

      <p><strong>Is dragging:</strong> <span id="dragEventNotice">no</span>

      <p id="eventLog"><strong>Event now firing:</strong><br /><span id="eventNotice"></span>

      <a class="goBack" href="http://www.useragentman.com/blog/2010/01/10/cross-browser-html5-drag-and-drop/">Go back to the User Agent Man HTML5 Drag and Drop article</a></p>

      <a href="#" id="toDrag" draggable="true">This is a draggable item</a>

   </body>
</html>

In the 02-dragObjectWithEvent.js script, the dragEventNotice node will be used to report whether the user is dragging the object around, and the eventNotice will be used to log what events the user has fired:

var dragObject = new function () {
   var me = this;

   var dragNode;
   var eventNoticeNode, dragEventNoticeNode;

   /* runs when the page is loaded */
   me.init = function () {

      if (EventHelpers.hasPageLoadHappened(arguments)) {
         return;
      }   

      /* The node being dragged */
      dragNode=document.getElementById('toDrag');

      /* The nodes that report to the user what is happening to that node*/
      eventNoticeNode = document.getElementById('eventNotice');
      dragEventNoticeNode = document.getElementById('dragEventNotice');

      /* The drag event handlers */
      EventHelpers.addEvent(dragNode, 'dragstart', dragStartEvent);
      EventHelpers.addEvent(dragNode, 'drag', dragEvent);
      EventHelpers.addEvent(dragNode, 'dragend', dragEndEvent);
   }

   /*
    * The dragstart event handler logs to the user when the event started.
    */
   function dragStartEvent(e) {
      eventNoticeNode.innerHTML =
         sprintf("<strong>%s</strong>: Drag Event started.<br />%s",
            new Date(),  eventNoticeNode.innerHTML);
   }

   /*
    * The drag event reports to the user that dragging is on.
    */
   function dragEvent(e) {
      dragEventNoticeNode.innerHTML = "Currently dragging.";
   }

   /*
    * The dragend event logs to the user when the event had finished *and*
    * also reports that dragging has now stopped.
    */
   function dragEndEvent(e) {
      eventNoticeNode.innerHTML =
         sprintf("<strong>%s</strong>: Drag Event stopped.<br />%s",
            new Date(), eventNoticeNode.innerHTML);
      dragEventNoticeNode.innerHTML = "Dragging stopped."
   }
}

// fixes visual cues in IE and Chrome.
DragDropHelpers.fixVisualCues=true;

EventHelpers.addPageLoadEvent('dragObject.init');

Before we get to the drag events, a word about the coding conventions I use for this and all the other code examples in this article:

• the var me = this line ensures that the script doesn’t confuse the this keyword of the object with the this keyword inside an event handler.
• EventHelpers.addPageLoadEvent() (which is part of EventHelpers.js) will execute dragObject.init when the HTML has loaded. addPageLoadEvent() is based on code from Dean Edwards’ article The window.onload Problem – Solved!. It is similar to jQuery’s $(document).ready()method and prototype’s dom:loaded event.
• This code uses a JavaScript version of sprintf() that I had mentioned in a previous blog post. I have used it in all the remaining examples because I think it makes the code a lot easier to read (however, it is not necessary in order to make HTML5 drag and drop work).

Let’s get back to the drag events — you’ll notice that I have set the dragstart, drag and dragend events. When this page is loaded, it will tell you if the draggable object is currently being dragged, and will log all dragstart and dragstop events on-screen. Click on the example link below and see for yourself:

See Example #2, a draggable object with events attached

Step 3: Setting Events on the Target Object

Step 2 showed us how we can drag an object around the screen and know when each drag starts and ends. Now we need to drop the object. Let’s define a drop target to be an object where draggable objects can be dropped. A drop target can have the following event handlers attached to it:

Event name	Description
dragenter	Fires when a draggable object is first dragged inside an object.
dragover	Fires everytime a draggable object is moved inside an object. Note: if you want to allow the draggable object to be dropped inside this object, you must cancel the default behaviour of this event handler.
dragleave	Fires when a draggable object is dragged out of an object.
drop	Fired when a draggable object is dropped into an object.

If you want an object to become a drop target, you must attach both the dragover and drop events to it. You may ask “I understand why I need to implement drop (after all, it is one half of the term “drag and drop”) but why do I need dragover?” As stated in the table above, the drop event will not fire unless you cancel the default behaviour of the event target’s dragover event. This point is really important and your scripts will not work correctly unless you do this.

You may ask “Why is there even a dragover event in the first place? Isn’t drag sufficient?” (In his article, Peter-Paul Koch asked this question a bit more emphatically that I did). The dragover event object does contain some useful information, such as the coordinates of the mouse pointer inside the event target, (When I created DragDropHelpers, this information allowed me to fix Explorer and Chrome’s visual cue issue that I mentioned in step #1). These coordinates are stored in the properties offsetX and offsetY, except in Firefox 3.5 which keeps these values inside of the event properties layerX and layerY. For convenience, DragDropHelpers includes a method called getEventCoords() that will use the appropriate property to get these values (Note: layerX and layerY are only accurate when the drop target’s CSS position propety is set to relative, absolute or fixed).

To show how to add drop functionality to your code, lets take the code from example #2 and add a drop target:

<!DOCTYPE html>
<html lang="en">
   <head>
      <title>Example #3: a dragable object with a drop target</title>
      <script type="text/javascript" src="../../shared/js/sprintf.js"></script>
      <script type="text/javascript" src="../../shared/js/EventHelpers.js"></script>
      <script type="text/javascript" src="../../shared/js/DragDropHelpers.js"></script>

      <script type="text/javascript" src="js/03-dragObjectWithTargetObject.js"></script>

      <link rel="stylesheet" type="text/css" media="screen" href="css/test1.css" />

   </head>
   <body>

      <h1>Example #3: a dragable object with a drop target</h1>

      <p>Try to drag the red box around and dropping it in the target object.</p>

      <p><strong>Is dragging:</strong> <span id="dragEventNotice">no</span>

      <p id="eventLog"><strong>Event now firing:</strong><br /><span id="eventNotice"></span>
      <a class="goBack" href="http://www.useragentman.com/blog/2010/01/10/cross-browser-html5-drag-and-drop/">Go back to the User Agent Man HTML5 Drag and Drop article</a></p>

      <a href="#" id="toDrag" draggable="true">This is a draggable item</a>
      <div id="dropTarget">This is a "target" object</div>

   </body>
</html>

The drop target will be the <div> with an id of dropTarget. The 03-dragObjectWithTargetObject.js script is the same code in example #2 except we add two event handlers:

• a dragover event that reports where the mouse is inside dropTarget
• a drop event that reports when the drop happened.

var dragObject = new function () {
   var me = this;

   var dragNode, targetNode;
   var eventNoticeNode, dragEventNoticeNode;
   me.init = function () {

   	if (EventHelpers.hasPageLoadHappened(arguments)) {
   		return;
   	}	

   	dragNode=document.getElementById('toDrag');
   	targetNode=document.getElementById('dropTarget');
   	eventNoticeNode = document.getElementById('eventNotice');
   	dragEventNoticeNode = document.getElementById('dragEventNotice');

   	/* These are events for the draggable object */
   	EventHelpers.addEvent(dragNode, 'dragstart', dragStartEvent);
   	EventHelpers.addEvent(dragNode, 'drag', dragEvent);
   	EventHelpers.addEvent(dragNode, 'dragend', dragEndEvent);

   	/* These are events for the object to be dropped */
   	EventHelpers.addEvent(targetNode, 'dragover', dragOverEvent);
   	EventHelpers.addEvent(targetNode, 'drop', dropEvent);

   }

   function dragStartEvent(e) {
   	showMessage("Drag Event started");
   }

   function dragEvent(e) {
   	dragEventNoticeNode.innerHTML = "Currently dragging.<br />";
   }

   function dragEndEvent(e) {
   	showMessage("Drag Event stopped");
   	dragEventNoticeNode.innerHTML = "Dragging stopped."
   }

   function dragOverEvent(e) {
   	var coords = DragDropHelpers.getEventCoords(e);
   	showMessage(sprintf(
   	   "Drag over event happened on node with id %s at coordinate (%d, %d)",
   	   this.id, coords.x, coords.y));
   	EventHelpers.preventDefault(e);
   }

   function dropEvent(e) {
   	showMessage("Drop event happened on node with id " + this.id);
   	EventHelpers.preventDefault(e);
   }

   function showMessage(message) {
   	eventNoticeNode.innerHTML =
   		sprintf("<strong>%s</strong>: %s<br />%s",
   			new Date(), message, eventNoticeNode.innerHTML);
   }

}

// fixes visual cues in IE and Chrome.
DragDropHelpers.fixVisualCues=true;

EventHelpers.addPageLoadEvent('dragObject.init');

(Note: EventHelpers.preventDefault(e) does what you’d expect: it prevents the default behavior of the event handler, similar to prototype’s Event.stop() or jQuery’s event.preventDefault())

See Example #3: a dragable object with a drop target

Note that in the above example, the time that the draggable object’s dragend event fires and the time that the drag target’s drop event fires is not consistant among browsers. Safari and Chrome fire dragend first, while Firefox and Internet Explorer fire drop first.

The two other drop target events, dragenter and dragleave are not absolutely necessary for every script, but let’s add these events to example #3 anyway to see how they work:

var dragObject = new function () {
   var me = this;

   var dragNode, targetNode;
   var eventNoticeNode, dragEventNoticeNode;
   me.init = function () {

      if (EventHelpers.hasPageLoadHappened(arguments)) {
         return;
      }   

      dragNode=document.getElementById('toDrag');
      targetNode=document.getElementById('dropTarget');
      eventNoticeNode = document.getElementById('eventNotice');
      dragEventNoticeNode = document.getElementById('dragEventNotice');

      /* These are events for the draggable object */
      EventHelpers.addEvent(dragNode, 'dragstart', dragStartEvent);
      EventHelpers.addEvent(dragNode, 'drag', dragEvent);
      EventHelpers.addEvent(dragNode, 'dragend', dragEndEvent);

      /* These are events for the object to be dropped */
      EventHelpers.addEvent(targetNode, 'dragover', dragOverEvent);
      EventHelpers.addEvent(targetNode, 'drop', dropEvent);
      EventHelpers.addEvent(targetNode, 'dragenter', dragEnterEvent);
      EventHelpers.addEvent(targetNode, 'dragleave', dragLeaveEvent);
   }

   function dragStartEvent(e) {
      showMessage("Drag Event started");
   }

   function dragEvent(e) {
      dragEventNoticeNode.innerHTML = "Currently dragging.<br />";
   }

   function dragEndEvent(e) {
      showMessage("Drag Event stopped");
      dragEventNoticeNode.innerHTML = "Dragging stopped.";
   }

   function dragOverEvent(e) {
      var coords = DragDropHelpers.getEventCoords(e);

      showMessage(sprintf(
         "Drag over event happened on node with id %s at coordinate (%d, %d)",
         this.id, coords.x, coords.y));

      EventHelpers.preventDefault(e);
   }

   function dropEvent(e) {
      showMessage("Drop event happened on node with id " + this.id);
      EventHelpers.preventDefault(e);

   }

   function dragEnterEvent(e) {
      showMessage("Drag Enter event happened on node with id " + this.id);
   }

   function dragLeaveEvent(e) {
      showMessage("Drag Leave event happened on node with id " + this.id);
   }

   function showMessage(message) {
      eventNoticeNode.innerHTML =
         sprintf("<strong>%s</strong>: %s<br />%s",
            new Date(), message, eventNoticeNode.innerHTML);
   }

}

// fixes visual cues in IE and Chrome.
DragDropHelpers.fixVisualCues=true;

EventHelpers.addPageLoadEvent('dragObject.init');

See Example #3a: a drop target with dragenter and dragleave event handlers

(Note that in Firefox 3.5, a dragleave event will fire just before a drop event, which the other browsers don’t fire dragleave when dropping).

Step 4: Passing Data Between the Draggable and Target Objects

Once a draggable object is dropped into a drop target, the two objects can pass information between them using the drop event’s dataTransfer property. This property has two methods, setData() and getData(). In order to pass data between the two, a developer must use setData() during one of the draggable node’s drag events (e.g. dragstart). The drop target can then receive this data during one of it’s events using the getData() method.

Method	Description
setData(dataType, data)	Sets the data that can be shared between the draggable node and the drag target. Parameters dataType – The type of data that is to be set. So far, the only cross-browser dataTypes that can be set are ‘Text’ and ‘Url’. data – The data that is going to be set.
getData(dataType)	Gets the data that was previously set by dataTransfer.setData(). It can also get data that was set by a dataTransfer.setData() call from another page, another browser window, and another vendor’s web browser on the same machine. It also can get data that was set by a drop event of another desktop application (for example, Windows WordPad). Parameters dataType – The type of data that is to be set. So far, the only cross-browser dataTypes that can be set are ‘Text’ and ‘Url’.

setData() takes one string parameter, which is the data you want to share between the draggable object and a drop target.

Let’s take the code from step #3 and mix it up a bit: instead of having one draggable object, let’s make four. I have taken four photos of the Beatles from the Wikmedia Commons and made them draggable.

<!DOCTYPE html>
<html lang="en">
   <head>
      <title>Test 4: setData() and getData()</title>
      <script type="text/javascript" src="../../shared/js/sprintf.js"></script>
      <script type="text/javascript" src="../../shared/js/helpers.js"></script>
      <script type="text/javascript" src="../../shared/js/DragDropHelpers.js"></script>

      <script type="text/javascript" src="js/04-setDataGetData.js"></script>

      <link rel="stylesheet" type="text/css" media="screen" href="css/test1.css" />

   </head>
   <body>

      <h1>Test 4: <code>setData()</code> and <code>getData()</code></h1>

      <img draggable="true" src="images/george.png" alt="George Harrison" />
      <img draggable="true" src="images/john.png" alt="John Lennon" />
      <img draggable="true" src="images/paul.png" alt="Paul McCartney" />
      <img draggable="true" src="images/ringo.png" alt="Ringo Starr" />

      <div id="dropTarget"><span>Drop an image here to find out more information about it.</span></div>

   </body>
</html>

The script 04-setDataGetData.js uses dataTransfer.setData() and .getData() to copy the <img> of the Beatle being dragged, as well as placing the alt attribute’s contents underneath the image.

var dragObject = new function () {
   var me = this;

   var targetNode;
   var eventNoticeNode, dragEventNoticeNode;

   var dataTransferCommentString;

   me.init = function () {

      if (EventHelpers.hasPageLoadHappened(arguments)) {
         return;
      }   

      targetNode=document.getElementById('dropTarget');
      eventNoticeNode = document.getElementById('eventNotice');
      dragEventNoticeNode = document.getElementById('dragEventNotice');

      /* These are events for the draggable objects */
      var dragNodes = cssQuery('[draggable=true]');
      for (var i = 0; i < dragNodes.length; i++) {
         var  dragNode=dragNodes[i]
         EventHelpers.addEvent(dragNode, 'dragstart', dragStartEvent);
      }

      /* These are events for the object to be dropped */
      EventHelpers.addEvent(targetNode, 'dragover', dragOverEvent);
      EventHelpers.addEvent(targetNode, 'drop', dropEvent);
   }

   function dragStartEvent(e) {
      e.dataTransfer.setData('Text',
         sprintf('<img src="%s" alt="%s" /><br /><p class="caption">%s</p>',
            this.src, this.alt, this.alt
         )
      );
   }

   function dragOverEvent(e) {
      EventHelpers.preventDefault(e);
   }

   function dropEvent(e) {
      this.innerHTML = e.dataTransfer.getData('Text');
      EventHelpers.preventDefault(e);
   }

}

// fixes visual cues in IE and Chrome.
DragDropHelpers.fixVisualCues=true;

EventHelpers.addPageLoadEvent('dragObject.init');

See Example #4: using setData() and getData()

As previously mentioned the data that is set in setData() can be read in other applications. If you are in Windows, open up WordPad and drag one of the images into it. You’ll see the data that was given to setData() during the dragstart event.

This interoperability with the operating system will allow developers to do some very interesting things which are out of the scope of this article. I will, however, want to explore this in future postings.

Step 5: Drag and Drop Effects

In a traditional desktop application, you can use drag and drop to copy objects, move objects, and create links to things. You can use the HTML5 drag and drop events to do this as well, but it would be nice to give the user visual cues to show what kind of action a draggable object can do, and what kind of action a drop target can accept. It would also be nice to only allow “copy objects” to only drop on drop targets that are programmed to accept them.

These features can be implemented using e.dataTransfer.effectAllowed on the draggable object and e.dataTransfer.dropEffect()on the drop target:

Method	Description
e.dataTransfer.effectAllowed	Sets the type of effect a draggable object is allowed to make. Valid values are copy, move, link, copyMove, copyLink, linkMove, all, and none.
e.dataTransfer.dropEffect	Sets the type of effect a drop target is allowed to accept. Valid effects include copy, move, and link.

When these are set correctly, drag and drop will only work when the draggable object’s effectAllowed and the drop target’s dropEffect are compatible. To illustrate this, let’s first change the dragstart and dragover events in example #4 to do the copy effect:

   function dragStartEvent(e) {
      e.dataTransfer.effectAllowed="copy"; 

      e.dataTransfer.setData('Text',
         sprintf('<img src="%s" alt="%s" /><br /><p class="caption">%s</p>',
            this.src, this.alt, this.alt
         )
      );
   }

   function dragOverEvent(e) {
      e.dataTransfer.dropEffect = "copy";
      EventHelpers.preventDefault(e);
   }

Example #5: matching drag and drop effects

Note that unlike example #4, the mouse pointer has changed from the copy icon (in Windows, ) to the move icon ().

Now let’s change the code so that the draggable object and the drop target don’t have matching effects:

   function dragStartEvent(e) {
      e.dataTransfer.effectAllowed="copy"; 

      e.dataTransfer.setData('Text',
         sprintf('<img src="%s" alt="%s" /><br /><p class="caption">%s</p>',
            this.src, this.alt, this.alt
         )
      );
   }

   function dragOverEvent(e) {
      e.dataTransfer.dropEffect = "move";
      EventHelpers.preventDefault(e);
   }

See Example #5a: unmatching drag and drop effects

You’ll see that the user is not able to drop the image on the drop target.

Update (Jan 28, 2010): There is a documented bug in Safari and Chrome for Windows where drag and drop will not occur if effectAllowed and dropEffect are set to move. This bug does not occur in the Mac editions of these browsers.

A More Complex Example

Let’s take all the information we have gathered and make a “real-world” script. Let’s say you were asked to create a “user entitlement” administration widget for a website. The widget will have three entitlement catagories: “Unassigned Users”, “Restricted Users” (e.g. users who have restricted access to the website) and “Power Users” (e.g. users who would have administration access to a website):



Screenshot of the user entitlement screen we want to implement

It should be rather easy for an administrator to drag and drop users back and forth between entitlement “buckets” in order to elevate or lower a users credentials.

Let’s go through the steps we established above to implement this script.

Step 1: Defining a Draggable Objects

First let’s take a look at the table in the HTML:

<table>
    <thead>
        <tr>
            <th>Unassigned Users</th>
            <th>Restricted Users</th>
            <th>Power Users</th>
        </tr>
    </thead>

    <tbody>
        <tr>
            <td id="unassignedUsers">
            	<a href="#" draggable="true">Moe Howard</a>
		<a href="#" draggable="true">Curly Howard</a>
		<a href="#" draggable="true">Shemp Howard</a>
            	<a href="#" draggable="true">Larry Fine</a>
	    </td>

            <td id="restrictedUsers">
            </td>

            <td id="powerUsers">
            </td>
        </tr>
    </tbody>
    <tfoot>
	<td id="unassignedUsersHelp">
	  Drag a user from this list to another list to change the
	  user's permissions.
	</td>
	<td id="restrictedUsersHelp">
	  Dragging user here will give this user restricted
	  permissions.
	</td>
	<td id="powerUsersHelp" >
	  Dragging a user here will give this user power user access.
	</td>
    </tfoot>
</table>

(Note that the contents in the tfoot node are hidden by CSS).

Step 2: Setting Events on the Draggable Objects

The “users” are draggable objects. In the script, we find all these nodes using Dean Edwards’ cssQuery and set dragstart and dragend event handlers on each of them (Note: cssQuery allows us to select nodes by CSS selector, similar to the built-in functionality inside jQuery).

userNodes = cssQuery('[draggable=true]');
for (var i=0; i<userNodes.length; i++) {
   EventHelpers.addEvent(userNodes[i], 'dragstart', userDragStartEvent);
   EventHelpers.addEvent(userNodes[i], 'dragend', userDragEndEvent);
}

It then keeps track of the current node being dragged in the object variable currentlyDraggedNode and makes that node transparent by making it a member of the draggedUser class, which the page’s stylesheet defines as transparent.

function userDragStartEvent(e) {
   currentlyDraggedNode = this;
   currentlyDraggedNode.className = 'draggedUser';
}

The dragend event removes the transparency of the currentlyDraggedNode:

function userDragEndEvent(e) {
   currentlyDraggedNode.className = '';
}

Step 3: Setting Events on the Target Objects

All the table cells in the <tbody> are drop targets, so we use cssQuery again to grab all those nodes and set the appropriate events.

userListNodes = cssQuery('.userList');

for (var i=0; i<userListNodes.length; i++) {
   var userListNode = userListNodes[i];
   EventHelpers.addEvent(userListNode, 'dragover', cancel);
   EventHelpers.addEvent(userListNode, 'dragleave', userDragLeaveListEvent);
   EventHelpers.addEvent(userListNode, 'drop', userDropListEvent);
   EventHelpers.addEvent(userListNode, 'dragenter', userDragOverListEvent);
}

The most important event is the drop event handler. This event handler takes the currentlyDraggedNode, removes it from its current table cell (using removeChild()) and drops it into the drop target (using appendChild()).

function setHelpVisibility(node, isVisible) {
   var helpNodeId = node.id + "Help";
   var helpNode = document.getElementById(helpNodeId);

   if (isVisible) {
      helpNode.className =  'showHelp';
   } else {
      helpNode.className =  '';
   }
}

function userDropListEvent(e) {
   currentlyDraggedNode.parentNode.removeChild(currentlyDraggedNode);
   this.appendChild(currentlyDraggedNode);
   setHelpVisibility(this, false);
   userDragEndEvent(e);
}

They show the contents of the table cell below it by making it a member of the class showHelp. They also

prevent the dragover default behaviour so that drop events will fire in the drop target.

function userDragOverListEvent(e) {
   setHelpVisibility(this, true);
   EventHelpers.preventDefault(e);
}

The dragleave re-hides the contents of the table cell below it.

function userDragLeaveListEvent(e) {
  setHelpVisibility(this, false);
}

function userDragEndEvent(e) {
   currentlyDraggedNode.className = '';
}

Steps 4 and 5

We do not actually pass any data between the draggable object and the drag target — when the drop event occurs, the draggable object is moved from one column to another without the need of any dataTransfer data. The drag and drop effects were already handled in step 3, so we are all done.

See the above example in action

Drag and Drop Between Frames

Using the above information, it is also possible to drag and drop objects between frames (this is something that I don’t think any old school drag and drop script can do). I made an example below, and I leave it as an exercise to the reader to go through the code and figure out how it works.

See the inter-frame drag and drop example in action

Cross-Browser Issues I Have Seen

These are the cross-browser issues I know of so far. I will update this list with others I find in the future.

• in Firefox 3.5, a dragleave event will fire just before a drop event, which the other browsers don’t fire dragleave when dropping.
• the time that the draggable object’s dragend event fires and the time that the drag target’s drop event fires is not consistant among browsers. Safari and Chrome fire dragend first, while Firefox and Internet Explorer fire drop first.
• According to Francisco Tolmasky, setData() cannot be called during drag events in Firefox. Hopefully this will be fixed in a future release of the browser.
• DragDropHelpers implements a workaround for Explorer so it can drag any object around. However, I did not use this functionality in any of the examples because it exposes a problem with Safari not being able to drag an object correctly when the user initiates the drag on the text inside it. This problem doesn’t happen with text inside of links, but with text inside other nodes (like a <div> tag). I understand this problem has been fixed in the Safari nightly builds, so I left the functionality in the DragDropHelpers library for future use.
• DragDropHelpers.js “fixes” the dragging visual cues in Explorer and Chrome by:
  • making a transparent and absolutely positioned clone of a draggable object when it’s dragstart event is fired
  • moving the cloned object near the mouse when the <body>‘s drag event is fired.
  • destroying the clone when draggable object’s dragend event is fired.

  I didn’t turn it on by default because I am not sure when (or if) this problem will be fixed in Internet Explorer or Chrome. I also doesn’t work well when dragging objects from one window or frame to another, since the cloned visual cue can’t jump from page to page. Feel free to use it (or not) as you see fit.

• As mentioned previously, because of a bug in Webkit, drag and drop will not occur if effectAllowed and dropEffect are set to move in Safari 4.0.4. Hopefully this will be fixed in a future version of Webkit.

Conclusion

HTML5 drag and drop will be an important part of our front-end toolkit. Even though the flavors that browser-vendors offer today are incomplete, it is possible to smooth out these flaws to produce useful web applications. What I have covered here only scratches the surface – there are more properties and methods that some of browsers offer that can be used to further enhance the drag and drop experience. But I have been working on this blog entry way to long, and my wife is giving me that “what the hell are you doing up at this hour” look, so I think I’ll stop here for now.

Download

DragDropHelpers, and all code used in this article can be downloaded below.

DragDropHelpers.js v.1.0a and sample code.

]]> http://www.useragentman.com/blog/2010/01/10/cross-browser-html5-drag-and-drop/feed/ 58