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

In the last few months, I have written two articles where I discussed a few strategies to do CSS3-style transforms in IE (CSS3 Text-Shadow – Can It Be Done in IE Without JavaScript? and CSS Blurred Text-Shadow in IE — Part I). While demonstrating the possibilities to creating a varied range of text-shadows in IE, there wasn’t any silver bullet that produced what I considered one of the Holy Grails of CSS polyfills: a method that could take an existing page and render multiple CSS3 text-shadows in IE with few, if any, changes to the CSS code. To that end, at the end of my last article, I dropped the gauntlet at the end of my last article and challenged the web development community to help come up with a better solution. I got a few takers, but one stood out from the rest. Kazumasa Hasegawa submitted his script and blog post (in Japanese and then in English) about his script that could do exactly what I asked: full CSS3-style text-shadowing in IE. It can do multiple blurred and unblurred shadows per block of text. The only caveat is that one would have to set the CSS selectors inside a JavaScript file. However, the code was extremely well written, and it was very easy for me to refactor it to become a plug-in for my CSS3 polyfill library, cssSandpaper. Now, all a developer has to do now is include a few <script> tags into the <head>, and BAM!!! — instant text-shadow goodness in IE7+.

Yeah Whatever! Show Me Proof!

If you are viewing this page in IE7+, here are the droids you are looking for:

Live CSS/HTML	IE9	Firefox	Text-Shadow Syntax
Simple			2px 2px 0 #E51919
Blurred			3px 3px 3px #B24C4C
Etched			0px 1px 0px white
Flaming			0px 0px 4px white, 0px -5px 4px #FFFF33, 2px -10px 6px #FFDD33, -2px -15px 11px #FF8800, 2px -25px 18px #FF2200
Neon			0 0 1px #ffffff, 0 0 2px #ffffff, 0 0 3px #ffffff, 0 0 4px #ff00de, 0 0 7px #ff00de, 0 0 8px #ff00de, 0 0 10px #ff00de, 0 0 15px #ff00de;
Unfocused			0 0 3px #fff
Glowing			0 0 20px yellow, 0 0 60px yellow
Embossed			-1px -1px white, 1px 1px #333333
Pillow			1px 1px white, -1px -1px #444
Fake 3D			1px 1px rgba(255,128,0,.7), 2px 2px rgba(255,128,0,.7), 3px 3px rgba(255,128,0,.7), 4px 4px rgba(255,128,0,.7), 5px 5px rgba(255,128,0,.7)

(Note that the Blur example does not appear correctly in IE7 and 8, due to lack of support of the transparent color)

These examples were inspired by these excellent examples on the web:

• Text-shadow, Photoshop like effects using CSS by CSS3.info (cssSandpaper version)
• Using CSS Text-Shadow to Create Cool Text Effects from Chris Spooner (cssSandpaper version)
• 8 css3 text-shadow effects by Fatma Alemadi (cssSandpaper version)

How Can cssSandpaper Give Me text-shadow Goodness?

1. Download the code from github.
2. Include the following in the head of the document you have text-shadowing on:
   

   <script type="text/javascript" src="/path/to/EventHelpers.js">
   </script>
   <script type="text/javascript" src="/path/to/textshadow.js">
   </script>
   <script type="text/javascript" src="/path/to/cssQuery-p.js">
   </script>
   <script type="text/javascript" src="/path/to/cssSandpaper.js">
   </script>
   

3. It should now work in IE. With the HTML5 Doctype, you can remove the type="text/javascript" attributes.

Download the latest version of cssSandpaper with IE text-shadow support.

Okay, What Are The Caveats

Like any polyfill solution, there are a few things one has to keep in mind when using a solution like this.

1. As you can see from the above examples, blurred text-shadows in IE look slightly different because of the different algorithm IE’s Blur Visual Filter uses compared to what CSS3 text-shadow uses. This is not so obvious on the second example above, but becomes more obvious the more blurred text-shadows are applied on the same text. For most applications, this is acceptable, but for those of us who like to pixel-bitch (i.e. complain when something is not pixel-perfect), you should be aware of this difference (No, I don’t know where I got that term from. I may have made it up. Anyone else heard of it before?)
2. Creating a large text-shadow blur (i.e. greater than 70px) on a large piece of text can cause Internet Explorer’s rendering engine to slow down when the text is scrolled into view.
3. Sometimes IE cuts off the shadows when the line-height is too small:
   
   

   The letter 'P' and other letters with descenders may get cut off if the line-height is not set to be larger than the actual font-size.

4. In IE7-8, elements above text-shadowed text that have a line-height property measured in em units may effect the text-shadow in IE. If there is a problem, the shadow is one pixel off from where it is supposed to be, as shown in this screenshot:
   
   

   Examples of a correct looking text-shadow (left) and a text shadow that is a pixel off (right).

   As you can see from the screenshots above, this problem is much more obvious when there is no blur-radius in the text-shadow. I am trying to see if I can work around this problem, but it looks like it has to do rounding errors when IE converts em units to pixels. If you have a lot em units in your document, you may want to consider using my non-JavaScript solution when using a single, non-blurred text-shadows.

5. Sometimes, in order for the text-shadows to render correctly when using ClearType, you may have to use the -sand-chroma-override CSS property on the HTML you applied the text-shadow on. This property is used by cssSandpaper to fix a problem with ClearType and IE’s Visual Filters, as described in my previous blog post, How to Make ClearType, @font-face Fonts and CSS Visual Filters Play Nicely Together. Most of the time, this property should be set to be the color that that is behind the text value of the background of the text, but sometimes you will have to look at the outline of the texts and the solid shadows to get an idea as to how it should be set. Let’s take, for example, the “Law and Order” style text at the top of this page. We used the following CSS to produce the text-shadow on the “CSS3″ text:
   

   -sand-chroma-override: #666666;
   text-shadow:
   	-4px 0px 0px #0f1128,
   	-8px 0px 4px rgb(50, 152, 234),
   	-10px 0px 4px rgba(50, 152, 234, 0.3),
   	-8px -4px 4px rgba(50, 152, 234, 0.6),
   	-8px 4px 4px rgba(50, 152, 234, 0.6);
   

   Why did I end up using #666666? It is a greyscale color that is roughly between the brightness of the off-white text and the blue shadow. If I set it to black instead, the outline of the text’s first dark text-shadow would be blocky, as seen here:

   	-sand-chroma-override: #000000	-sand-chroma-override: #666666
   Scale 100%
   Scale 300%

   What you set this value to will depend on the text-shadow recipe you are using and, to paraphrase my Mathematics text-books in college, I leave it up to the reader to play around with the -sand-chroma-override value to see what looks best in which situation.

In Conclusion

This script opens up a lot of great possibilities for styling text in IE. There is still some work to be done to make the script even better with some inevitable bugs that will need to be fixed, and I will continue to work on it to make improvements. If you see areas for improvement, or any bugs that you see with the code, please make a comment on the cssSandpaper issues page on github. If you have something to contribute, I would be most grateful. :-)

Other changes that I am planning for cssSandpaper will include:

1. Choice of Selector Library: I will be refactoring cssSandpaper to use other selector libraries besides cssQuery, which is currently bundled with it. This will include, but not restricted to, jQuery. This will allow developers to reduce the number of libraries included in their documents and reduce load time.
2. Modularity: I will make it easy for developers to make their own plugins to support CSS properties not currently supported by cssSandpaper. This module framework will also allow developers to only add support for the CSS properties they want to use (e.g. if a developer doesn’t use any CSS3 transforms, then they don’t have include that code or supporting libraries, like Sylvester.js).
3. Only Download Code If Needed: I want to make cssSandpaper only download plugins if actually needed. This will probably be done with Alex Sexton’s and Ralph Holzmann’s excellent yepnope.js library. While this library can be used today to speed things up, I want to look into making a little more integrated, if possible.
4. Further CSS3 Support: I am looking into polyfills at the moment, like border-image. Any other ideas for plugins will be most welcome.

Download cssSandpaper

Download the latest version of cssSandpaper with IE text-shadow support.

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

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

Update: Jan 6, 2011

Check out Paul Irish’s Mother Effing HSL for a nice color-picker you can play with to get the hang of HSL.

I have heard stories about “those people” that see a color and can immediately calculate the RGB hex code in their head, without any tool whatsoever. Since I have never actually met one of “those people”, I don’t think they really exist. However, it would be a nice skill to have, especially when presenting a new design to a client and they say “Perfect! But can make that box a brighter orange, and that do-hickey a less pronounced purple? And can you show us how it would look right now?”

This seemingly impossible task of coming up with color codes off the top of your head can be done using CSS3′s hsl color notation. HSL is a much more “human-friendly” notation than RGB, and with it you can code colors in your head easily without using The GIMP’s or Photoshop’s color-wheel.

Don’t believe me? Read on and I’ll show you. You’ll never want to go back to RGB again. And even though IE 6-8 doesn’t support HSL natively, we will cover how support can be added.

Notation

An HSL color code uses the following CSS3 notation:

#myObject {
    background: hsl(120, 50%, 50%);
}

The first number is the hue, the second number is the saturation, and the third is the lightness. These three terms are what HSL stand for. But how does one manipulate these numbers? Easily.

Step 1: “Young Guys Can Be Messy Rascals”

Memorize this sentence. If you do, you will be to remember the six major colors in the HSV color wheel: Yellow, Green, Cyan, Blue, Magenta and Red. These colors are spaced out by angles of 60 degrees. If you follow the mnemonic, you should be able to remember the diagram on the left very easily.

So, if you want to pick green, you would code:

hsl(120, 100%, 50%)

(Don’t worry about the second and third parameters for now … we will get to that in a second).

Blue would be:

hsl(240, 100%, 50%)

Let’s say you wanted a color that is not on the wheel, like purple. Purple is halfway between blue (240°) and magenta (300°) so we should pick something in between:

Think it should be more blue? Choose an angle closer to blue!

Want more magenta instead? Then choose angle closer to magenta:

Note that you do not put use the deg keyword link in CSS3 Transforms. It seems a little inconsistent, but at least it’s less typing.

Step 2: Choose Your Intensity

The second parameter is the colorfulness, or saturation. The larger the percentage, the more “colorful” this color is. Let’s take a look at what happens when we change green’s (120°) colorfulness:

The more the saturation percentage, the less “gray” it is.

Step 3: Lighten it up

The final step is to lighten up the color to the right level. That can be done with the final parameter:

That’s It!

Try it when you are using color on your next project. You’ll find using the HSL color-space is much easier than using RGB

Browser Support

HSL is supported in almost all the major browsers: Firefox 3.0+, Safari 3.0+, Chrome 5.0+, Opera 10+ and Explorer 9.0+. For the browsers that don’t support it, I have updated cssSandpaper to implement HSL with the CSS color property, as well as the border, background family of properties (i.e. border-right, background-color, etc).

Also supported by cssSandpaper is HSLA, which is to HSL, as RGBA is to RGB. It contains a fourth element, the alpha channel, that is a number from 0 to 1. To illustrate how this works, let’s say an HTML element has a grid as a background image. How can you shade that background image so that it looks, say, more green?

The table above is not an image — it is a real example of hsla() in action. Pretty neat, huh? You can also use HSL and HSLA color in gradients. The cssSandpaper library has supported WebKit style gradients with it’s own -sand-gradient property. Now it supports HSLA gradients, like this 80% opaque yellow to 20% opaque blue linear gradient:

Unfortunately, cssSandpaper only supports HSLA for background coloring only, not border or text coloring, but one would just use progressive enhancement to take care of that edge case, since what it does support, in my humble opinion, is rather cool. Download the latest version from the link below and use HSL and HSLA color notation now! You’ll impress your developer friends with your off-the-top-of-your-head color-coding skillz. :-)

Get the latest version of cssSandpaper from the official documentation 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)

When I released cssSandpaper a few months ago, I was disappointed that I couldn’t support CSS3 transform’s translate() function in IE due to a limitation in the DXImageTransform.Microsoft.Matrix CSS filter. However, with the gracious help of Nicola Rizzo (who has already used his Matrix filter skills coding a really cool dojox transformation plugin) and Tomasz Tunik, we now have a version of cssSandpaper that supports it. I also got a few requests to have IE support for CSS3 gradients that can use the rgba() color space, and with the help of information on CSS3 Please, it was easily added.

transform: translate

The CSS transform property allows for 2D translations of a box. What this means is, no matter which way you want to rotate or skew the object, you can move the object horizontally and vertically from the object’s perspective. Some of you may ask “How is this different from changing the object’s top and left properties? Let’s take a look at an example below to see how it differs:

An example of CSS3 transform: translate() using cssSandpaper (click the image above to see it in action)

In the example above you’ll see two white boxes, one without any transforms performed, and the other translated 200 pixels to the right. Just what you would expect. Now take a look at the two red boxes … they are both rotated 45 degrees, but the second one is then translated 200 pixels to the right from the object’s perspective.

The translations are done with some very simple CSS:

/*
 * This object is rotated 45 degrees and then translated 200 pixels to the
 * right and 100 pixels down, with respect to the object's perspective
 */

#o2 {
	-sand-transform: translate(200px, 100px);
}

translate() takes two parameters, the x and y translation offsets (currently, cssSandpaper only supports px units for these offsets). There are also translateX() and translateY() if a developer only wants to translate in one direction.

rgba() Gradients

The rgba color space adds alpha channeling to the rgb color space you know and love. When using it in gradients, developers can make parts of an elements background-color semi-transparent. The two examples below illustrate the effects that be done with rgba().

A few rgba() gradients on top of each other to demonstrate their semi-transparency.

An example of an animation using rgba() gradients (click on the above images to show the examples in action).

The following code illustrates how to perform an rgba() gradient:

/*
 * The following is a horizontal gradient that blends red to blue, with a 50% opacity level
 */

#o2 {
   background-image: -sand-gradient(linear, left top, right top,
      from(rgba(255, 0, 0,  0.5)), to(rgba(0, 0, 255, 0.5)));
}

Note that as before, IE only supports two color gradients that are strictly horizontal or vertical. I hope to support multiple color stops in IE in a future release. Also note that in IE, the alpha channel is removed from an object if you apply a transform on it. This may be a limitation of IE’s Gradient filter, which cssSandpaper uses to implement CSS3 gradients.

In order to translate rgba() notation to ARGB notation with IE’s gradient filter understands (e.g. #aarrggbb, where aa are two hex digits representing the amount of opacity), I modified Stoyan Stefanov‘s RGBColor script (which translates from one color notation to another) and added ARGB support.

For information about the rgba color space, read the CSS3.info’s brief introduction to Opacity and RGBA.

Future Roadmap

There is quite a bit more I would like to see cssSandpaper support, including:

1. solid rgba() background colors: this should be quite easy to support, given it is a special case of an rgba() gradient (i.e. a transition from a color to the same color).
2. CSS3 transitions: performing animations with only a bit of CSS would be sweet for those who are afraid of recursive programming with the JavaScript setTimeout() function.
3. transform-origin: modify the origin for transformations of an element (this would allow, for example, developers to produce an animation of planets rotating around the sun, which would be the transform-origin point for all the planets).
4. border-radius: Firefox and Safari have slightly diffferent methods of rounding corners of a block-level element, and it would be useful to simplify this. It would also be nice to have support for it in any version of IE (there are a few excellent solutions involving VML are out there today, but it would be great if there was one that supported all the features that CSS3 supports, including different radii for each corner, as well as co-existance with the other features of cssSandpaper, which may not be an easy thing to do).
5. CSS3 gradients with multiple color-stops: cssSandpaper uses IE’s Gradient filter, which only supports two color-stops.  It would be great to do some JavaScript magic to emulate multiple color-stops.
6. radial gradients in IE: although IE’s Gradient filter doesn’t support it, VML does (I found a really cool example of an VML radial gradient, but it can only be viewed in IE).
7. better support for other units of measure besides px: I personally love to use em units in my design work, and want cssSandpaper to support this and other units, like cm, in, and percentages.

If anyone would like to help me implement these features or any others in cssSandpaper, please contact me either in the discussion below or at the email address at the top of this page (I can really use any assistance anyone can give). Even if you don’t know JavaScript, any comments you have on this library would be most welcome. Let’s prevent older browsers from keeping us from using CSS3 and doing some really cool design work.

Get the latest version of cssSandpaper from the official documentation page