HTML5 Video, minus Ogg

As you’ve probably read somewhere on the interwebs, HTML5 is bringing native video support to browsers. This will enable us to embed a video file directly in our HTML, much like a SWF or image.

Background

You may have also heard that there’s currently a big controversy over what kind of video files will be supported. The defacto standard is MP4/H.264, which is used by Adobe in their Flash video format, and by huge media sites like YouTube. Mozilla, the makers of Firefox, refuse to support the MP4/H.264 standard because it isn’t open-source and free from licensing constraints.

Turns out H.264 is not public domain. Although the company that owns the H.264 patent has temporarily agreed to waive royalty fees for the next decade or so, they reserve the right to charge fees later on. Mozilla says no way, we will only support a video format that is free from licensing issues and has no patent holders (because patent holders can decide to sue some day). Mozilla supports the completely free/open-source Ogg format.

Apple and Adobe, already knee-deep in MP4/H.264 with their Quicktime and Flash video products, vow to press on with H.264.  Google also supports H.264 because YouTube relies on it, and because Google’s new Chrome browser is based on the WebKit project, which has Apple as a main code contributor. In case you haven’t noticed, Apple, Adobe and Google have pretty much cornered the internet video market the past few years, so if they’re throwing their support behind H.264, you can count on it being around for a while. Not to mention that many mobile devices, including the iPhone and most Android phones, have hardware that is designed specifically to support H.264 video, enabling smoother playback and less battery drain than non-dedicated hardware.

(For what it’s worth, Opera is in agreement with Mozilla and supports Ogg. However, not many people seem to pay attention to Opera these days, so they don’t appear to have much influence in this race. Microsoft has endorsed H.264 with it’s upcoming IE9 browser, but it won’t be available for some time.)

The problem

Firefox and Opera are essentially forcing websites to offer two versions of each video: an Ogg version and an MP4 version. In my opinion — and the opinion of many others — this simply will not do. Providing two different video files is not realistic, Ogg’s quality is inferior to H.264, and many computers and mobile devices have direct hardware support for H.264 but not Ogg. In reality, without MP4 support, HTML5 video is rendered useless for most site developers in Firefox and Opera.

The most logical workaround is to code <video> elements to work for MP4 and have a Flash Player-based fallback for older browsers and browsers that only support Ogg. Since the <video> element is designed to allow for fallback content, just like the <object> element, we can do this:


<video id="myvideo" width="480" height="360" controls>
    <source src="/video/file.m4v" type="video/mp4"></source>
    <object data="flash-video-player.swf" type="application/x-shockwave-flash" width="480" height="360">  
        <param value="flash-video-player.swf" name="movie"/>  
        <param value="file=/video/file.m4v" name="flashvars"/>
    </object>
</video>

This works fine in Safari, Chrome, Internet Explorer and older versions of Firefox and Opera that don’t support the <video> element. However, Firefox 3.6 and Opera 10.5 do something very irritating: even though they KNOW their <video> doesn’t support “video/MP4”, they load the <video> element anyway. Which is … like … OMG so duh … because the video can’t possibly play!

If the <video> element is loaded, Firefox and Opera will never load the fallback <object> containing the Flash-based fallback.

Because this behavior cannot be fixed with markup, we’re forced find a scripted workaround (notice that we haven’t used a single bit of JavaScript yet). Thankfully, there’s a pretty straightforward solution: Delete the <video> element in Firefox and Opera.

A Solution

Here’s a simple script that will detect whether HTML 5 video is supported, and if it is, will check to see if MP4 is supported. If HTML5 video is supported but MP4 is NOT supported, the script deletes the specified <video> element but leaves the Flash fallback in its place.


var detectVideoSupport = function (){
    var detect = document.createElement('video') || false;
    this.html5 = detect && typeof detect.canPlayType !== "undefined";
    this.mp4 = this.html5 && (detect.canPlayType("video/mp4") === "maybe" || detect.canPlayType("video/mp4") === "probably");
    this.ogg = this.html5 && (detect.canPlayType("video/ogg") === "maybe" || detect.canPlayType("video/ogg") === "probably");
    return this;
};

var replaceVideoWithObject = function (video_id){    
    if(!video_id){ return false; }
    var video = document.getElementById(video_id);
    if(video){
        var obj = video.getElementsByTagName("object")[0];
        if(obj){
            var obj_copy = obj.cloneNode(true);
            video.parentNode.insertBefore(obj_copy, video);
            video.parentNode.removeChild(video);
        }
    }
};

window.onload = function (){
    var video = detectVideoSupport();
    //Both Opera and Firefox support OGG but lack MP4 support
    if(video.ogg && !video.mp4){
        replaceVideoWithObject("myvideo");
    }
};
</script>

Functioning demo.

A few notes

Tested successfully in:

  • Windows XP: Firefox 3.0, Firefox 3.5.8, Internet Explorer 6, Internet Explorer 8, Google Chrome 4.1.2
  • Windows Vista: Internet Explorer 7
  • Mac OS X (10.6): Firefox 3.6, Safari 4.01, Chrome 5 (beta), Opera 10.1, Opera 10.5b

(Note: IE6, IE7 & IE8 give an unexplained “object required” error in the demo page, but everything works fine. I will investigate as time permits.)

This demo uses the JW Media Player as the Flash fallback video player, but you can use any Flash-based video player on your page.

This demo doesn’t do any Flash Player version detection to ensure the visitor has a supported version of Flash Player. If you need to add Flash Player version detection, you can use SWFObject to embed your Flash file.

Update April 3, 2010: This post was updated to add Opera 10.5 to the list of non-behaving browsers and remove Firefox user agent sniffing.

A new removeClasses utility for MooTools

Note: If you want to skip to the final code (in both MooTools and framework-neutral flavors), it’s at the bottom of this post.

The problem

Readers of this blog know that I enjoy MooTools. Like other JavaScript frameworks, it has many excellent features, including addClass and removeClass functions, which I use all the time. However, when I was working on my CustomInput class the other day, I discovered a major shortcoming of MooTools’ removeClass function — it doesn’t work very well when trying to remove multiple classes (as of MooTools version 1.2.4). In particular, if you specify multiple classes to remove, removeClass will only work if the classes are listed in that element’s className property in the order specified.


//Assuming element has className "hello cruel world"

//Single terms work fine
element.removeClass("world"); //becomes "hello  world"
element.removeClass("hello"); //becomes " cruel world"

//Multiple terms listed in same order as className works fine
element.removeClass("hello cruel"); //becomes " world"

//Multiple terms NOT listed in same order as className fail
element.removeClass("hello world"); //remains "hello cruel world"
element.removeClass("cruel hello"); //remains "hello cruel world"

The cause

A peek at MooTools’ removeClass code reveals the shortcoming:


removeClass: function(className){
   this.className = this.className.replace(new RegExp('(^|\s)' + className + '(?:\s|$)'), '$1');
   return this;
}

The string containing the class names you want to remove is passed as-is; it remains a whole string, and is not broken down into substrings. So "hello world" remains the single string "hello world" instead of two separate strings "hello" and "world".

I tested jQuery’s removeClass function and noticed it doesn’t have the same problem; it will remove each word, no matter what order you specify. Taking a look under the hood reveals a completely different approach to removeClass:


removeClass: function( value ) {
   if ( jQuery.isFunction(value) ) {
      return this.each(function(i) {
         var self = jQuery(this);
         self.removeClass( value.call(this, i, self.attr("class")) );
      });
   }

   if ( (value && typeof value === "string") || value === undefined ) {
      var classNames = (value || "").split(rspace);

      for ( var i = 0, l = this.length; i < l; i++ ) {
         var elem = this[i];

         if ( elem.nodeType === 1 && elem.className ) {
            if ( value ) {
               var className = (" " + elem.className + " ").replace(rclass, " ");
               for ( var c = 0, cl = classNames.length; c < cl; c++ ) {
                  className = className.replace(" " + classNames[c] + " ", " ");
               }
               elem.className = jQuery.trim( className );

            } else {
               elem.className = "";
            }
         }
      }
   }

   return this;
}

The big difference between jQuery and MooTools in this case is that jQuery converts the arguments to an array (split using spaces as a delimiter) then loops through the className property to search for each word in the array, whereas MooTools performs a simple full-string replace using regular expressions.

The search for a solution

My first reaction was to build a MooTools-flavored variation of jQuery’s removeClass code.


Element.implement({
   removeClasses: function (classNames) {
      if(this.className){
         var classNameString = this.className;
         classNames.split(/s+/).each(function (term){
            classNameString = classNameString.replace(term, " ");
         });
         this.className = classNameString.clean();
      }
      return this;
   }
});

It follows the same basic principles of the jQuery version, but uses MooTools’ Array.each and String.clean utility functions. It works well, but I wasn’t thrilled about using a loop. I thought maybe a regular expression would be better suited for the job.

I eventually came up with this:
(purposely verbose to explain what’s happening)


Element.implement({
   removeClasses: function (classNames) {
      if(classNames && this.className){
         //Replace all spaces in classNames with vertical beams
         var terms = classNames.replace(/s+/g, "|");
         //Create a regular expression using terms variable
         var reg = new RegExp('\b(' + terms + ')\b', 'g');
         //Use the new regular expression to replace all specified terms with a space
         var newClass = this.className.replace(reg, " ");
         //Use MooTools' 'clean' method to remove extraneous spaces
         newClass = newClass.clean();
         //Set element's classname to new cleaned list of classes
         this.className = newClass;
      }
      return this;
   }
});
Notes:

  • I’m no expert on JavaScript speed tests, so for all I know a loop might be quicker. However, a regular expression feels more elegant.
  • I named my utility removesClasses so it doesn’t overwrite MooTools’ built-in utility.

Final MooTools version

Here’s a more concise version:


Element.implement({
   removeClasses: function (classNames) {
      this.className = this.className.replace(new RegExp("\b(" + classNames.replace(/s+/g, "|") + ")\b", "g"), " ").clean();
      return this;
   }
});

You can see it in action via the MooShell (apparently the MooTools Shell is no longer online)

Standalone (framework-neutral) version

For those of you who don’t use MooTools, a few small edits will allow you to use this code without relying on any outside JavaScript libraries. First, a verbose version explaining what’s happening:


function removeClass(el, classNames) {
   //Only run if the element is available and supports the className property
   if(el && el.className && classNames){
         //Replace all spaces in classNames with vertical beams
         var terms = classNames.replace(/s+/g, "|");
         //Create a regular expression using terms variable
         var reg = new RegExp('\b(' + terms + ')\b', 'g');
         //Use the new regular expression to replace all specified terms with a space
         var newClass = el.className.replace(reg, " ");
         //Use regular expression to remove extraneous whitespace between class names
         newClass = newClass.replace(/s+/g, " ");
         //Use regular expression to remove all whitespace at front and end of string
         newClass = newClass.replace(/^s+|s+$/g, "");
         //Set element's classname to new cleaned list of classes
         el.className = newClass;
   }
}

The concise version:


function removeClass(el, classNames) {
   if(el && el.className && classNames){
      el.className = el.className.replace(new RegExp("\b(" + classNames.replace(/s+/g, "|") + ")\b", "g"), " ").replace(/s+/g, " ").replace(/^s+|s+$/g, "");
   }
}

Used as follows:


var myelement = document.getElementById("myelement");
removeClass(myelement, "one three");
//<div id="myelement" class="one two three"></div>
//becomes
//<div id="myelement" class="two"></div>

Enjoy!

Successfully tested in Internet Explorer 6 (WinXP), Firefox 3.5 (WinXP), Firefox 3.6 (OS X 10.6.2), Safari 4 (OS X 10.6.2), Opera 10.1 (OS X 10.6.2), Chrome 5 (OS X 10.6.2)

CustomInput Class: Accessible, Custom-Styled Checkboxes and Radio Buttons

I’m a big fan of the Filament Group’s UI work.  They put a lot of thought into their work, and ensure everything they make is not only beautiful, but as accessible and as semantic as possible.

One of my favorite pieces of work by the Filament Group is their approach to stylized checkbox and radio <input> elements, as described in their post Accessible, Custom Designed Checkbox and Radio Button Inputs Styled with CSS (and a dash of jQuery)

The system is remarkably well-constructed, degrades gracefully, and is completely accessible if JavaScript, image loading, or CSS is disabled can’t be loaded. No small feat. Plus it remains semantically sound, with no bloated markup.

Having said all that, I’ve never actually used any of Filment Group’s UI code in my projects because of one little obstacle: they rely on jQuery.  Mind you, I’m not a jQuery hater, but I prefer MooTools and build all my major projects using MooTools. Switching to jQuery for such a small UI customization is not going to happen. I’ve often thought it would be great to build a MooTools version of Filament’s UI examples, but never had the time… until today.

I’m currently working on a new quiz system at work, and decided I’d incorporate Filament’s wonderful stylized checkboxes and radio buttons into my project, which meant it was time to roll up my sleeves and code me some Moo. 

View Demo

I made a couple of changes to the underlying JavaScript to suit a MooTools approach (and add some flexibility with the CSS selectors) but the basic premise is the same as Filament’s demo.

The following JavaScript will style ALL checkbox and radio inputs on your page. Note that CustomInput returns the collection of elements that have been styled.


window.addEvent("domready", function(){ 
    var all_styled_inputs = new CustomInput();
});

If you want to target specific parts of the page or only certain input types, pass a CSS selector as an argument:


window.addEvent("domready", function(){
    //Only style checkboxes
    var styled_checkboxes = new CustomInput("input[type='checkbox']");

    //Only style radios in a div named "walkman"
    var styled_radios = new CustomInput("#walkman input[type='radio']");
});

The CustomInput class has been fully JSLinted, and remains very close to the original jQuery version’s size. When compressed (YUI), it squeezes down to about 1.6kb. It uses ‘dollar-safe’ mode for compatibility with other JS libraries.

It has been successfully tested in the following systems:

Windows XP

  • Internet Explorer 6
  • Firefox 3.5
  • Safari 4
  • Chrome 4
  • Opera 10

Mac OS X (10.6.2)

  • Firefox 3.6
  • Safari 4
  • Opera 10.1
  • Chrome 5 (beta)

View Demo | Download Project Files

Major kudos to Filament Group for sharing their ideas with the world.

Update 3/12/2010: Fixed a typo in the JS file preventing the checkedHover class from being assigned.

Introducing LearnSWFObject.com

I’m happy to introduce you to my latest project, LearnSWFObject.com

It’s been many, many months in the making, and has rudely been put aside a number of times when my life left me no free time to work on it. Happily, I’ve been able to push through the last remaining barriers and get the site out the door. Hopefully someone will find it useful.

I’ve ported my most popular SWFObject tutorials and examples to the new site — updated, of course — and have added a few new tutorials, too. As part of the housecleaning effort, I’ve removed all SWFObject examples and tutorials from pipwerks.com. 301 redirects will re-route the most popular posts to their LearnSWFObject.com equivalent, but the odds and ends have been sent to the compost heap.

I’m most excited about the brand-new code generator (written from scratch) that will write your SWFObject embed code for you. Some notes about the generator:

  • It can write HTML 5, HTML 4 (transitional/strict), and XHTML 1 (transitional/strict) doctypes
  • It provides code for both types of SWFObject embeds: dynamic (JavaScript) and static (markup)
  • It includes a download link that lets you save your generated markup in an HTML file
  • The static publishing option includes an option for a nice, shorter syntax
  • The generator uses progressive enhancement techniques, meaning it’s nicer with JavaScript enabled but fully functional without it

Give it a try!

LearnSWFObject.com will remain a work in progress, as SWFObject itself continues to evolve and people find news ways to break use it in their sites. I will continue to play with the formatting and layout from time to time.

In other SWFObject news, I think I’m allowed to report that SWFObject 2.3 is in the works, and will contain mostly bug fixes and an enhancement or two. Bug reports and feature requests are always welcome at SWFObject’s Google Code site. If you have questions about how to use SWFObject that aren’t answered by the LearnSWFObject.com tutorials, please post them on the SWFObject Google Group.

Gotchas in Internet Explorer 8

Internet Explorer 8 (IE8) is at Release Candidate 1, which means it will be released very shortly. IE8 is a brand-new browser and will represent a considerable shift from IE7/IE6; it will follow standards more closely and will offer much improved CSS 2.1 support. However, because of some of these changes, it is also widely understood that IE8 might break websites that have relied on IE-specific hacks targeted at previous versions of Internet Explorer.

To their credit, the IE development team has been very candid about the changes and have posted a number of blogs and documents aimed at helping web developers prepare for IE8. I was looking over one such page and thought I’d point out what I consider to be some of the biggest ‘gotchas’ so far.

Setting Unsupported CSS Values

Trying to detect support for a specific CSS value through a JavaScript try/catch statement will no longer generate an exception, which means you can’t rely on JavaScript to detect support for specific CSS values anymore.

Assigning CSS values that were unsupported in IE7 but are supported in IE8 Standards Mode will not generate exceptions in IE8 Compatibility View. Some sites use these exceptions to determine if a particular value for a CSS property is supported or not.


try {
   elm.style.display = "table-cell";
} catch(e) {
   // This executes in IE7,
   // but not IE8, regardless of mode
}

Malformed HTML

IE8 will not be as forgiving of malformed HTML markup. This is a great new ‘feature’ in terms of ensuring people (and software) are less sloppy with their markup, but this will certainly cause many, many problems for hundreds of thousands of old, poorly written websites.

Parser error correction for malformed HTML has changed in IE8 Standards Mode. Pages depending on the way IE7 performs error correction may encounter issues as a result.


<ul>
    <li>1.1
        <ul>
            <li>1.1.1</li>
    </li> <!-- Closes 1.1 in IE8, but not IE7 -->
            <li>1.1.2</li>
        </ul>
    </li>
</ul> 

Working with an Element’s Class

Like the malformed HTML ‘feature’, this is another great improvement in IE that will also cause many, many headaches. You see, for years IE wouldn’t let developers use the standard setAttribute("class") method for specifying a class name via JavaScript. Instead, IE required developers to use the proprietary setAttribute("className"). This means that it became commonplace for scripts to check for IE then use class for non-IE browsers and className for IE. Now, you’ll still need to make that check for older versions of IE but find a way to use class for IE8. <sarcasm>This will be fun.</sarcasm>

Don’t get me wrong — I’m excited that IE will finally behave like other browsers in this regard — but it also means that so long as IE6 and IE7 are still around, we’ll have to jump through more hoops to handle class names.

In IE7, “className” had to be used as the attribute name to set and retrieve the class of an element. This has been fixed for standards-compliance in IE8 Standards Mode. Using the old approach will create an attribute named “className” that has no affect on the actual class assigned to an element.


return elm.getAttribute("className");

SOLUTION: Use the standardized name, “class”, instead of “className”.


return elm.getAttribute("class");

CSS Expressions

One of the common hacks for IE’s shortcoming with CSS support has been to use IE’s proprietary CSS expressions, which are basically JavaScript statements embedded in place of a CSS value. While this practice has been frowned upon by most in-the-know web developers, it still wound up being heavily utilized as an ‘easy fix’ type of hack.

IE8 will no longer support CSS expressions. This will make it behave more like other browsers, but will cause problems for those who have relied on CSS expression hacks. Fortunately, it should be relatively easy to move your CSS expressions into your page’s JavaScript as suggested by Microsoft.

Support for CSS Expressions has been removed in IE8 Standards Mode.


/* CSS */
#main {
    background-color: expression(
        (new Date()).getHours()%2 ? "#000" : "#fff"
    );
}

SOLUTION: Refactor to utilize either improved CSS support or DHTML logic.


/* Script */
var elm = document.getElementById("main");
if((new Date()).getHours()%2) {
    elm.style.backgroundColor = "#000";
} else {
    elm.style.backgroundColor = "#fff";
} 

On the whole, I’m excited about the changes IE8 will bring, although it will undoubtedly require site revisions for anyone who uses JavaScript extensively in their projects.

You can read the original Microsoft blog post here.

Lazy loading excanvas.js

excanvas.js is a script that enables developers to use the canvas element in Internet Explorer; since IE doesn’t support canvas or the canvas API, the excanvas script converts (most) canvas commands to Vector Markup Language (VML), the only vector rendering language supported natively in Internet Explorer.

excanvas is designed specifically for Internet Explorer, so most people simply use a conditional comment to load it in IE and avoid loading it in other browsers:


<!--[if IE]>
<script type="text/javascript" src="/scripts/excanvas.js" src="/scripts/excanvas.js">
<![endif]-->

This works fine if you have access to the HTML file that needs to load excanvas, but what if you can’t edit the HTML? This was my predicament with a recent project; I decided to use a lazy loader approach (on-demand loading) and load excanvas.js dynamically.

I started by developing an HTML example page that used the canvas element and had the excanvas.js file hard-coded. Everything worked as planned. I then took out the hard-coded excanvas.js file and replaced it with a JavaScript-based lazy loader. Guess what? It didn’t work.

I scratched my head for a while and did some more testing. The strange thing was that excanvas.js was loading when and where it was supposed to, but the script itself wasn’t firing.

After digging around the excanvas.js source code a bit, I found the problem: the script contains an init function that only gets invoked when the document’s readystate changes. If the document is already loaded, the readystate won’t change and the init function will never fire!

A simple modification to the excanvas.js file fixed the problem:

Original code (starting at line 87 of excanvas.js)


init: function(opt_doc) {
    if (/MSIE/.test(navigator.userAgent) && !window.opera) {
        var doc = opt_doc || document;
        // Create a dummy element so that IE will allow canvas elements to be
        // recognized.
        doc.createElement('canvas');
        doc.attachEvent('onreadystatechange', bind(this.init_, this, doc));
    }
},

Modified version


init: function(opt_doc) {
    if (/MSIE/.test(navigator.userAgent) && !window.opera) {
        var doc = opt_doc || document;
        // Create a dummy element so that IE will allow canvas elements to be
        // recognized.
        doc.createElement('canvas');

        if(doc.readyState !== "complete"){

            doc.attachEvent('onreadystatechange', bind(this.init_, this, doc));

        } else {

           this.init_(doc);

        }

    }
},

Basically all we’re doing is checking to see if the readystate is already “completed” before attempting to do attachEvent. If the state is completed, we don’t need attachEvent and can just invoke this.init_ directly.

Update: Alternate solution

January 2014. Unfortunately, the authors of ExCanvas haven’t addressed this issue yet. Since it has been over 3 years since I submitted an issue on their project site, I assume it will not be addressed. (At this point I can’t blame them, who wants to support old versions of IE anyway?)

However, there is some good news if you still need to use ExCanvas: Willis at badsyntax.co came up with a different solution that doesn’t require modifying the source code. I recommend using his technique, as it’s cleaner and allows you to use a CDN copy of ExCanvas instead of maintaining your own copy.

Font replacement techniques

Like many other web professionals, I’m tired of the limited font set we have to work with. Gee, should I use Verdana on this site or Georgia? Maybe Arial? Meh. Bor-ing.

The merits and legal implications of CSS3’s proposed @font-face are being hotly debated, which means the proposal is going nowhere fast. Unfortunately, this also means we won’t have native browser support for a wider set of fonts anytime soon. In the meantime our sites (and e-learning courses) will continue to use the same old ho-hum fonts.

Are there any other options? The answer is yes, but none of them are perfect. The most common (and cross-browser) solution is to use what’s referred to as the image-replacement technique; the basic idea is to use a program like Photoshop to create an image containing your text in a nice font, then display the image instead of the original HTML text. Since this requires making a custom image for every line of text, it’s generally only used for headings. Chris Coyier wrote a nice article on the topic about a year ago, and rounded up the most popular techniques at the time.

Some enterprising developers have come up with alternative image replacement techniques that are quite impressive. The most popular (by far) is sIFR, a Flash-based solution that can replace any specified text on your page dynamically, using small SWF files. This solution doesn’t require custom images, is cross-browser, and is extremely flexible. Alas, it also requires JavaScript and Flash Player; if used for a lot of text on the screen, you wind up with a bunch of SWFs floating around, which definitely eats up CPU cycles and slows down older computers.

More recently, there have been interesting attempts at using SVG, canvas, and VML to draw fonts dynamically. One early implementation of this was typeface.js [link no longer available], which appeared to be a great idea but was difficult to use. More recently, Cufon has been getting a lot of buzz. I think it’s very nice and is easy to use, but it also has a few drawbacks, namely what happens if CSS is disabled in the browser:

cufon-screenshot

Image: Cufon in action, but with CSS disabled. Cufon-generated text is blue, the original text is black.

Any text generated by Cufon (and some similar scripts) is treated as an inline image — canvas elements are functional equivalents to images. The original text is hidden using CSS. If CSS is disabled, the original text shows up side-by-side with the generated text. This causes all sorts of problems.

Another drawback is selectability; Cufon and other canvas/VML-based systems have problems making text selectable in all browsers. To be fair, this is a problem with just about every image replacement technique except sIFR, which uses the power of the Flash Player plugin to get around the issue.

I’d like to be able to harness the creative possibilities of typography in my e-learning courses but really wish I didn’t have to jump through all these hoops to do it. Which system will I wind up using? Probably a combination of old-school static images created in Photoshop and sIFR. I feel that sIFR is the best option for my projects because of its greater accessibility and flexibility, but only when I know my target audience has Flash Player. I’m also very impressed by Cufon and hope they manage to take it to the next level to be on-par with sIFR.

Image-Free Progress Bar using MooTools and Canvas

As part of my ongoing experiments with <canvas>, I decided to convert an image-based progress bar to an image-free canvas-based system. I just finished whipping up a proof-of-concept; it uses MooTools to generate the canvas and CSS code. No images were harmed in the making of this progress bar.

More info later (time permitting)

Modal.js updated

Shortest post ever: Just wanted to mention my Modal.js class is still a work-in-progress. Today I made a few updates, most notably to some CSS handling and to the styling of the ‘close’ button (looks much more sophisticated now). Check it out.

Custom modal windows using canvas and MooTools

In my previous post Fun with canvas and MooTools: a Rectangle class, I explained that I wanted to make a modal window for a project at my workplace. I was interested in using MochaUI, but felt it was a bit heavy for my needs. I started playing with the canvas element (using excanvas.js for Internet Explorer support), and wound up making a useful Rectangle class that can quickly draw shapes in canvas using JavaScript.

Shortly afterward I built a simple modal window class named Modal using MooTools. This class combines a dynamic canvas drawing API (the Rectangle class) with dynamic DOM element generation to create on-demand modal windows using no external images. My goal was to make this about as easy to use as a normal JavaScript alert, prompt or confirm window.

I’ve been playing with it over the last week or so, and while it’s nowhere near perfect (esp. the ‘close’ button), I think it’s good enough for my project at work. I figured I’d post it here in case anyone wants to have a look. Feel free to use it if you like, but remember it comes as-is with no warranties! View Modal.js here.

Note: The code in Modal.js is subject to change!

I’m completely open to suggestions for code improvements (my code still feels ‘hacky’ to me), but I’m not really interested in adding new features at the moment. If you really want a full-featured, well-crafted window system, you should use Greg Houston’s MochaUI.

Modal Examples:

The default

The simplest way to invoke the window is:

var modal = new Modal({ title: "My title", html: "<p>My html code goes here</p>" });

Simple no-frills

You have the option of not using a window titlebar or ‘close’ button:

var html = "<p>This is a modal window without any title bar.</p>";

var modal = new Modal({
    html: html,
    width: 300,
    height: 200,
    edgeMargin: 1,
    windowRadius: 9,
    opacity: 0.80,
    colors: {
        modalBackground: "#CCC",
        windowBackground: "#999",
        contentBackground: "#EFEFEF"
   },
   showTitleBar: false
});

Public Methods

close() This closes the modal window. Once the window is closed, the elements are destroyed and garbage collected using MooTools’ element.destroy method.

var mymodal = new Modal({
    title: "My title",
    html: "<p><a href='#' onclick='return goAway()'>Close me</a></p>"
});

function goAway(){
    mymodal.close();
    return false;
}

Options

The options available in the Modal class are:

Text

  • title (String) Text content for titlebar. String format, loads into an h1 element.
  • html (String) Text content for the main window content. Loads into a div.
  • padding (Number, default is 12) Indicates how much padding the content div gets, in pixels.
  • font (String, default is “Verdana, Geneva”) Sets CSS style for the title and window content. Can be overridden by inline styles.
  • fontSize (String, default is “small”) Sets CSS style for the window content div. Can be overridden by inline styles.

Size/shape

  • width (Number, default is 350) Width of window before the drop shadow gets added, in pixels.
  • height (Number, default is 200) Width of window before the drop shadow gets added, in pixels.
  • shadowSize (Number, default is 6) Size of drop shadow, in pixels (note: not 100% pixel perfect measurements).
  • titlebarHeight (Number, default is 28) Size of titlebar, in pixels.
  • edgeMargin (Number, default is 1) Size of window chrome between shadow and content area, in pixels.
  • windowRadius (object OR number) Size of window corner radius, in pixels. If a number is specified, all four corners get the same radius. If an object is used, each corner gets the number specified (see below).
    • windowRadius.topLeft (Number, default is 9)
    • windowRadius.topRight (Number, default is 9)
    • windowRadius.bottomLeft (Number, default is 3)
    • windowRadius.bottomRight (Number, default is 3)

Behavior

  • animate (Boolean, default is true) Indicates whether or not to fade out the modal background when dismissing the window.
  • backgroundClickDismissesModal (Boolean, default is true) Indicates whether or not clicking the background will dismiss the modal window.
  • closeButton (Boolean, default is true) Indicates whether or not to include a close button. Only works when showTitleBar is also set to true.
  • showTitleBar (Boolean, default is true) Indicates whether or not the title bar should be rendered.

Colors

  • opacity (Number, default is 0.66) Indicates the opacity level of the background modal div. Number must be between 0 and 1.
  • colors (object) Child properties are used to specify colors for window elements. All color parameters accept standard CSS color conventions, including hex and RGB.
    • colors.modalBackground (Default is #000) Background modal div.
    • colors.windowBackground (Default is #AAA) Window chrome color.
    • colors.windowTitleBar (object) Used to create a gradient background for the window’s title bar. Accepts two properties: top and bottom.
      • colors.windowTitleBar.top (Default is “#F5F5F5”)
      • colors.windowTitleBar.bottom (Default is “#AAA”)
    • colors.contentBackground. (Default is “#F8F8F8”) Color of the canvas element behind the content div.
    • colors.closeButton (object) Used to create a the background and stroke for the closeButton.
      • colors.closeButton.fill (object) Used to create a gradient background for the closeButton.
        • colors.closeButton.fill.top (Default is “#F5F5F5”)
        • colors.closeButton.fill.bottom (Default is “#F36”)
      • colors.closeButton.stroke (object) Used to create a gradient stroke for the closeButton (does not work in Internet Explorer).
        • colors.closeButton.stroke.top (Default is “#FFF”)
        • colors.closeButton.stroke.bottom (Default is “#F00”)

Drawbacks

A system like this is bound to have drawbacks, and the biggest one is probably accessibility. Users with a screen reader or similar device may find the custom modal completely unusable. This is the same problem most RIAs face due to dynamically generated content. I’m considering implementing a check that uses a traditional JavaScript alert, prompt or confirm window in lieu of the custom modal if the user is using a screen reader. The check may or may not be based on whether WAI-ARIA mode is activated, but I have a long way to go before I’m ready for that! (Side note: To see WAI-ARIA in action, check out Google Reader.)

Another drawback is the mingling of my CSS with my JavaScript; in most cases I don’t like using JavaScript to set styles, except to set a classname. However, in this case I want the modal window to be as simple as possible and look nice out-of-the-box without requiring adding CSS files and all that jazz.

Lastly, I’d like to point out that the window doesn’t auto-size to fit the content. However, if the the HTML content doesn’t fit, the main content div will sprout scrollbars, ensuring you still have access to all of the content.

Anyway, this has been a fun experiment for me. It’s taught me a lot about what goes into creating feature-rich and flexible JavaScript widgets. I have nothing but respect for people who make JavaScript-based UI components like the folks behind MochaUI, Dojo, and YUI. It’s a TON of work.