#zachleat {
  transition-property: employment;
  transition-delay: 1209600s; /* 14d */
}

If you’ve been living under a block-level element and aren’t familiar with Filament Group, I’m sure you’re familiar with a few of their contributions to the web development world. They’re well known for their advocacy and real world application of development practices that are important for the future of the web: Accessibility, Progressive Enhancement, and Responsive Design. They’ve literally written the book on Progressive Enhancement, and their recent redesign of the Boston Globe was one of the first major large scale implementations of Responsive Design. If that weren’t enough, they are also leading the development of the jQuery Mobile project.

Woooooo!

In all seriousness, I do still see new JavaScript developers that are unaware of the parseInt problem. I’m hoping this will raise awareness or failing that at least make some people smile.

The Mankini’s development predated the HTML5 specification but the end result was functionally similar. The difference being that in addition to operating on text inputs and textareas, it also worked with LF/CR and selects (injects an option with an empty value). The HTML5 specification requires that LF/CR be stripped from the placeholder value.

One of the most important design considerations our interaction design team specified for The Mankini was that it was not to be used as a replacement for a form label. It was a complement to the form label and nothing more. The HTML5 specification came to the same conclusion: “The placeholder attribute should not be used as an alternative to a label.” The reasoning is obvious: if the form field has a non-empty value, you need to be able to easily identify the value’s semantic meaning.

Instead of putting the label text into the placeholder, use the placeholder to supplement the labels with an example e-mail and URL to provide more of a hint to the user for proper formatting. This example isn’t a huge usability issue since the three fields’ values would be easily identifiable, but it’s important to keep in mind.

Placeholder Testing

I decided to run a few compatibility tests on the placeholder attribute to see where I could reuse the HTML5 placeholder inside of The Mankini (the test results are also available on GitHub). This yielded a few interesting things about some consistent and inconsistent cross-browser incompatibilities with the specification that I thought were worth sharing.

1. The HTML5 spec states that the placeholder should be visible when “element’s value is the empty string and/or the control is not focused.” The and/or presents the implementor with a decision. Do they keep the placeholder text visible when the field is focused but the value is still empty? Or do I remove the placeholder when focusing into an empty field?
   
   My personal preference is that the text remains until the user starts to type. Safari 5.1, iOS 5, and Chrome 17+ were the only browser implementations to agree with this as of time of writing.
2. The HTML5 spec has suggested (not required) that placeholders only apply to <input type="text, search, password, tel, url, email, number"> and <textarea>. For some input types such as hidden, radio, or checkbox this limitation makes sense, the placeholder would add nothing to these elements. But for others like datetime, date, month, week, time, datetime-local, color, or file the argument can be made that it would be useful.
3. There is an open WebKit issue to add placeholder support to contenteditable. Hopefully the specification gets modified and this gets added, as it would have been useful for my BigText Demo Wizard which manually implemented that same feature.
4. <input type="number"> support is broken in Safari and it’s already been reported and fixed. “The future is here, just not evenly distributed.”

As a side note, it should be said that both Opera and iOS both have comprehensively badass support of the new HTML5 form element types.

Overlooked Polyfill Considerations

• For those browsers that did implement the placeholder, it was well supported in password fields, showing as plaintext and then converting to masked input when the user started to enter data. This was a nice surprise, but polyfilling that behavior in old Internet Explorers will require additional lifting since dynamically changing the type attribute is not permitted.
• Placeholder text should not be included with form submit.
• Placeholder text should reinitialize on form reset (note: there is no delegate event for reset in jQuery)
• Performance. Is the component required to iterate over all elements and add a class to initialize each one individually? For best performance, use CSS attribute selectors (input[type="text"][placeholder]) for the default style and iterate only to remove the light gray color on form elements with non-empty values. This only requires a className modification for a much smaller set of elements, only the ones with non-empty values. Remember that the browsers we polyfill are often the slowest.
  
  Does the component modify the className property on focus and blur? I found this to be a huge performance issue for the Mankini in IE7 and IE8 on pages with large DOM trees and was a lot faster if the Mankini only modified one element’s style (think jQuery’s $(this).css('color', '#000')).
• Clear the values on page unload. After page refresh, some browsers will attempt to save unsubmitted form values and re-enter the values when the page reloads (added after reviewing Mathias Bynen’s jQuery-placeholder).

Bathwater, No Babies

HTML5 Please recommends that we use the new and shiny responsibly and gives the go-ahead to use the placeholder polyfill on our pages. I humbly disagree. This seems to be the same trap we fell into for rounded corners and box shadows. We put extra effort into trying to get our sites to render and behave identically cross-browser, when we should have just let them render in old browsers without rounded corners or box-shadows at all. To test whether or not a polyfill is necessary, I created a super complex decision workflow called The Polyfill Test. It consists of 2 steps:

1. Look at your own browser statistics. If the feature is at >50%, continue to Step 2.
2. Determine if the user be able to complete their task without the feature. If the task is still completable without significant impairment, the polyfill isn’t necessary.

Globally, placeholder support is sitting at 60% and growing. This particular feature has passed the tipping point. If your audience isn’t a representative sample of the global web browser statistics (big enterprise intranets with 97% Internet Explorer), your mileage may vary.

If you’re already using validation on the form fields (client and/or server side) and you’re correctly using the placeholder to supplement (not replace) the field labels, I would argue that the polyfill isn’t needed. It’s an implementation nice-to-have, not a requirement.

Update: Added note about Chrome 17+ support for placeholder text remaining on focus per Mathias’ feedback below.

Earlier this year I was given the opportunity to attend the jQuery Conference in San Francisco. I was delighted to go, able to finally meet some of the JavaScript greats I’d been stalking following online for years.

Looking back on the conference, the one presentation that had the biggest impact on the way that I code had to have been Dan Heberden‘s “Deferreds, Putting Laziness to Work.” (I would be remiss if I didn’t also mention inspiration from a recent presentation by Eli Perelman at the Omaha jQuery Meetup.)

At first, Deferred objects sound scary. I can assure you that they’re actually incredibly easy and incredibly useful. Today we’ll go through the simple task of reworking the Geolocation API to use jQuery Deferred objects.

Here is the standard Geolocation API to retrieve the user’s current position:

navigator.geolocation.getCurrentPosition(function(position) {
  // success
}, function(error) {
  // failure
}, {
  // options
  enableHighAccuracy: true
});

When the above API is called, a prompt is shown to the user asking if they want to divulge their location information to the domain of the currently active web site. Typically this prompt is a non-blocking asynchronous operation (although not explicitly defined in the specification).

Let’s go ahead and change it to use a jQuery Deferred object:

function getCurrentPositionDeferred(options) {
  var deferred = $.Deferred();
 
  navigator.geolocation.getCurrentPosition(deferred.resolve, deferred.reject, options);
 
  return deferred.promise();
};

Notice that the success callback is replaced by the deferred object’s resolve method and the error callback is replaced by the reject method. All of our function arguments are removed from the API. We’re left with one simple options argument.

This allows us to do things like:

getCurrentPositionDeferred({
  enableHighAccuracy: true
}).done(function() {
  // success
}).fail(function() {
  // failure
}).always(function() {
  // executes no matter what happens. I've used this to hide loading messages.
});
// You can add an arbitrary number of callbacks using done, fail, or always.

We could also use $.when to run code upon completion of two arbitrary and contrived operations like a Geolocation call and an Ajax request. Awesome.

To coordinate between multiple Deferred objects, use $.when:

$.when(getCurrentPositionDeferred(), $.ajax("/someUrl")).done(function() {
  // both the ajax call and the geolocation call have finished successfully.
});

I wonder what other browser native APIs could be better served by using Deferred objects instead of function arguments.

One Web, Two Web Primer

There are two different approaches one can take when developing a mobile web site. The first approach has been assigned the delightfully inclusive moniker ‘One Web‘. One Web involves creating a single web site accessible from both mobile and desktop web browsers and the site’s presentation is custom tailored at run time to the capabilities of the user’s device.

The second approach involves creating two completely separate web sites, one for mobile and one for the desktop. The advantage with this approach is that content and the user interface can be tailored specifically for mobile, as the user’s context while using each site is likely to be drastically different. An obvious nickname for this approach might be ‘Two Web’.

Two Web involves a white list of mobile User Agents that server side code uses to detect mobile devices and redirects them to a mobile specific site. The remaining User Agents are left to view the desktop version. An improvement to this approach allows end users to opt-out of the mobile version by simply clicking on a link that redirects to the desktop version and persists the setting (often using a cookie).

With One Web the site is customized and adapted based primarily on screen dimension, orientation, and pixel density. Contrast that to Two Web, which usually divides touch screen and non touch screen devices. While this may make it easier on developers, it’s awkward for users. For example, consider Google Plus on an iPad. The entire experience feels like it was intended for a small screen, and feels barren and feature-poor on the larger tablet screen. The full Google Plus web site would be better for the iPad.

Other downsides to Two Web include maintenance of two separate code bases, maintenance of the User Agent white list as new devices are released, and dependency on server side code to redirect mobile User Agents to the mobile site.

Developers should also be aware of the historical precedence of browser vendors borrowing User Agent strings from other devices as they become popular. That’s why almost all User Agents in existence today contain the string “Mozilla” and why WebKit User Agents contain “like Gecko.” Come to think of it, User Agent theft happens most often when the target is Netscape or Netscape progeny.

Make Your Choice

An informed reader might already be aware of the choice between One and Two Web. What you might not be aware of is that your mobile JavaScript libraries and toolkits may have already made this choice for you. The mobile web development space is clouded with tools that don’t document their requirement of Two Web.

Most of the tools that have been reviewed below have focused on WebKit support only. It is not the author’s desire to simply suggest that these tools should work on non-WebKit mobile browsers. The tools we use should not create a web divided between mobile and desktop. In a theoretical world where WebKit has a global monopoly on both mobile and desktop web browsing, it would still create problems if sites are restricted to mobile only or desktop only. Developers must be aware of the compromises we’ve inherited from our tools.

As of June 2011, mobile web browsing is only 6.5% of all web browsing, while 24.5% of all web browsing is desktop WebKit (non-mobile browsers like Chrome or Safari). While evidence would suggest that the share of mobile web browsing will increase, we should be very cautious to assume that WebKit (mobile or desktop) will ever reach anything close to 100% market share.

Let’s look at how a few sample pages render in a few desktop browsers. (Keep in mind that I did not test in the other major rendering engine, Presto currently used by Opera 11.5)

Sencha Touch 1.1.0

Trident (IE9) Not Supported	Gecko (Firefox 5) Not Supported

Instead of a nice list with large click targets, we’re greeted with a simple white screen. No error messages detailing a JavaScript error occurred on the page. No warning saying the web browser being used here isn’t supported (the bane of Progressive Enhancement advocates). Really bad user experience here.

Officially, Sencha Touch support is not “anything WebKit” as some have suggested. It officially supports Apple iOS 3+, Android 2.1+, and BlackBerry 6+ devices. It does not include WebOS, which is a WebKit browser, nor does it include any desktop web browsers.

DHTMLx Touch v.1.0 RC

Trident (IE9) Not Supported	Gecko (Firefox 5) Not Supported

DHTMLx Touch operated much better than Sencha Touch on desktop browsers. Despite the fact that many of the demos on their website are hidden behind QR codes. You can use a QR decoder to get the URLs for viewing on your desktop device. As for official web browser support, the DHTMLx Touch web site states:

While browsing the demos of DHTMLX Touch, note that the framework requires a mobile device to display and work correctly. You can also run the demos on standard PCs in Firefox 3.6 and above, and WebKit browsers (Safari, Chrome, etc.), but there still can be some issues since DHTMLX Touch is optimized for mobile devices.

Unfortunately, even though it works for the most part, desktop web browsers are still unsupported. It should also be noted that DHTMLx isn’t full WebKit either, as Blackberry 6 is not yet officially supported.

Dojo Mobile 0.2

Trident (IE9) Supported	Gecko (Firefox 5) Supported

Dojo Mobile also did fairly well. There were a few minor rendering issues with WebKit prefixed gradients (and no background color fallback) which I would consider to be very minor bugs. Here’s the good news from the Dojo documentation:

Dojox.mobile supports not only webkit-based mobile browsers, but also non-CSS3 desktop browsers such as IE and (older) Firefox.

jQuery Mobile 1.0b2

Trident (IE9) Supported	Gecko (Firefox 5) Supported

In most of the other frameworks, cross browser compatibility documentation felt like an afterthought mentioned in passing. Not jQuery Mobile. It has the most complete web browser support documentation of any mobile component framework. Not only is their documentation the best, their device support is the most comprehensive. The project officially supports Internet Explorer all the way back to version 7, which speaks volumes to their commitment to allow the developer to make the choice between One Web and Two Web.

Conclusion

If you’re developing Hybrid Native applications using software like PhoneGap, desktop web browser support doesn’t matter here. Feel free to disregard this entire article.

However, if you are developing for the web I would encourage you to look strongly at One Web as the default choice, and use Two Web as the exception when your content and context require drastically different non-adaptable versions of the site for mobile devices. Certainly I’m not suggesting that either One or Two Web are silver bullets. But we should all be aware of how the tools we choose weigh on our decision, and how this decision will affect our users in the future.

We at @paravelinc happily present to you FitText—a jQuery plugin for inflating web type: http://t.co/1NuQg5z

Naturally, I wondered how it compared to BigText, a plugin of my own creation to Make Text Big. Trent continued:

It’s in the GitHub readme, but I want to recognize BigText from @zachleat as another font sizer for non-fluid sites: http://t.co/dXw607P

I was delighted to get some attribution from Trent, and even more delighted to see their plugin. It’s really a great piece of work. However, his statement that BigText is just for non-fluid sites is not quite accurate. Let’s dive in.

On the surface, BigText and FitText might seem very similar. In fact, they are quite different and approach what might seem to be a similar problem (resizing text to fit a container) in very different ways.

At its simplest, we can boil it down like this: If you’re crafting a specific design with copy that is not going to change, use FitText. If your text is dynamic (maybe user generated), use BigText.

Here’s more detail:

FitText is very lightweight and fast, even considering it doesn’t yet use a debounced resize event. The FitText algorithm is quite beautiful. A huge well done to Paravel.

FitText relies on the fact that there is a linear relationship between font-sizes and element widths. Once you’ve established the ratio between the two, it’s off to the races. In fact, it would probably be technically possible to determine the ratio solely on the initial inner-width of the text and the initial font-size. I’ll have to play around with that approach but if it works it would give an amazing speed improvement to BigText.

In a perfect world, BigText and FitText could be combined, to create a mutant auto-text-sizing plugin baby that gives the best of both worlds.

A few weeks ago at the jQuery Conference (San Francisco 2011), Nicholas Zakas delivered a wildly entertaining presentation entitled “Progressive Enhancement 2.0″ (slides 65-79 are especially great), updating the basic rules of PE for a modern age. While prior Progressive Enhancement techniques included layering content, presentation, and behavior (conveniently represented as HTML, CSS, and JavaScript). PE 2.0 (not to be confused with our other 2nd generation friend, the Web) involves multiple layers of CSS for differing device capabilities (rounded corners for example) and multiple layers of JavaScript (ECMAScript 5 capable browsers, for example). He made the argument that this also included ignoring older browsers (in some cases) and only moving forward with new functionality for newer, more capable devices.

Like any web developer that believes in getting actual work done, I agree with his argument but not without exemption.

Pieces of Flair

The benefit of Progressive Enhancement pays off when your code encounters a device is incapable of interpreting the CSS or JavaScript correctly in a way the code was intended. This could be because of a bug in the rendering or JavaScript engine (or God-forbid an error in the code itself), or it could be because the feature being utilized is newer than the device itself and it could not have supported it without clairvoyance or a time machine.

The example Nicholas used to display this case was the Twitter home page, which uses CSS border-radius to display rounded corners. In user agents that don’t support border-radius, such as IE <9, the elements have sharp rectangular corners. Using Progressive Enhancement here is a no-brainer, especially for features (like rounded corners) that have no bearing on the actual meat of the page, the content.

But when the feature is the content and degradation requires additional work, the decision is more complex. HTML5 <video> and <audio> probably aren’t an acceptible baseline for progressive enhancement yet (based on current web browser statistics), and (video/audio) may never be an acceptable baseline depending on your views on universal accessible content. The best baseline might be a text-only transcript of the media. It really depends on how much importance the video/audio is to the core functionality of the page.

Input

Historically speaking, in order of mainstream application the progression of input devices used to interact with (even back before web) applications was: keyboard, mouse, touch, and (even more recently) speech (see the speech attribute on text inputs in Google Chrome). Logical progression concludes that we’ll see gesture APIs (think Microsoft Kinect) available at some point as well. It’s very important to consider that the the mechanism of input must also be carefully layered. Start with a good baseline of keyboard support for your application, then add mouse interactions, then layer any specific (multi-)touch interactions on top of that, and so on. You don’t want to skip any intermediate input layers.

In Nicholas’ presentation, he presented an example of the Yahoo! homepage, specifically modified for tablet devices (slide 115). He went on to describe that the carousel functionality on the main image on the page was not available when viewing the page in Firefox. I think this is a good example of what happens when you skip layers of input interactions, moving straight to touch, without first layering mouse-based input. The approach the Yahoo! team took might be okay if you can afford to develop multiple independent code bases for a single home page, but most teams are going to want to get as much out of a single code-base as they can.

Cutting Fat

A side benefit of targeting Progressive Enhancement to your core functionality allows you to easily add ancillary features that don’t need to span the entirety of your browser support spectrum. Some might argue that the Carousel functionality in the Yahoo! tablet example could be considered ancillary, but the positioning and screen real estate dedicated to it suggests otherwise. Facebook’s chat in IE6 is a good example of this (slide 114). Is chat part of the core functionality that Facebook wants to guarantee device independent access to? Apparently not. Making decisions in this realm involves a real cost benefit analysis, weighing the feature against user benefit, browser market share, and development/implementation time.

Exceptions

It’s important to note that not all things can be developed using Progressive Enhancement. There are certain use cases in which viewing the content in a lower fidelity than the author originally intended would destroy the value of content altogether. While these use cases are rare for most sites, most artistic endeavors can be classified as such. Consider The Wilderness Downtown, an amazing and beautiful interactive film built by Chris Milk using HTML5. The strong, vivid emotional connection between the film and the viewer would have been destroyed had the content been a text-based transcript, or just audio, or even just a video. Art must not be compromised.

Now, some of you probably read the above paragraph and are thinking to yourself that your blog also qualifies under the above exemption (you’re the guy that doesn’t have full text feeds on his RSS aren’t you?). Just be real with yourself, most things probably don’t fit into the same level of interactivity as The Wilderness Downtown. Don’t use art as an excuse.

Conclusion

Start with the primary goal of each individual page, this must be universally accessible. If the goal is to display text content, the text must be available sans-JavaScript. If the goal is to show a video or play audio, consider a transcript as your baseline. If the goal is to solicit form input from the end user, don’t skip input interaction layers. But don’t be afraid to shirk best practices on things that aren’t necessary to that goal, like social media links, a real-time chat client, trends/statistics, etc. You’ll know what matters.

Update: Changed the title of the article.
Update: Rather than My Yahoo!, Nicholas informed me that it was just the Yahoo! homepage.

(I appreciate the irony of sharing these slides using the flash plugin)

• Download the original PDF (exported from Keynote)
• Download the source code

If there’s demand, I do have a video of the talk. Let me know and I can do a bit more work to package the video and upload it.

When Raging Netflix Queue recognizes the site you’re browsing to be a movie web site, it will show a small green Netflix icon in the address bar. Clicking that icon will add the title to your queue. If the title is available for Instant Viewing, it will go into your Instant Queue. If not available for Instant View, it will go into your DVD Queue. If the title is still in theaters and not yet available on DVD, it will go into the Saved portion of your DVD Queue, and Netflix will automatically add it to your DVD Queue when it becomes available.

Raging Netflix Queue supports Rotten Tomatoes, IMDB, Google Movies, Apple Trailers, Movie Fone, movies.com, Yahoo Movies, and Fandango. Let me know if you have others you’d like to see added.

Download Raging Netflix Queue

Screencast

Hiccups

Years

The extension will parse the release year from the movie page, in order to guarantee better accuracy of results (There are a ton of remakes out there with the same titles). However, the actual year may vary. Some sites report theater release date, while others DVD release date, or the movie may have gone through a small showing and then a larger showing later. Thus, we allow plus or minus one year leverage when searching Netflix. See Cedar Rapids (2011) on Rotten Tomatoes.

Use of “The” or And/&

Apple’s entry for The Adjustment Bureau does not include “The” in the title. While this would be solved if Netflix allowed partial name matches in their OData API, Raging Netflix Queue does an additional search prepending “The” to the title, if no titles were found on the first go.

Netflix requires exact name matches in their API and prefers “and” over “&” in my tests. Raging Netflix Queue does a simple string replace there.

Single Quotes

Titles like “The King’s Speech” don’t match, due to another limitation with the Netflix OData API. There is no way to escape single quotes in the query string. I’m waiting on Netflix for an answer there.

Hindsight

It’s true that I have built a web browser plugin (to an add-on) before, and even a plug-in to a ported web browser add-on, but it was a great experience to build an actual web browser extension and Google Chrome has made it very easy to do so. This was also a jQuery-free project, as I would think that all Google Chrome extensions would be. jQuery is intended to solve cross browser compatibility issues, and a web browser specific extension shouldn’t have any of those. Sure, it feels like you’re being spoiled to use native String trim(), Array forEach, and document.querySelector. But damn it, I deserve nice things every once in awhile.

I’m getting such a huge queue right now.

He wins a copy of Christian Johansen‘s book, Test-Driven JavaScript Development.

If you code for a living, testing will make your life easier. Even though the contest is over, I encourage you to go through the steps and complete the original challenge, if for no other reason than to see how easy it is to get a simple testing environment set up with JsTestDriver.

Stay tuned for more coding challenges!

Related: An Update to The JavaScript Testing Challenge

Here’s Steve’s screencast (using, I assume, a mechanical keyboard?):

Please note that the following information may be common knowledge, as this behavior is as described in the pre-requisite Microsoft documentation on the subject. However, I feel this behavior to be unintuitive and requiring more explicit communication.

Library developers live in a much different world from full stack developers. If you’re supplying code that will be used by others, you’re faced with a different set of priorities. As such, the library I manage provides certain user agent sniffing conveniences, namely classes to replace CSS Hacks (similar to the approach used in HTML Boilerplate to provide ie6 through ie9 classes on the <html> tag) and JavaScript booleans (similar to jQuery.browser). Much like jQuery, these conveniences remain for backwards compatibility.

The purpose of this post is in fact not to convince you whether or not User Agent Sniffing is a good tradeoff for performance (even though, in some cases I believe it is), but instead to provide further evidence that using the User Agent alone is an unreliable method to determine the rendering engine of the web browser, and must be complemented with other approaches. If you’re going to sniff, you have to sniff harder.

X-UA-Compatible Breaks navigator.userAgent

Microsoft defines two terms to help communicate how new versions of Internet Explorer render a page: Browser Mode and Document Mode. Browser Modes are determined prior to any request made to the server (and cannot be changed by web developers). If the user triggers an IE7 Browser Mode using the Compatibility View Button, a new request is made to the server. Document Modes are determined in the page response.

Compatibility View Button Flow

1. User presses the Compatibility View button. This changes the Browser Mode.
2. Request sent (since the Browser Mode has changed, the User-Agent is also changed to MSIE 7.0)
3. Response from Server
4. Document Mode determined

X-UA-Compatible Flow

1. Internet Explorer uses the default Browser Mode (newest available in the browser)
2. Request sent (Browser Mode determines User-Agent to send, probably MSIE 8.0 or MSIE 9.0)
3. Response from Server. Content may include X-UA-Compatible <meta> tag and/or Response HTTP headers such as X-UA-Compatible).
4. Document Mode determined, using X-UA-Compatible and the DocType

If a X-UA-Compatible header is sent back in the Compatibility View flow, it will take precedence but obviously will not change the request User-Agent HTTP header.

It’s important to note that since the request has already gone before the Document Mode is determined, the Document Mode has no bearing on the request User-Agent HTTP header. While Microsoft probably could have changed navigator.userAgent to be different than the request User-Agent HTTP header, I feel they made the correct decision is keeping the same value. navigator.userAgent remains the same value as the request User-Agent HTTP header in IE8, but Microsoft changed this behavior in IE9. In IE9, navigator.userAgent represents the document mode, not the request User-Agent header.

The User Agent isn’t the only thing being determined. The prerequisite Microsoft documentation states that the Browser Mode determines the User Agent, Default Document Mode, and Conditional Comments. This is not accurate. The Document Mode determines which Conditional Comments execute, not the Browser Mode.

Also note that using IE’s Conditional Compilation feature to return the version of JScript will be the same, independent of Document Mode.

var ie = /*@cc_on @_jscript_version+@*/0;
// Always returns 5.8 in IE8, independent of Document Mode.

Example Code from Scott Jehl’s respond.js

Test Pages

Try the following tests in Internet Explorer 8+ to test for yourself.

• Stock Page
• Setting X-UA-Compatible IE=7 using a Meta Tag (or IE=EmulateIE7)
• Setting X-UA-Compatible IE=7 using an HTTP Header (or IE=EmulateIE7)

What Does This Mean?

If you use X-UA-Compatible to change the Document Mode/IE Trident rendering engine, any client side code relying on navigator.userAgent (such as jQuery.browser) or server side code relying on the User-Agent HTTP Header will be incorrect. Since we can’t rely on the User Agent, what can we use? Microsoft does provide a document.documentMode integer we could use, pretty easily. But, I think there is a better approach.

Consider a great piece of JavaScript written by James Padosley to find Internet Explorer version numbers using Conditional Comments. His code seemed to meld perfectly with the above realization that the Document Mode determines Conditional Comment execution. We can use this to fix jQuery.browser.

// Place this script after jQuery, but before any code that uses jQuery.browser
// Modified to only test for IE 6+, since jQuery only supports 6+
(function($)
{
    if(!$.browser.msie) {
        return;
    }
 
    var v = 5,
        div = document.createElement('div'),
        all = div.getElementsByTagName('i');
 
    while (
        div.innerHTML = '<!--[if gt IE ' + (++v) + ']><i></i><![endif]-->',
        all[0]
    );
 
    $.browser.version = v;
})(jQuery);

Now, of course, since we’re creating nodes there is a small performance penalty in using the above script over Regular Expressions and document.documentMode. I feel this to be worthwhile, given that I’ve been burned by Internet Explorer’s version number before. But next time, I reserve the right to choose performance over simplicity.

It all began with a simple web foray to Designing Monsters. Their simple, typographic design was beautiful. But why? Their combination of the beautiful League Gothic font, use of Lettering.JS, and some simple font scaling gave the page a wonderful consistent vertical alignment. Like the Million Dollar Homepage, I wanted to rebuild it — but I didn’t want to spend a lot of time manually adjusting font sizes. So I did what any programmer with the jQuery Golden Hammer would do, I turned my problem into a nail.

At it’s simplest, the BigText jQuery plugin takes a single element and sizes the text inside of its child <div>s to fit the width of the parent element. Gives the text that lovely vertical alignment.

<div id="bigtext" style="width: 300px">
    <div>The elusive</div>
    <div>BIGTEXT</div>
    <div>plugin exclusively</div>
    <div>captured on film</div>
</div>

$('#bigtext').bigtext();

See the above at JSFiddle.

Implementation Details

The plugin itself is more than just a simple font-size incrementer. I wasn’t happy with the performance of simply iterating through font sizes with a single fixed interval. I decided it would be better to test multiple decreasing intervals. For each line, it increments first by 16em until it detects a line break, backs off an interval then increments by 8em. It continues with 4em, 2em, 1em, 0.1em, until it finds the correct font-size to the nearest hundredth of an em. It’s noteworthy that Webkit does not respect font-sizes to the nearest hundredth, it’s precision is maxed out at tenths. This algorithm results in fewer tests in most cases, especially where the resulting font-size will be very large. Performance is always important. After font-size, it moves to word-spacing as a backup for extra precision, especially needed on Webkit.

The BigText Demo Wizard

Check out the Demo

This is where the magic happens.

• Editable text (contenteditable), and BigText will run on every keyup event to resize what you’re typing.
• Dynamic horizontal and vertical centering using Alex Russell’s Flex Box CSS classes (This is easy now, hooray!)
• 3D transforms (browser support checked using Modernizr, currently only available in Safari. Note: Chrome flattens to 2D space)
• Custom fonts are loaded using Google’s Font Loader JavaScript API
• Ben Alman’s Throttle Plugin
• The rest is mostly jQuery UI with the Aristo theme

Turns out, the BigText Demo Wizard makes for really easy Kinetic Typography screencasts (not amazing, but surely easy):

The above is simply the manual process of typing lyrics into the BigText Demo Wizard. You can easily make one of these too, with the help of the following keyboard shortcuts:

• CTRL + ALT + X: Set the text to a random 3D transform angle.
• CTRL + ALT + C: Toggles between white and black background.
• CTRL + ALT + R: Reset 3D to default state.
• CTRL + ALT + SPACE: Fade out current text, clears the text, sets a random 3D transform angle, ready to type!
• CTRL + ALT + ENTER: Same as CTRL + ALT + SPACE, but keeps the same 3D transform angle.

The fun part about the BigText Demo Wizard for me was that it almost turned into a non-musical instrument when I used it real-time to complement music. Feel free to cruise Pandora and type lyrics to the music until your wrists get sore. What can you make with it?

The BigText Demo Wizard was tested manually in Safari 5, Chrome 8, Opera 11, Firefox 3.6, and Internet Explorer 8. The BigText jQuery plugin has a full JsTestDriver suite, available on GitHub. Just run ./test.sh or test.bat

In The JavaScript Testing Challenge, I asked JavaScript developers of the world to change their heathen ways and embrace the future of automated testing for a healthier and brighter tomorrow.

However, due to seasonal timing or otherwise real life related reasons, the challenge was greeted with a worldwide chorus of universally blank stares. So, in the true spirit of Christmas, I’m removing the deadline and will award the grand prize to the developer with the first correct and complete PrimeFactors code kata screencast. That’s right, be the first to answer the challenge will win a copy of Test-Driven JavaScript Development by Christian Johansen (PDF or Print version, your choice).

If you have any questions or need help getting started, let me know! I’d be glad to help. Good luck!

Update: An Update to The JavaScript Testing Challenge

Think back to the last time you wrote new code from scratch. Not autogenerated Dreamweaver image hovers or a pasted script from Dynamic Drive, but pure unadulterated new code. What was your process? I’m betting it’s probably similar to: (1) code, (2) switch to a browser, (3) confirm desired behavior for the change you’ve made, and (4) repeat.

Comrades, let me assure you that there is a better way, and it starts with writing unit tests. As a Front End Engineer that’s been doing it bareback without tests since I started in 1997, let me assure you that adopting automated testing strategies is one of the single best changes I’ve made to my development cycle to make myself more productive. Enough fluff. Let’s get started!

Testing Environment Setup in 3 Steps

Prerequisite: Java on the classpath

1. Download the JavaScript-Code-Katas Source (ZIP) (or checkout the code from the Github Repository, if you have git available)
2. Extract and browse to it using your operating system’s command line.
3. Run (Windows)
   > JsTestDriver.bat Template

   Run (MacOS)
   $ ./JsTestDriver.sh Template
   This script will close Safari (be careful if you’re using Safari in other windows)

If a web browser popped up on your screen, congratulations! You have an automated testing environment set up and running. Easy, right?

Writing a Test

Now, let’s write our first test!

1. Open up templateTest.js in your favorite IDE.
2. Add the following:

   TemplateTest = TestCase('TemplateTest');
   TemplateTest.prototype.testSample = function()
   {
       assertTrue(true);
       assertFalse(false);
       assertEquals(true, true);
   };

3. Re-run the JsTestDriver shell script from Step #3 above.

Now you should see something like the following:

Total 1 tests (Passed: 1; Fails: 0; Errors: 0) (2.00 ms)
  Safari 533.18.5 Mac OS: Run 1 tests (Passed: 1; Fails: 0; Errors 0) (2.00 ms)

Notice how you didn’t have to touch any HTML boilerplate code or manually bring up a web browser? Productivity ensues! You’ve made it this far, are you brave enough to dive into a Code Kata?

Prime Factors Code Kata

Code Katas are just small programs used as practice. They’re a great way to introduce Test Driven Development and improve proficiency with your IDE.

The Prime Factors Code Kata requires a function that takes a single integer argument and returns an array of prime factors of that argument in ascending numerical order. For example, passing in 8 should return 2, 2, 2.

• Original Java version by Uncle Bob Martin (see original post).
• JavaScript implementation of the Prime Factors algorithm

I’ve recorded an unmodified single-take screencast of myself performing the kata below. I’m using the same source code I provided above, but with the JsTestDriver Eclipse plugin instead of using the command line to run the tests. The plugin is great for the screencast, because it very easily shows when the tests are failing or passing. You might also notice that it reruns the tests automatically every time I save.

JsTestDriver

If you want to learn more a about JsTestDriver, check out their Google Code page. “But I use QUnit!” you say. That’s fine, there is an adaptor for that. Using both tools together, you won’t need to launch each individual browser manually and trigger the tests to start. It will save you time.

Challenge

Testing will help you. It will improve your the quality of your code and your productivity. I challenge you to practice the JavaScript Prime Factors Code Kata in your own IDE with your own automated testing process. Send a link to me on Twitter (@zachleat) with an unmodified single-take screencast of you performing the kata (in JavaScript) by December 25, 2010 and the fastest kata screencast will win a copy of Test-Driven JavaScript Development by Christian Johansen (PDF or Print version, your choice*).

Screenr is a great tool for recording screencasts, if you need one.

Good luck!

Or, I Am Dynamically Loaded CSS (and So Can You!)

Dynamic resource loading is one of the keys to have a performance happy web application. There are generally three different criteria we must address when making a request: cross domain security policies, asynchronous/synchronous (will it block the host page while loading), and whether or not events are triggered when the request completes.

If the resource and host page are on the same domain, obviously XMLHttpRequest works the best. We can control whether or not the resource is loaded asynchronously or synchronously, and we know exactly when it gets done.

If the resource and host page are on different domains (increasingly more common with CDN’s), our options narrow. Loading the JavaScript is a solved problem, just use the onload event on the <script> tag and you’re good to go (onreadystatechange for IE). But CSS is more complicated.

Existing Solutions

In all of the library source code I evaluated, Internet Explorer didn’t cause any issues. It fires both the onload and onreadystatechange events for <link> nodes. Obviously this is ideal behavior, and IE got it right. But what about Firefox and Safari/Chrome?

YUI 2.8.1 and 3.1.1

Original Source

// FireFox does not support the onload event for link nodes, so there is
// no way to make the css requests synchronous. This means that the css 
// rules in multiple files could be applied out of order in this browser
// if a later request returns before an earlier one.  Safari too.
if ((ua.webkit || ua.gecko) && q.type === "css") {
    _next(id, url);
}

I wouldn’t be surprised if the commit log there was from Bon Jovi; that code is living on a prayer.

LazyLoad

Original Source

// Gecko and WebKit don't support the onload event on link nodes. In
// WebKit, we can poll for changes to document.styleSheets to figure out
// when stylesheets have loaded, but in Gecko we just have to finish
// after a brief delay and hope for the best.
if (ua.webkit) {
    p.urls[i] = node.href; // resolve relative URLs (or polling won't work)
    poll();
} else {
    setTimeout(_finish, 50 * len);
}

Better, closer, warmer. This includes a nice method for working with webkit browsers. The poll method compares document.styleSheets, since Webkit has the nice option of only appending to the styleSheets object when the styleSheet has successfully loaded.

So we have working solutions for IE and Safari/Chrome. The only unsolved piece of the puzzle here is Firefox.

This post from the same author as LazyLoad also describes another solution which involves modifying the source CSS and polling against it. But that’s not really ideal. Can we do better?

Solution

Here’s what I came up with (using jQuery for brevity, note that this solution only fixes Firefox, and does not incorporate the above already solved solutions):

var url = 'css.php',
    id = 'dynamicCss' + (new Date).getTime();
 
$('<style/>').attr({
    id: id,
    type: 'text/css'
}).html('@import url(' + url + ')').appendTo(document.getElementsByTagName('head')[0]);
 
function poll()
{
    try {
        var sheets = document.styleSheets;
        for(var j=0, k=sheets.length; j<k; j++) {
            if(sheets[j].ownerNode.id == id) {
                sheets[j].cssRules;
            }
        }
        // If you made it here, success!
        alert('success!');
    } catch(e) {
        // Keep polling
        window.setTimeout(poll, 50);
    }
}
 
window.setTimeout(poll, 50);

See this demo in action. (Firefox only)

Update: After much joy and celebration, I have discovered that an approach similar to the above was written by Oleg Slobodskoi in his xLazyLoader plugin for jQuery. It shouldn’t be surprising that two independent developers might reach the same solution, and is just more proof that software patents are stupid. :)

Update #2 Added note about HTML5 async property on script tags.

Feel free to fork/contribute at your leisure.
http://github.com/zachleat/ALARMd

If you’re new, you can check out ALARMd.com to see what I’m talking about.

As many of you may already know, my day job includes managing a large and complex enterprise jQuery-based user interface component library. It’s used by all new web applications at the company, which boasts over an IT department of approximately 1500 people and hundreds of web applications. Needless to say, I get a fair volume of interesting support tickets that come my way. A few weeks ago, I had the pleasure of receiving one such ticket.

The support ticket’s symptoms included a oft-heard complaint: poor performance. On the web, poor performance can be attributed to a great many things, but most often can be boiled down to a bottleneck in JavaScript code using the DOM API. This time, strangely enough, the culprit was something else entirely.

One of the first things I check when an application complains of poor performance is the total size of the document, or how many nodes it has. One of the best ways to ensure good performance is to keep your document small, especially on projects using heavy dynamic element selection and filtering (think jQuery, Mootools, Prototype, Dojo, or any code using a selector engine like Sizzle). Any JavaScript library emulating CSS selectors executing over a very large document is going to take quite a bit longer than querying a small document, especially when the user’s browser doesn’t support native querySelector or getElementsByClassName.

To get an idea of what the size of a large document is, I usually go to a site with some fairly advanced JavaScript and query their size.

// Returns the total number of nodes in the document
document.getElementsByTagName('*').length;
// note: this number will not include any child nodes inside of iframes.

Getting back to the support ticket in question. After querying the document, I quickly found that the page contained over 50000 nodes. Wow. So, we’ve caught a big one. You’re going to be telling your grandkids about this some day. But, now what?

I decided it would be beneficial to find out where and what all of those nodes were. After clicking around the live document in the Firebug’s HTML tab for awhile, looking at View Source, and Ajax requests in the Console, I successfully determined the culprit. This particular application was using Wicket, a popular Java library for web applications, which includes its own Ajax Logger component (similar to my favorite log4javascript; or something like the YUI Logger), used to keep track of an application’s Ajax calls and JavaScript page manipulations with an inline GUI embedded in the parent document. On one page load, this application’s Ajax logger component had created 40000 nodes of log content.

It’s important to realize that embedding unnecessary content of that magnitude on the page can be very detrimental to performance. JavaScript loggers should log to a new child window, rather than be embedded in the parent document. This way they won’t bloat the document, but still provide you with much needed logging information.

But, in the future, how might this type of problem be more easily diagnosed and prevented? Ideally, when confronted with large documents, we want to see where in the document the majority of those nodes are located. But there isn’t an easy way to see which portion of the document is using the largest number of nodes, especially if the culprit is deep into the document tree. We can go through the source code manually, but that isn’t very efficient.

So in the spirit of exploratory development to help troubleshoot real-world problems, I decided to make a Firebug Lite plugin. This would give me an easy cross-browser tool to diagnose my problem in a familiar interface. Load up Firebug Lite, load the DOM Sailbloat JavaScript file, and easily spot the HTML love handles.

Here’s what it looks like in action:

Go Forth

1. See the demo
2. Download the source
3. Fork the Sailbloat on GitHub

Note: there is currently an undiagnosed issue with the Sailbloat and it fails to load intermittently. If you know why, I’d be happy to put your name in the source code credits.

Date Pickers are helpful components that are useful for a couple of reasons:

1. They allow you to easily map an existing real-world mental model (the Calendar) to form input (a text field). This provides additional context beyond what the simple string value of a date represents: days of the week, Calendar month labels, leap year information.
2. They allow for more usable and actionable data restrictions and error feedback. Want the user to select a weekday? Just show them on the calendar which days are available.
3. Visual cue as to what the form field’s data format should be. If a calendar icon is next to the form field, it becomes very obvious what kind of data the user should put into the field.

Now, the last two reasons are all well and good, but carry no intrinsic incentive for the user to actually click on and use the Date Picker component. The first reason is what actually motivates a user to bring up the Date Picker and select a date on it.

Now, consider the following Time Picker component, popularized by a John Resig blog post:

Comparing to the Date Picker component above, one could easily make the argument that it offers little to no incentive over simple keyboard input. It offers no additional context, extra data, or an existing physical mental model for the user to associate with. The only advantage it might offer is an easy calculator for those unfamiliar with 24-hour (military) time. I would argue that placing the AM/PM selection at the beginning of the selection creates a reversal of the closest established mental model a person typically uses to represent a time: the digital clock (hours, minutes, seconds, and AM/PM at the end).

These implementation examples speak to a larger trend of front end engineers that concentrate too much on code optimization and cross browser compatibility, and not enough on usability and user driven design. It’s an easy trap to fall prey to, but one we must be wary of. A Time Picker might offer benefit in terms of data restriction (e.g.: select an hour in the range of a normal workday), but it does very little for the efficiency and usability of data entry. So, before you start putting Time Pickers on all of your forms, make sure the Time Picker you add represents something like this:

and not this:

Image Sources:
1. tesora.com.au
2. codeproject.com

When you see issues with Character Encoding, it’s traditionally in the form of text on your page that looks like this: in Firefox or in IE.

Usually, those characters mean that the character encoding used on the page is either ambiguous (not specified), or incorrect. We can use Firefox to determine that Character Encoding of a web page (Right Click and go to View Page Info; or use the “Character Encoding” entry in the View menu). Check to make sure that the encoding reported by Firefox is the same encoding used in your IDE. For example, Eclipse 3.5 has a “Set Encoding” option in the Edit menu.

The reason most English alphabetic and numeric characters are consistent independent of character encoding is due to consistency in the lower characters in each encoding. The characters making up the ASCII character set (0-127) are the same as the lowest 128 characters of ISO-8859-1, UTF-8, and others.

Managing your character encodings gets trickier as you add more architectural layers to your application. For example, character encodings may differ in your database, the properties files used to configure your application (java.util.Properties uses ISO-8859-1 by default), or maybe the XML or JSON file you’re loading from an external API.

Ever heard of HTML character entities? That’s the primary reason they exist — as a sort of encoding independent reference to a particular character. So, for example, the Œ character does not exist in the ISO-8859-1 character set. To display this character in a document with ISO-8859-1 encoding, use the equivalent HTML character entity: Œ. For an easier reference, check out this full table of HTML character entities. If using ISO-8859-1 for your HTML document, any entity above Unicode index 255 will need to be escaped. If you’re using UTF-8 encoding, HTML character entities shouldn’t be required.

Setting the Character Encoding

To specify the character encoding for any file, you can set a Content-Type header by configuring your web server or application. Apache lets you easily set different default character encodings for each individual file extension (.js for example). Using the Content-Type header is the most full proof and efficient ¹ method to serve content.

But without access to the Apache configuration, how do we specify the character encoding?

For external JavaScript Files

In the HTML File

Just add the charset attribute. If not specified, the HTML document’s character encoding is used by default (specified in the Content-Type header or the appropriate meta tag, for example: <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>).

<script type="text/javascript" src="script.js" charset="utf-8"></script>

In the JavaScript File

To my knowledge, there is no way for a JavaScript file to report its own character encoding. To me, this seems like an omission. Each individual document should be able to report its own character encoding without a header. CSS files can do it (@charset at-rule). HTML files can do it (<meta> tag). Why not JavaScript files?

For Dynamically Created Script Tags

var s = document.createElement('script');
s.src = 'script.js';
s.type = 'text/javascript';
s.charset = 'utf-8';

If you’re using jQuery’s Ajax functions to load external JavaScript files, perhaps you might be inclined to use the script dataType. jQuery even provides a scriptCharset option for wrapping the above method for changing the charset on a dynamic script tag. Be warned, the jQuery Ajax function uses two different methods to load external script files (as of version 1.4.2). If a same-domain request, it uses an XMLHttpRequest. If a cross-domain request, it uses a dynamic script tag. So the scriptCharset jQuery option only applies to cross-domain requests. We’ll need some other method to mitigate our character encoding issues (or just use dynamic script tags).

For XMLHttpRequest Objects

Our saving grace would be the overrideMimeType method, if it weren’t poetically unavailable in Internet Explorer. Using this method, we can override the mime type and character encoding.

var xhr = new XMLHttpRequest();
// Not available in Internet Explorer (up to version 8 at time of writing)
if (xhr.overrideMimeType) {
    xhr.overrideMimeType('application/x-javascript; charset=utf-8');
}

Portable non-ASCII JavaScript

The best way to make non-ASCII characters in JavaScript files portable is to escape the characters properly. If the character is destined for HTML, use an HTML character entity (if available, not all Unicode or ISO-8559-1 characters have entities). Or, escape the characters using the proper Latin or Unicode escape sequence.

// Raw characters
var string = "ñó";

// HTML character entities
var string = "ñó";

// Escaped to Latin
var string = "\xf1\xf3";

// Escaped to Unicode
var string = "\u00f1\u00f3";

If you use the Google Closure Compiler, you’ll get the Unicode escape sequences for free (see issues 24 and 68). Make sure to read the tickets for more benefits of serving your JavaScript files using Unicode escape sequences to output only ASCII characters.

Summary

The easiest way to preemptively solve a lot of character encoding issues is to use UTF-8 for everything, and configure your web server/application to serve the UTF-8 Content-Type header. If you’re writing JavaScript code that you’re going to distribute to the masses, convert any non-ASCII characters using the proper escape sequences. Your JavaScript will be more portable, and will work out of the box on more server configurations.

Sources

1. Performance Implications of Charset, an article by Kyle Scholz

// Create a medium size array, at least 100 items
var obj = [];
for(var j=0, k=150; j<k; j++) {
    // the value here doesn't matter.
    obj.push('ABCD'+j);
}
 
// Sort the array alphabetically.
obj.sort(function(m,p){
    m=(''+m).toLowerCase();
    p=(''+p).toLowerCase();
 
    if(m > p) return 1;
    if(m < p) return -1;
    return 0;
});

The obj Array should now be sorted, in alphabetical order based on value. BUT, in our best friend Internet Explorer, a Number Expected error may be the result. Don’t be fooled if your test array behaves correctly, it only happens intermittently for arrays of varying size!

So, I whipped up a quick test to check the damage. Iterating over array sizes from 1 to 150, running the Array sort algorithm. The following failures resulted:

* Failures may vary to the specifications of the test machine.

Of course, the Number Expected error is going to result whenever your code doesn’t return a number inside of the function callback. But the problem here is something deeper than simple application code failure. The problem is in JScript itself. Any modification to the sort arguments may result in the Number Expected error.

    m=(''+m).toLowerCase(); // modifies the argument m and is unreliable.

This problem will manifest itself more frequently if you use the Google Closure Compiler, which restructures JavaScript to reuse argument variables if possible, probably to save the 4 character penalty of a “var ” declaration.

Normally, reusing argument variables is a safe practice for primitives, since they are passed by value and not by reference, as is the case in this Array sort example ¹. So, what exactly is going on here? One commenter at the Google Closure Compiler bug seems to think that the actual array values are being passed by reference instead of by value. I’m not completely convinced that’s the case.

The Fix

Don’t reuse the argument variables inside of an Array sort function.

// Changing the above example
obj.sort(function(m1,p1){
    var m=(''+m1).toLowerCase(),
        p=(''+p1).toLowerCase();
 
    if(m > p) return 1;
    if(m < p) return -1;
    return 0;
});

Check the source code of the demo file to see the different methods of modifying the arguments that I attempted.

1. If you want to learn more about passing by value or reference, Jonathan Snook has a nice explanation.

Internet Explorer can’t make you do anything, it can only make you wish you hadn’t.

Updated: Added note about Internet Explorer 9 and its Compatibility View. Looks like it’s fixed!