Please forgive the Simpsons reference in the title, but let’s face it, browsers eat up an enormous amount of screen real estate with menu bars, super bars, status bars, toolbars, scrollbars. And that’s all before you get to the white space and toolbars and menus your own app requires.

Sure, you can press F11 today in pretty much every browser and achieve that end, but how many of us actually do that? If we’re the power users and we don’t do that, what hope do we have for our users?

The Full Screen API will make it easy to do automatically. Better still, pre-release versions of this API are already supported in Firefox 9 and Chrome 15 (though disabled by default in Firefox 9).

To get you started, the Mozilla Developer Network has released its own guide to the interface.

In brief, there are a few key requirements:

1. The calling object for requestFullScreen() must be a DOM node
2. The DOM node may not be the child or parent of a plugin
3. If the DOM node is an IFRAME (or is the parent or child of one), the IFRAME must have an allowfullscreen="true" attribute

So what does real-world code look like? Let’s take a look at Mozilla’s own example:

function toggleFullScreen() {
  if ((document.fullScreenElement && document.fullScreenElement !== null) ||    // alternative standard method
      (!document.mozFullScreen && !document.webkitIsFullScreen) {               // current working methods
    if (videoElement.requestFullScreen) {
      videoElement.requestFullScreen();
    } else if (elem.mozRequestFullScreen) {
      videoElement.mozRequestFullScreen();
    } else if (elem.webkitRequestFullScreen) {
      videoElement.webkitRequestFullScreen(Element.ALLOW_KEYBOARD_INPUT);
    }
  } else {
    if (document.cancelFullScreen) {
      document.cancelFullScreen();
    } else if (document.mozCancelFullScreen) {
      document.mozCancelFullScreen();
    } else if (document.webkitCancelFullScreen) {
      document.webkitCancelFullScreen();
    }
  }
}

As you can see, the naming conventions aren’t quite there yet. Further, neither Firefox nor Chrome quite apply the CSS expectations of the developing standard.

When the calls fire successfully, either fullscreenchange, mozfullscreenchange or webkitfullscreenchange events will fire. Likewise, when it fails, either fullscreenerror, mozfullscreenerror or webkitfullscreenerror events fire.

Note also that in Firefox 9, you cannot use a form in fullscreen mode; pressing any key inside of an input seems to take you out of Full Screen mode. The browser provides no instructions for exiting fullscreen mode, so you will need to provide them yourself.

Confusingly, the ALLOW_KEYBOARD_INPUT parameter in the webkitRequestFullScreen() call seems to block the keystroke handler in the MDN sample, though forms once again work. It also provides instructions for exiting Full Screen mode, though it neglects to mention that Esc will do it as well, instead referring to Command + Shift + F on my Mac.

Still, Firefox 10 is expected to support the API out of the box, so we can start to see the development of true browser application environments. The possibilities for kiosk environments are also exciting.

There are lots of grid libraries out there. Naturally, this means we need to reinvent the wheel. With HTML5, we have a fantastic new tool called the CANVAS tag which frees us from the limitations of CSS.

The canvas tag is beautifully documented and supported on most modern browsers. Further, aside from IE 6-8, the vast majority of the browsers support the element as it is defined, which means we don’t need wrapping libraries to deal with browser quirks.

Using all of these libraries as baselines, there are a few essential pieces of functionality:
We must be dimension agnostic. Whether our space is 480px or 2560px wide, it should work well
We must support any number of columns
We must support n-wide columns
We must support arbitrary gutter sizes
We must get results consistent with those other libraries

To that end, I present the grid() function. It returns an object with an array of offsets, as well as plenty of other information that facilitates writing still more content to the canvas (or advanced features like simulating sub-columns). It has no library dependencies, although it currently does not gracefully handle older browsers.

Basic usage is simple:

result = AB.grid(canvas, 16, 20);

This one line takes the canvas element specified in the first parameter and divides it into 16 columns separated by 20 pixel gutters. The function returns an object that looks like this:

{
   cols: 16,
   element: canvas#tutorial,
   gutter: 20,
   offsets: [0, 60, 120, ..., 900],
   width: 40
}

You can also pass arrays:

result = AB.grid(canvas, [1, 3, 1], 10);

This divides the element into a 20% panel on the left and right and 60% in the middle. Now our response looks like this:

{
   cols: 3,
   element: canvas#tutorial,
   gutter: 20,
   offsets: [0, 194, 756],
   width: 186
}

Let’s go changing the colors:

result = AB.grid(canvas, [1, 4], 10, { foreground: '#CCC', background: '#EEE' });

Need to pad the outer margins as well?

result = AB.grid(canvas, [1, 4], 10, { includeOuter: true });

Maybe we just want to simulate the arithmetic, without drawing anything?

result = AB.grid(canvas.width, [1, 4], 10);

This would also work:

result = AB.grid(canvas, [1, 4], 10, { overrideWidth: canvas.width });

Now you’re probably saying that this is all well and good, but why bother when we are already using a CSS layout library for the site in general? Aside from making it easier to construct graphs, we can also use this to generate perfectly sized images within the client.

The following three lines will create an image tag from a canvas and do it faster than the human eye can detect:

var img = document.createElement('img');
img.setAttribute('src', canvas.toDataURL());
document.getElementsByTagName('body')[0].appendChild(img);

You could almost as easily assign it as a background image (here I am finally employing jQuery):

$('body').css('background', 'url(' + canvas.toDataURL() + ')');

Note that you must wrap the image data in the strings url( and ) for this to work.

Check out the code on GitHub.

In some of my past projects, I’ve had a strong desire to know the pixel density of the display device. In traditional desktop environments, we could reasonably trust that an assumption of 72dpi would work well, but on mobile devices this is not the case. The iPhone 4 packs twice as many pixels in an inch as the 3GS and Android devices vary wildly, while it sometimes feels like you can visually distinguish the individual pixels on older Blackberry devices.

Meanwhile, you still need everything to fit as close to pixel-perfect as possible. On the server-side, this requires a massive database, like Tera-WURFL, but on the client-side, we can use a fast and simple script.

For the purposes of this post, I will use jQuery, but you can use the framework of your choice to achieve the same end.

var test = $('</div>');
 test.height("1 inch").width("1 inch");
 var yDensity = Math.round(test.height());
 var xDensity = Math.round(test.width());
 test.remove();

First, I create a DIV with some minimal level of content, since mobile browsers like to collapse (or even ignore!) empty DOM nodes to improve performance.

Then I set its dimensions. I tried setting the dimensions as part of the style, but curiously, Firefox chose to ignore it so I didn’t even bother testing this behavior in Safari.

Now I can use the height() and width() methods in jQuery, which return an integer representing the number of pixels. Note that I have to round this figure, because those listed pixel densities are sometimes approximate. You’ll definitely get a float if you use metric units, of course.

Finally, I remove the node, as we no longer require it. Note that we never attached it to the DOM, so we never influenced rendering of the actual page.

Do you really care if the user clicks an option inside of a SELECT? In most cases, it’s only a means to the end of getting the new value. So why is your change event handler sending data to the server and modifying the DOM? This leads to spaghetti code, violation of DRY and ever more expensive maintenance costs as your app’s interface evolves.

Thus was born Backbone, an extension of underscore, with default support for jQuery, and with a bit of editing, support for MooTools.

So let’s say you’re Amazon and you’re trying to find a way to comply with the legal requirements in some states that say affiliate sold items are subject to sales tax. This is complex and you probably only want to get the most relevant data as late in the process as possible. Backbone makes it surprisingly easy.

Bind to a change event on our data object:

var destination = new Backbone.Model();

_.extend(destination, {state: null});

var order = {
  subtotal: 100,
  tax: 0,
  total: 100
};

//underscore makes it easy to pseudo-subclass
_.extend(order, new Backbone.View());

destination.bind( "change", function() {
  //Pass null in the first parameter to save all model properties
  destination.save(null, {
    success: function(model, reps, xhr){
      //Apply the tax rate
      order.total = order.subtotal + order.subtotal * xhr.taxrate;

      //Update display. Note that this is a no-op by default and
      //you should define it as needed elsewhere.
      order.render();
    }
  } );
} );

Now for our event handler on the SELECT. Note that I’m using jQuery, but you could use any library (or none at all).

$("#state").change( function() {
  //Do whatever pre-processing is required
  var v = $(this).val();

  //This could be generalized very easily
  destination.set({
    state: v
  });
} );

Let me start by saying that I love jQuery. Most of the time, it makes it very easy to write sane code. Sometimes, however, it just feels weird.

For example, let’s say we need to insert a link at the beginning of a div. You might write something like:

$('#myDiv').prepend('<a href="http://my.host/path" title="This is a cool link!">Click here</a>');

-or-

$('<a href="http://my.host/path" title="This is a cool link!">Click here</a>').prependTo('#myDiv');

It seems fairly straightforward, but it’s a maintenance nightmare, because you now have raw HTML buried inside of your Javascript. If it’s complicated HTML that is being dynamically constructed, it’s all too easy to introduce hard to find browser parser errors.

MooTools, on the other hand, gives you a powerful alternative with its Element class.

To create a new DOM element you literally call a constructor and pass the tag name and attributes to it. So, for example, that same link would be built with:

var myLink = new Element('a', {
 href: "http://my.host/path",
 title: "This is a cool link!",
 text: "Click here"
});

At the price of a handful of few extra bytes, you get clear, legible code. The equivalent of .prepend() is thus:

$('#myDiv').grab(myLink, 'top');

While this might at first seem less intuitive, you can use the same method call to insert that link before or after the selected element. Sure, you could do that with .before() or .after() in jQuery, but imagine if you needed to make the insertion point variable!

There are also a slew of additional benefits, like ECMAScript 5 array methods, support for multiple inheritance, and event handlers that make it easy to detect if the user is pressing Alt while right clicking.

Give MooTools a try, but before you do, I strongly urge you to read Sean McArthur’s excellent post, A Better Way to use Elements, on the difference between $() and $$(). If you come from a background of using Prototype, it will seem perfectly natural, but jQuery users can be caught by surprise.

As a follow up to my last post, I thought I’d put out an instruction on actually creating a Google Chrome retreat.

Step 1: Add a Chrome Frame header to your site.

Add this to the head of the Chrome Frame dependent pages:

<meta http-equiv="X-UA-Compatible" content="chrome=1">.

If this isn’t practical, You can also configure your server to send an HTTP header of

X-UA-Compatible: chrome=1

I advise against this approach, however because server configs won’t be immediately available to other users on a site.  By its nature, a Chrome Frame retreat should be considered a reasonably unique event.  It’s good to clearly document this dependency for anyone else who may need to debug things later.  Once you’ve started to retreat, make sure you’re applying the header to every page of the site.  The two engines render things differently and you may create an inconsistent experience for your users if they are transitioning between Chrome Frame and Trident environments frequently.  In my experience, border-radius and drop shadow toggling on and off is a pretty strong “It’s Broken” signal for end users.

Step 2: Identify your Dependency Wall.

1. Identify the range of pages / screens in your web app that you can’t support in IE.
2. Identify the navigation routes to those pages.
3. Leverage the routes to find natural locations for gatekeepers.
   1. 1. Login Screens (the perfect location)
      2. Tutorial Screens (A natural context fit for users)
      3. An Advanced Mode (Similar to the “enriched mode” Microsoft uses for ActiveX requiring cloud apps).
   • If you’re lucky, this will be a screen somewhere beyond your conversion pipeline.
4. Create an interception event for IE users.  You can bake this into your app, but the easy way is with conditional comments.
   1. Identify the Dom Nodes in your layout that must be presented to the user for them to progress.
   2. <div id=’loginbox’>…</div>
   3. Create a conditional comment to hide the nodes and prompt the user to install Chrome Frame.
   1. Be careful of z-index.  The chrome install iframe doesn’t work well if IE is floating some other content node on top of the install button.
   2. UN-INSTALL chrome frame once you’ve tested your retreat perimeter.  This is a big deal for ongoing development as you won’t be testing in IE otherwise.
   3. Becareful about your conversion pipeline.  Your key selling points may be behind the perimeter, but the act of demanding Chrome Frame is a pretty severe barrier to forward movement.

<html>
<body> <div id='prompt'></div> <!--[if IE]>
<script type="text/javascript"
src="http://ajax.googleapis.com/ajax/libs/chrome-frame/1/CFInstall.min.js"></script>
<style>
#loginBox{
display:none;
}
</style>
<script>

window.attachEvent("onload", function() {
CFInstall.check({
mode: "inline",
}); });
</script> <![endif]-->
</body>
</html>

Other Lessons Learned

Here’s a few lessons learned from deploying this.

 

If you come from an OOP background you’re likely used to defining class variables like this:

class MyClass {
   var internalValue1;
   var internalValue2;
   function constructor() {  … }
}

The values which are to be stored in your object are simple, straightforward, likely to be typed, and the compiler will detect typos in the variable names. JavaScript, as a loosely types language which treats its objects more like collections than discrete objects, can’t really offer us those protections. Conversely, that also means that we have a great deal of flexibility.

In essence, we can dynamically subclass our objects, which you have to admit is a neat trick.

So, for jQuery.UI widgets, the variables stored within our widget are not defined until we assign them. The act of assignment defines the variable name, which can then be called upon at will.

Assignment is simply:

this._setData(‘variablename’, variablevalue);

Retrieval of this value is similarly straightforward:

this._getData(‘variablename’);

This does mean that the old problem of misnamed variables is alive and well. It also means that you need to be prepared to handle an undefined response to the _getData call.

Okay, so this doesn’t strictly have anything to do with any JavaScript library, but it’s a handy little snippet of code to keep in your arsenal.

val = Math.max(cMin, Math.min(val, cMax));

In one line of code, we’ve automatically constrained val between cMin and cMax. Note that if cMax and cMin are reversed (cMax is less than cMin) val will immediately be set to cMin (the higher of the values).

We can, of course, rectify this when cMin and cMax are assigned values by calling

cMin = Math.min(cMin, cMax);
cMax = Math.max(cmin, cMax);

This is simple – provided you understand that the reference the keyword this refers to changes depending on when it is called.

When called during initialization, this refers to the widget you’re initializing. When the event itself is triggered, this refers to the DOM node node and not the widget.

As such, we need to introduce a new variable during initialization which the jQuery.UI library calls self which is, of course, equal to the initialization this, not triggered this. (Those of you familiar with Object Oriented Programming and by-reference calls should have no issue with this concept).

<$.widget("ui.clicker", {
   _init: function() {
      self = this;
      this.element.click(function() {
         self.increment(self);
         self.render();
      });
      this.render();
   },
   increment: function(target) {
      target.value(target.value()-1);
      //The exact handling of target.value will be shown another day
   },
   render: function() {
      this.element.text(this.value());
   },
   value: function(val) {
      …
   }
});

You’ll note that we have to pass self to the increment method or the widget won’t actually be able to find itself, but the render method, which was called during initialization, is henceforth always able to correctly reference this (the widget)!

Can you think of some times you might want to disable the right click context menu? Or better still, insert your own behavior or application specific context menu?

This is a simple and useful trick:

element.bind('contextmenu',function(e){
    //Optional customized handling here
    return false;
});

If you don’t return false, the normal context menu will appear, which could actually be desirable, depending on what exactly you want it to do (say, exiting a field and recording it as dirty).