Zach Leatherman

Performance and Responsive Web Design

2013-05-17T00:00:00-05:00

The presentation was originally given to NebraskaJS in November of 2012. Unfortunately due to my own technical ineptitude with screen recording software I wasn’t able to publish the talk. So when I was asked to present on the topic again at the Omaha Mobile Group, I thought it would be a good opportunity to update the talk and get a second chance at recording it in front of an audience.

Video

View the Slide Deck (April 2013)

Or, view the original Slide Deck (November 2012).

Content

0:00 Title and Personal Background
3:04 Responsive Web Design Primer
5:24 The Web has Responsive Roots
6:24 Alternatives to RWD
- Do nothing
- Create separate mdot site
14:44 Common RWD Performance Problems
- 16:03 Blocking JavaScript
- 18:27 Blocking CSS
- 30:07 Images
  - 31:11 Manipulating Images with CSS
  - 36:47 Responsive Images (in HTML)
RWD Buzzkills
- 45:40 Advertising
- 46:47 Social Networking Widgets
50:23 RWD Showcase Showdown
54:21 Conclusion
Questions (Some really great discussion here)
- 56:19 How do Data URIs impact the critical path?
- 57:43 The difference between Responsive and Adaptive?
- 58:18 Do you have to start from scratch with RWD?
- 59:39 How would Jimmy Wales and Wikipedia implement RWD?

(Side note: I wish there was an equivalent to TimeJump for YouTube embeds)

Reactions, Reviews

Performance & Responsive Web Design speakerdeck.com/nebraskajs/per… great presentation from @zachleat
— Brad Frost (@brad_frost) November 17, 2012

People of Omaha! You _want_ to hear @zachleat talk about responsive design and performance. Trust me. meetup.com/Omaha-Mobile-G…
— Responsive Design (@RWD) March 29, 2013

The best RWD deck I've seen in a long time. The optimization section is a must read - speakerdeck.com/nebraskajs/per… by @nebraskajs
— Eric Snowden (@ericsnowden) March 6, 2013

zachleat.com is Dead, Long Live zachleat.com

2013-05-05T00:00:00-05:00

If you’re reading this in the RSS Feed, please accept my humble apologies for not transparently converting my feed. This is one of the perils of switching from WordPress to Jekyll. The URL for the feed has not changed, but you’ll probably see a lot of unread items appearing here, so feel free to “mark all as read.”

Welcome to the redesign of zachleat.com! Notably, the title of the blog is now my name, instead of Web 3.0, 6 Bladed Razors, 7 Minute Abs. I’ve decided that using my name for the blog title is more in line with the principles I set forth in A Web Developer Fumbling with Social Media.

Tools

The entire site’s source code is available on GitHub. If you see any issues with the site, please file them on GitHub. I probably could be convinced to rip out the proprietary pieces and release it as a blog boilerplate project—let me know if this is something you’d be interested in using.

Grunt and Jekyll work beautifully together, even though they’re written in two different languages. It’s especially convenient that grunt watch is configured to run the appropriate jekyll commands to generate the site automatically.

That being said, if anyone knows of a really good Node.js site generator, please let me know. I’ve tried a bunch of them and haven’t yet found anything as good as Jekyll.

Theme

It’s a simple minimalistic mobile-first responsive web design (that’s a mouthful, eh?) theme that I’ve built from scratch. I’m calling it Butt Sweater, for obvious reasons. Okay, not really. Well actually I mean to say, the reasons are not obvious—it’s really called Butt Sweater.

Removals

Wordpress: It was good to me for many years, but I am not sad to see Wordpress go and will look forward to blogging using Markdown in my normal code editor.
jQuery: I love it, but do not make use of enough JavaScript on the site to warrant it—yet.

Future Plans

Add SocialCount, which will mean either re-adding jQuery or removing the jQuery dependency from SocialCount.
I want to use the Google Analytics data to generate a visualization for the site that will communicate post popularity. I want it to be easy for visitors to find my most popular posts on the big list of posts on the home page.
~~Import the old Comments. This is still in the works. Whether or not I re-add the ability to let users post new comments directly on the site is still a matter for debate.~~

For now, let me know what you think on twitter.

Tool or Die, a Web Developer’s Workflow

2013-03-17T00:00:00-05:00

This is a talk I gave at Nebraska Code Camp 2013.

“Tool and die makers are a class of machinists who work primarily in toolroom environments—…often in an environment with flexible, semipermeable boundaries from production work.”

These are the people that make the tools to make the products. This was the environment I grew up in—watching my father work as a tool and die maker. He could make anything! But more importantly, he knew the value of good tools—even if you had to construct them yourself.

Tools are important and tooling for Web Development is improving! I’ll go through a few of my favorites: Node.js, grunt.js, npm, yepnope, SASS, grunticon, Browser devtools, Testing tools, and others.

Watch on YouTube

View the Slides

Fork the Slides on GitHub

But You Don’t Have to Take My Word For It

Cory House was quick off the blocks with a review of all the talks he attended:

Zach laid out his presentation in a unique way, relying totally on hand-made lean HTML markup that slowly blossomed as he walked us through topics. I really enjoyed this iterative and novel approach – it was the perfect choice for such a markup heavy session.

A Web Developer Fumbling with Social Media

2013-01-26T00:00:00-06:00

As a curious web developer that’s moderately obsessed with statistics, I decided to go back and look at my history of side projects, blog posts, and other junk I’ve posted on twitter to see what has had the biggest impact on my ‘social reach.’ Yeah, I know. It felt wrong typing ‘social reach’—I’ll put a dollar in the jar. I’ll probably owe a few of those before this post is done.

It’s a common sentiment that as developers we should focus on making cool stuff and the rest will solve itself. While that has been my general plan for my career and side projects, in hindsight I don’t believe that to be the complete truth. I think developers should spend time on self marketing—larger professional networks (not just social networks) lead to more opportunities.

So as a blind squirrel, I come to you with the nuts I’ve found: seven events that have bumped my network size and what I’ve learned from studying them. Note that Facebook is not mentioned here. I don’t use Facebook for career development.

Share and Be Shared

Out of those seven events, three were the direct result of Mr. Paul Irish. While I have no idea what I did to get in Paul’s good graces—I appreciate his concerted effort to share RSS feeds (Event 1), people to follow on Twitter (Event 2), and Google circles (Event 3). Paul increases the number of people consuming web development content which leads to more well informed developers. A rising tide lifts all boats. This is something we can all do. Look for some similar posts from me soon.

Silos are Lonely

Trailblazing can lead to isolation. Solve problems collaboratively or competitively—don’t solve your own problems alone.

After BigText came out, I was getting 2 RSS subscribers per day. Four months later when Paravel released FitText (Event #4) and linked to BigText that number jumped to 6. Even though the two plugins were competitors, we were both trying to solve a similar problem and our growth became intertwined.

Concentrate on the Right Network

It’s a lot easier to get an RSS subscriber or get circled on Google than it is to get someone to follow you on Twitter. It would seem that Twitter users curate their Twitter friends very closely since it’s one big unconfigurable stream (don’t get me started about how useless lists are). RSS and Google both let you self-organize your incoming posts in such a way that makes it easier to ignore content without unsubscribing.

If I had to choose, I’d take a Twitter follower over an RSS feed subscriber over a Google follower. But it ain’t a zero sum game.

Average RSS feed subscribers per day (2.4 years): 4.1
Average Google followers per day (1.1 years): 2.03
Average Twitter followers per day (4.3 years): 1.09

Name-drop Yourself

Plaster your name on everything you do. Link to your Twitter account and RSS feeds.

I’ve screwed the pooch on this quite often—most notably on SocialCount and BigText especially. I’ve had people say to me: “Oh—SocialCount? You built that?” Obviously not ideal. Personally, I felt that both of those plugins were higher quality than parseIntimate (Event #5), but parseIntimate had my twitter handle right on the front which bumped my followers more than SocialCount or BigText (prior to FitText).

Align Career with Community

Despite my ghost town of a profile on Google , my circled count jumped when I joined Filament Group (Event #6). Of course, working for a company that is so heavily invested in the community and open source is great.

Give Talks and Encouragement

For the Front End Engineering Manifesto (Event #7) I followed my own advice and put my twitter handle on both the top and bottom of the presentation and added SocialCount widgets for easy sharing. However, F2EM almost didn’t see the light of day.

If Ryan Versaw hadn’t personally encouraged me to present a topic at Nebraska Code Camp, I wouldn’t have created the presentation.
After giving the talk I sat on the content because I felt it was a little too preachy and dogmatic and was nervous about publicizing it. About 17 months later, Todd Parker stumbled onto it and encouraged me to release it.

Sometimes you just need a little push and I was lucky to get it from those guys. And at the end I’m very glad I posted it—F2EM was one of my most successful projects.

While I haven’t dipped my toe into the professional speaking circuit, I should thank Rey Bango for encouraging me to submit a talk to the jQuery Conference awhile back. I’ll dive in some day Rey!

I’ll keep my eyes open for someone that I can give a little push to and I encourage you to do the same. If you need my help or advice, I’d be glad to do what I can to help. Hit me up on Twitter or on Google Plus.

Full data available on Google Spreadsheets. RSS subscriber data provided by Feedburner (even though my first post was in 2007, I switched from naked RSS in 2010). Twitter data was provided by TwitterCounter and Google data by Social Statistics.

SocialCount, Faster & Lighter Social Networking Widgets

2012-11-27T00:00:00-06:00

I’m excited to let you guys know that my first Filament Group open source project was released. I made the move to Filament to both allow more client/open-source crossover work and to collaborate with some great Front End Engineers. SocialCount is the first public evidence of that goal.

SocialCount is a small jQuery plugin for progressively enhanced, lazy loaded, mobile friendly social networking widgets.

Third party JavaScript is one of the biggest challenges we face in our quest for high performance web sites and hopefully SocialCount will help tame the slothful beast.

Astute readers may recognize SocialCount from the implementation on A Front End Engineer’s Manifesto (page 2 and the footer).

Filament Group Lab Post

Contribute on GitHub

A Front End Engineer’s Manifesto

2012-09-02T00:00:00-05:00

Early last year at Nebraska Code Camp 2011, I gave a talk to a bunch of .NET developers about my own personal perspective on the world of Front End Engineering.

True to form, I developed the slide deck for the web using BigText, sausage.js, and a few other self-developed but yet-to-be released plugins. I uploaded it world wide for my presentation but never published the URL publicly. Unexpectedly, last week a developer from France found it and shared it on Twitter. Well, the cat is out of the bag.

I’ve been reluctant to share the slides because I certainly don’t want developers to take them as dogmatic truth. Rather, I’d love for people to see a forest using trees they’ve planted themselves. Try to take a step back and see the big picture when you’re problem solving on the front end and figure out what’s important to you.

So with a bit of trepidation but without further adieu:

f2em.com, A Front End Engineer’s Manifesto

If you’d like to see this talk live, let me know in the comments.

The site is also available on GitHub.

Talk Description

In the fast paced world of Front End Engineering, change reigns supreme. Dormant for years, the Browser Wars are back and have broken web development wide open. Led by competing vendors championing their own implementations of HTML5, CSS3, and other Web Standards, they’re unchaining us from the desktop computing environment. We’re seeing web browsers in our favorite Mobile Phones, E-Book Readers, and Tablet devices. Does your web site work with the Android Browser? On the iPad? How about the Kindle browser? IE9? Do you even know what version Google Chrome is on?

As web programmers, how do we keep up with this blistering, nauseating pace while still taking time to improve our skills? I’ll go through a set of principles and guidelines I use to simplify the world of Front End Engineering. These criteria will help you write better future-compatible flux-resistant code. They will help you evaluate new toolsets, APIs, frameworks, and even file formats and codecs. They will improve the quality of your web sites and applications.

Many thanks to Nate Koechley, who influenced some of this manifesto with his talk on Professional Front End Engineering, and to the countless other developers and designers who have made equally important community contributions.

CSS3 Job Transition

2012-05-16T00:00:00-05:00

I’m extremely excited to announce that I have accepted a full time position with Filament Group. I will be working alongside web developer titans of industry Todd Parker, Scott Jehl, Mat ‘Wilto’ Marquis, Patty Toland, and Maggie Costello Wachs.

#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!

Let’s get parseIntimate.

2012-02-13T00:00:00-06:00

This Valentine’s Day, spend a little quality time with JavaScript. Don’t be afraid to get parseIntimate.

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.

Placeholder Title for Article about HTML5 Placeholders

2012-02-05T00:00:00-06:00

When I’m not out fighting crime, I spend my days developing reusable components for the web. One of those reusable components I wrote was an implementation of a placeholder plugin. For the sake of privacy, all component names have been anonymized so I’ll refer to this home-grown implementation as The Mankini (if for no other reason than to drive some swimwear shopping traffic to my blog).

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.

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%2B were the only browser implementations to agree with this as of time of writing.
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.
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.
<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:

Look at your own browser statistics. If the feature is at >50%, continue to Step 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.

Deferreds and a Better Geolocation API

2011-11-07T00:00:00-06:00

Warning, this article is intended for Deferred unbelievers to convince them that Deferred objects are both easy and useful. If you’re already a Deferred object expert, you might want to skip this one.

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.

A Mobile Web Divided

2011-08-08T00:00:00-05:00

Unless you’ve been living comfortably under an elaborate dwelling constructed entirely out of rock, you’re aware of the growing popularity of smartphones and other mobile devices. With that growth we’ve witnessed a bumper crop of component libraries and frameworks to enable us to create mobile web sites and applications.

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.

FitText + BigText: A Tale of Two Plugins

2011-05-12T00:00:00-05:00

Earlier this week, @TrentWalton tweeted:

We at @paravelinc happily present to you FitText—a jQuery plugin for inflating web type:

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:

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:

	BigText	FitText
Demos	BigText Fiddle	FitText Fiddle
	Try resizing the demo windows above.
Algorithm	Sizes text automatically from a base up to fit the element width, regardless of initial font size.	Uses the width of the element and a configurable JavaScript argument (the ratio) to scale text down to smaller widths. This ratio argument must be set manually.
Responsive Design	Both plugins work with responsive design techniques, operating correctly with media queries, fluid designs, and window resizing.
Speed	Fast	Faster
Text	Works with user generated text, or any text isn’t cemented at design time. See the BigText Demo Wizard.	Requires up front configuration to specific text.
Resize Event	Works with existing debounced resize libraries, if they exist on the page.	Does not use a debounced resize event.
Unobtrusive	CSS and BigText font-sizes are independent of each other.	FitText uses your CSS font-size as a maximum font size.
	Don’t forget to set sane CSS font-size defaults when JavaScript isn’t available.
Unit Tested	Full Test Suite	-

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.

font-size = outer-width / configurable-ratio

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.

Pragmatic Progressive Enhancement

2011-05-09T00:00:00-05:00

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.

HTML5 vs. Native Applications, The Presentation

2011-03-05T00:00:00-06:00

This slide deck was prepared for my guest lecture at the University of Nebraska-Omaha’s spring course on Mobile Application Development (BSAD 8916-005). The course was developed in partnership with Google’s University Relations program and included a variety of business and management students with limited programming experience. My lecture was approximately six weeks into the course, and the students had already developed a few simple Android applications. My task was to convince them that HTML5 and Web Development is a viable alternative to native application development, for most use cases.

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

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.

Raging Netflix Queue, a Google Chrome Extension

2011-02-21T00:00:00-06:00

The premise is simple. When attempting to find movies to watch in my local theater, I often stumble upon titles that I feel to be more rental quality than theater quality. So I wanted an easier way to add those movies to my Netflix queue. I created a Google Chrome extension to accomplish just that.

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.

The JavaScript Testing Challenge Winner

2011-02-14T00:00:00-06:00

Congratulations to Steve Love, who was the first to complete The JavaScript Testing Challenge.

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!

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

Et tu, X-UA-Compatible?

2011-02-06T00:00:00-06:00

Or, the story of how I learned that the X-UA-Compatible header/meta tag is NOT the same as the Internet Explorer 8 Compatibility View button.

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

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

X-UA-Compatible Flow

Internet Explorer uses the default Browser Mode (newest available in the browser)
Request sent (Browser Mode determines User-Agent to send, probably MSIE 8.0 or MSIE 9.0)
Response from Server. Content may include X-UA-Compatible <meta> tag and/or Response HTTP headers such as X-UA-Compatible).
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.

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 = '',
        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.

BigText Makes Text Big

2011-01-11T00:00:00-06:00

*I like shortcuts: Fork BigText on Github or Check out the BigText Demo Wizard

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 its 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();

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

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

An Update to The JavaScript Testing Challenge

2011-01-09T00:00:00-06:00

Update: The JavaScript Testing Challenge Winner

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!

Time of entry will be based on the twitter at message sent to @zachleat. Full restrictions and rules posted here.

The JavaScript Testing Challenge

2010-11-13T00:00:00-06:00

Update 2: The JavaScript Testing Challenge Winner

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

Download the JavaScript-Code-Katas Source (ZIP) (or checkout the code from the Github Repository, if you have git available)
Extract and browse to it using your operating system’s command line.
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!

Open up templateTest.js in your favorite IDE.

Add the following: TemplateTest = TestCase('TemplateTest');

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

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.

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.

In the interest of full disclosure, here are the issues I’ve ran into so far using JsTestDriver:

Doesn’t apply CSS in some browsers. Issue #81
Defaults to quirks mode. Issue #79

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!

Coding must follow every step performed by myself in the above version. Templates and keyboard shortcuts can be used at your leisure, but no code can be generated specific to the kata itself (it must be a generic). Use your best judgement here, I reserve the right to disqualify any entries submitted that don’t follow the true spirit of the competition.

Don’t fuck with the speed of the video. I’m spending my own money on this, so if you’re cheating then you’re just stealing from me. Just be cool about it, okay?

The Print version of the prize is restricted to USA or Canada, PDF version is available internationally (unless you want to work something out for shipping costs).

Faking Onload for Link Elements

2010-07-29T00:00:00-05:00

Updated 2011/09/27: Rejoice! This issue has now been fixed in Firefox.

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 ` tag and you’re good to go (onreadystatechange` for IE). But CSS is more complicated.

Resource	Method	Option for (a)synchronous	Event
JavaScript/CSS Same Domain	`XMLHttpRequest`	Both	`onreadystatechange`
JavaScript Different Domain	`<script>`	Synchronous (Asynchronous where async property is supported)	`onload` `onreadystatechange` for IE
CSS Different Domain	`<link>`	Asynchronous	What this blog post is about.

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 `` 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) {
    // resolve relative URLs (or polling won't work)
    p.urls[i] = node.href;
    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=, 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) {
        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.

ALARMd is now on Github

2010-07-21T00:00:00-05:00

In an effort to ~~mindlessly copy what everyone else on the internet is doing~~ keep current on the latest and greatest Source Code Management tools, I decided that it would be good practice to move my open source project ALARMd (as seen on Lifehacker) from Google Code to Github.

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.

Maiden Voyage of the DOM Sailbloat

2010-07-19T00:00:00-05:00

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.

URL	Total Element Count
`maps.google.com`	`731`
`my.yahoo.com`	`1508`
`calendar.google.com (Authenticated)`	`681`
`reader.google.com (Authenticated)`	`4866`

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

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.

A Race Against Time Pickers

2010-06-08T00:00:00-05:00

The Date Picker component is one of the most popular user interface components on the web today. Its operation is very simple: focus into a field (sometimes a click on a dedicated calendar button is required) intended to contain a specific date and an on-screen calendar will be shown next to the form field, allowing the user to click on a specific date to populate the form field.

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

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

Examples

Here’s a sampling of some other time picker implementations:

This implementation is very similar to the first example, just organized differently. We can do better.

Reading an analog clock isn’t the problem. When we think of time, we start with numeric representations of the hours and minutes. The first thing that pops into the average person’s head when they hear “6:00 PM” probably isn’t: the little hand on the 6 and the big hand on the 12. The analog clock representation is a mental hurdle.

Now we’re getting closer. The user selects a full representation of the time, not just the last piece of the puzzle. I like the intuitive and simple organization of this time picker. You know immediately what you’re selecting. I think we can organize the times a little bit better though, give them a visual hierarchy.

This picker represents more of the spirit of what we’re looking for. It shows a simple list of the hourly options and progressively discloses the minute selections. I think switching to a single column layout would be more intuitive for keyboard navigation (combining the above two implementations into one super-component) and would do well with larger click targets.

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: tesora.com.au and codeproject.com

Point, Charset, Match: Character Encoding in JavaScript

2010-03-26T00:00:00-05:00

If you’re not familiar with the principles of character encoding, read the prerequisite Dive Into HTML 5 section on the subject.

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: &OElig;. 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 1 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 = "&ntilde;&oacute;";

// Escaped to Latin
var string = "xf1xf3";

// Escaped to Unicode
var string = "u00f1u00f3";

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

Performance Implications of Charset, an article by Kyle Scholz

Internet Explorer Array.sort Unreliable

2010-02-24T00:00:00-06:00

What would you expect to be the result of executing the following code?

// 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:

Browser	Failures *
Internet Explorer 6	4 sizes out of 150
Internet Explorer 7	18 sizes out of 150
Internet Explorer 8 (and Compatibility Mode)	2 sizes out of 150
Internet Explorer 9 (and Compatibility Mode)	0 sizes out of 150 (Fixed!)

* 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.

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

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.

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!

If the Menu Fitts, We Must Acquit

2010-02-15T00:00:00-06:00

One of the first things you’ll learn when diving into a self-taught course on usability is the hugely popular Fitts’s Law. In a nutshell, Fitts’s Law tries to predict the time needed to move to a “target area” (usually a link, menu, button, or form element) as a function of the distance to the element and its size. The bigger/closer the element, the faster a user can move to it.

Now, upon discovering myself a newly minted Mac OS convert from the hugely popular World of Windows, I quickly discovered that the application menus (File, Edit, etc) were one of the glaring differences I’d have to adjust to. Mac OS had all menus separated from the application window, all the way at the top of the screen. Coming from the Windows environment, this seemed unintuitive. But after reading more about Fitts’s Law, I discovered the reasoning: the edges of the screen are treated as an infinite height or width! Which is just a way of modifying the Fitts’s Law to say: the easiest things to click on are at the edges of the screen. That’s why the close icon or the Start Menu is so easy to access on Windows, and why the Application Menu is at the top of the screen in Mac OS.

We know about Fitts’s Law, but why aren’t we applying it to our web applications? Why aren’t we using the power of infinite height/width to help out on our designs? It seems like this crucial usability law has been overlooked on the web, and without good reason. Let’s look at a few applications that get it wrong (of course, in my humble opinion).

All of these screenshots were taken from 100% width designs, with no real reason not to incorporate the ideas behind Fitts’s Law into the menuing system. At first glance when I brought up Google Reader, I was excited. The hover behavior appeared when the mouse cursor was positioned at the very far left of the screen, but was disappointed to discover that the although the hover background color had changed, the entire hover target was not clickable.

Naturally, I decided to make a test of my own, to test which web browsers allowed Fitts’s Law Menus. The test case encompassed both left and bottom aligned menus, for completeness. A top menu was excluded, given that the top of the screen is reserved for browser chrome or application menuing. A right menu was also excluded as the right portion of the screen is reserved for the page scrollbar (which is the easiest scrollbar to manipulate with your mouse, per the same rules).

Also, on the Mac OS 10.6 and Windows XP operating systems, a Fitts’s Law Menu at the bottom of the screen is not possible, given that the Dock and Taskbar in these operating systems occupy at least a 4 pixel trough of the bottom-most space on the monitor, even as a hover target in “auto-hide” mode. Everyone is fighting over these crucial and very useful edge pixels.

To test whether or not this behavior is working correctly, maximize your browser window and move the cursor as far left on the screen as possible, but still over the menu. If the links are still clickable, congratulations, your browser works!

View the Demo / Test Page for the Fitts’s Law Menu

Compatibility Table

Browser	Operating System	Left Menu	Bottom Menu	Status Bar	Detail
Internet Explorer 8	Windows XP	no	no	yes	IE8 has a small 3 pixel border on the left and right of each window.
Internet Explorer 7	Windows XP	no	no	yes	IE7 has a small 3 pixel border on the left and right of each window.
Internet Explorer 6	Windows XP	no	no	yes	IE6 has a small 3 pixel border on the left and right of each window.
Google Chrome	Windows XP and Mac OS 10.6	yes	no	no
Mozilla Firefox 3.5 and 3.6	Windows XP and Mac OS 10.6	yes	no	yes
Safari 4.0.4	Windows XP and Mac OS 10.6	yes	no	no

The full screen mode of each individual browser was considered outside the scope of this study.

Conclusion

We should stand on the shoulders of giants and reuse the usability studies already completed on software that has gone before us. The left side of the browser window is the best place to utilize Fitts’s Law, and we should move our left-aligned menus on fluid width designs to occupy the space flush with the window’s edge to increase the speed at which those menus will be accessible by users. Having an infinite width menu is a big click target to hit.

CSS 3 Text: A Tale of writing-mode Woe

2010-02-12T00:00:00-06:00

After reading an interesting article on using the writing-mode CSS property to display vertical text (I’m always interested in how to abuse what browsers currently support into something new and exciting), I decided to look into this writing-mode property and see what opportunities it might present.

Generally when exploring a development opportunity, I tend to prioritize my adventures towards things that are supported in Internet Explorer first. This often has the biggest cross-browser payoff, since the other browser vendors tend to have a quicker draw than the Microsoft Team. However, surprisingly enough, this writing-mode study proved the opposite to be true. It seems very interesting that Microsoft has decided to implement a portion of the CSS 3 specification, given its general stance of moving slower than an iceberg to avoid “breaking the web.” But I, for one, welcome our new choose-your-own-adventure standards loving overlords.

As far as my tests go, the only browser to support the writing-mode property at all is Internet Explorer, which was very surprising. At it’s heart, though, writing-mode is just shorthand for two other properties: direction and block-progression. Luckily, Firefox, Safari, Chrome and IE back through at least version 6 support the direction property and have proprietary options for rotation, which allows for emulation of a few of the unsupported writing-mode‘s, but not all of them. The missing piece of writing-mode emulation belongs to the block-progression property, which isn’t supported by anyone, and would allow elements to flow reverse vertically (start at the bottom of a block and flow upwards).

It’s important to note that while IE8 has really set the bar for implementation here and has chosen to support writing-mode: lr-bt and writing-mode: rl-bt, they aren’t used to display any known language text. They’re just included for completeness, and aren’t a part of the W3C CSS 3 Text Module specification.

View the Demo / Test Page

Compatibility Table

writing-mode	Internet Explorer (Trident)			Mozilla Firefox (Gecko)	Apple Safari (Webkit)	Google Chrome (Webkit)
writing-mode	6	7	8	3.6	4	4
`lr-tb`	yes	yes	yes	yes	yes	yes
`rl-tb`	emulatable	yes	yes	emulatable	emulatable	emulatable
`lr-bt`	no	no	yes	no	no	no
`rl-bt`	no	no	yes	no	no	no
`tb-lr`	no	no	yes	no	no	no
`tb-rl`	yes	yes	yes	emulatable	emulatable	emulatable
`bt-lr`	no	no	yes	no	no	no
`bt-rl`	emulatable	yes	yes	emulatable	emulatable	emulatable

CSS Code for Emulation

Writing Mode: `lr-tb`

// Do nothing, this is the default

Writing Mode: `rl-tb`

direction: rtl;

Writing Mode: `lr-bt`

// Not possible using W3C spec

Writing Mode: `rl-bt`

// Not possible using W3C spec

Writing Mode: `tb-lr`

// Not possible using W3C spec

Writing Mode: `tb-rl`

-webkit-transform: rotate(90deg);
-moz-transform: rotate(90deg);
filter: progid:DXImageTransform.Microsoft.BasicImage(rotation=1);

Writing Mode: `bt-lr`

// Not possible using W3C spec

Writing Mode: `bt-rl`

direction: rtl;
-webkit-transform: rotate(90deg);
-moz-transform: rotate(90deg);
filter: progid:DXImageTransform.Microsoft.BasicImage(rotation=1);

Conclusion

Given that 4 of the 6 known writing modes are available or available through CSS emulation means we’re in pretty good shape on the internationalization front. Consulting the Microsoft provided table for common use cases, we’re only in trouble when trying to use the “Mongolian script writing system” and an “Arabic script block quote embedded in Mongolian script document.”

In some far fetched fantasy-world legacy application where a page may use tables for layout, I could see an application team possibly using the direction property to redistribute the tables for a print stylesheet. But that certainly wouldn’t be a common use case, since using CSS for layouts is going to give you much more flexibility in that regard. If you can think of any other off the wall uses for writing-mode or direction, I’d love to hear them!

Very complete article on CSS 3 writing-mode, including some direction properties that don’t exist in the specification (like ttb, ltr-ttb, and ltr-btt)
Bugzilla Bug for writing-mode in Firefox
As of the time of this writing, I was unable to find any results for writing-mode on the Webkit bug tracker.

Trash that “Back to Top” Link

2010-02-05T00:00:00-06:00

It would seem that perfection is attained not when no more can be added, but when no more can be removed.

—Antoine de Saint Exupéry

While most would argue that the principles espoused in the above quote might also be applied to the quote itself, it would serve us better to consider how we can attempt perfection in our User Interface designs instead.

The most complete litany of reasons why you should spend your page weight on more useful bytes has been compiled by Jukka Korpela, although he seems to both confirm that they are harmful and still use them on his site.

The rules of engagement I find useful when dealing with the ill-fated “Back to Top” or its ugly stepsister “Top of Page” link are as follows:

Delete the link.

Really, you don’t need the link. It’s a sacred cow remnant of a time when people believed that all content needed to be positioned above the page fold.

Guess what? People know how to scroll! They know how to scroll down, they know how to scroll up. Considering this prerequisite has been met, it becomes very apparent that the “Back to Top” link shares an unnecessary overlap in functionality with the scrollbar and is thus, unnecessary itself.

If you have an incredibly long page with a full set of “Table of Contents” links, it would be better to position your table of contents fixed to the viewport, so as to make it always available to the user. If the Table of Contents is always available, the user will never have to click a link as a shortcut to find it.

While not a usability epidemic, the “Back to Top” link is still widely used. Instant Shift and Smashing Magazine both have articles with hundreds of examples of sites with these links.

Don’t agree? If you’re stubborn as hell and hate simplicity, you’re going to keep the link on your page no matter what reasons are presented. In that case, at the very least follow these two guidelines:

Use progressive enhancement:

<a href="#" id="back-to-top">Back to Top</a>

// Requires jQuery
$('#back-to-top').click(function() {
    window.scrollTo(0,0);

    // don't change the hash if not needed
    return false;
});

Hide the link if the page doesn’t have a scrollbar. If no scrollbar exists, the user will always be “at the top.” // Continuing with Previous Example

// Continuing with Previous Example
$(function() {
    $('#back-to-top').hide();
});

// If the page scrolls, we know there is a scrollbar.
$(window).scroll(function() {
    $('#back-to-top').show();
});

// For completeness, you may also want to
//   add logic to the "resize" event.

Really though, just delete the link.

The “24″ Clock on ALARMd

2010-01-24T00:00:00-06:00

If you’re only using @font-face for titles and text, you’re missing out on a whole wealth of use cases that have yet to be explored. For instance, I created a very simple 7 Segment Display Numeric font to be used for a skin on alarmd.com and changed the color using nothing but CSS to create the “24″ Clock (true fans will note that the actual font is italic and has a serif on the 1). Nonetheless, this is just another useful application of @font-face.

Take a look at the Dingbats section on fontsquirrel to get your brain going in the same direction.

DIY Webdings – CSS Sprites using @font-face

2010-01-03T00:00:00-06:00

Almost everyone knows the Webdings font or its sibling Wingdings. Even if you don’t, chances are pretty good that it’s installed on your system.

Webdings is a symbol font designed in 1997 as a response to the need of Web designers for a fast and easy method of incorporating graphics in their pages.
…

Webdings is ideal for enriching the appearance of a Web page. Because it’s a font, it can be installed on the user’s system, (or embedded in the document itself) is fully scaleable [sic] and quick to render. It’s a perfect way of including graphics on your site without making users wait for lots of graphic files to download.

– Source Microsoft Typography

Microsoft was onto something here, and there is a nice parallel that can be drawn between the font and a CSS sprite: namely that multiple images are stored under the guise of a single HTTP request. So, why not create our own font and use it as a CSS sprite? Each character in the font (glyph) will be a single image in the sprite.

Why is this awesome?

We can change the color of our font using nothing but CSS color. This is a big one. We don’t have to have separate images for hover states! And if we want to change the color scheme, there are no new images to generate and we don’t have to make any changes to the font to do so.
Don’t have to monkey around with difficult to maintain CSS positioning code.
Fonts scale, graphics don’t. Zooming in on a graphic will result in a pixelated image, but fonts will be smooth like a 6 blade razor shave. Try zooming on the demo file below.

Why is this not awesome?

Font glyphs can only contain one color.
May experience the Flash of unstyled text (FOUT) while the font is loading.
Extra markup required for IE6 and IE7. While @font-face is supported in all non-extinct versions of IE, each @font-face sprite requires a corresponding text character on the screen. For instance, A, the A is required to display the @font-face Sprite stored under the A glyph.

Luckily, in most browsers we can inject a character using CSS :after/:before and the content property. Unfortunately, this is not supported in IE6 or IE7. I haven’t investigated whether or not this might be solved using other means (CSS expressions) yet.
Safari asks for permission to use the font with a scary popup box, which I assume is a security precaution gleaned from the Windows Vista playbook.

Demo

The following jQuery UI Icons are currently used in jQuery UI and are stored in one big CSS sprite.

It was pretty trivial to create a font with a subset of the jQuery UI icons (only the first 20, just a proof of concept here) using the wonderful FontStruct utility. Then, I took the TTF generated by FontStruct and plugged it into the completely lovely FontSquirrel @font-face Kit Generator. That gave me everything I needed for a fully cross-browser test.

View the Demo

Let me know what you think!

Successfully tested on:

Google Chrome 4 (Mac)
Safari 4 (Mac)
Firefox 3.5 (Mac and Windows)
Internet Explorer 8
With documented limitations above: Internet Explorer 6 and 7 (Compatibility Mode in IE8)

Does not work on (no @font-face support):

Google Chrome 3 and prior
Firefox 3 and prior

Read more about @font-face support from Paul Irish.

Don’t Give Up on Internet Explorer Yet

2009-12-09T00:00:00-06:00

These days, the browser landscape is more fragmented than ever. Were times easier back when IE6 and Firefox ruled the internet? Easier perhaps in terms of the number of browsers you had to launch for testing, but not better for any user’s experience. We are in a new world, where more web browsers are causing developers to become increasingly pragmatic with their designs and code. Sure, standards have created a safe haven under the newest versions of the Big 3 (Firefox, IE, Safari), but the lay majority are still using whatever default has been installed onto their computer, and they probably can’t tell you the difference between their web browser and a search engine.

We must be resilient to resist the transformation from development pragmatism to user abandonment, especially considering a developer’s trend of being insulated with the latest equipment. We use the newest hardware and download the most sophisticated browser software because we want the best experiences. We stack the cards in our favor. The difficulty lies with the populace that want a good experience (they can tell a fast site from a slow site), but they don’t want to buy new equipment or install a better browser. So the question has become: Where do you place your chips on the spectrum balancing modern hardware/software and the user experience?

As web developers, it has become increasingly easy to become disenfranchised with the lay majority’s computing environment. I’ve witnessed this personally after purchasing my first Apple computer, a device curiously immune to the plague of IE 6/7 (8 as well, but I would hesitate to label it as a plague, more like a normal run of the mill flesh eating virus). It’s an interesting phenomenon, being cutoff from the Windows environment (save virtualization) during development. It’s delightfully tempting to declare damnation upon the plague ridden Internet Explorer Zombies, and develop your web presence to standards alone, allowing less focus on the harshest development environment imaginable and more on actual problem solving.

When developers engage in quasi-web development, perhaps in the form of an iPhone specific web application or an Adobe AIR desktop application, it fosters similar feelings. The work shares many languages and technologies with real (wide-open) web development, but is targeted towards a single web browser. This benefits of this sort of tunnel vision device targeting must be carefully weighed against the penalties you’re paying in narrowed default-install client compatibility. At that point, it’s just friends with benefits.

Google Wave, in fact, requires the use of Safari, Firefox, Chrome, or the Google Chrome Frame plugin (which doesn’t count as actual browser support). As of the time this article was written, as many as 64% of all users (source) are met with the above screen when trying to access Google Wave. Let’s be clear: Ease of development is not an excuse to abandon users. Whatever happened to Device Independence?

Not surprisingly, Google Wave’s stand against Internet Explorer has not started a trend. Instead of all out war, the community at large has decided that subtlety is what’s needed to win this fight. Let’s hold back the sexual healing of rounded corners, even though perhaps users will call our design harsh or cold. Let’s give them plain buttons instead of nice three dimensional buttons with text and box shadows, even though they may be less actionable.

Let’s make it easier on ourselves at the expense of the user experience of The Zombie Majority. We make this sacrifice because we assume that Zombies won’t be able to tell the difference between eating a big juicy Einstein brain and a smaller but nonetheless still tasty brush clearing George W. And you know what, I think we’re right.

Updated to include a few more thoughts on Adobe AIR and the iPhone.

Device Independence on the Open Web

2009-08-29T00:00:00-05:00

Open Web advocacy can get pretty lonely working in Big Enterprise. Armed with slow moving standards bodies, and held back by antiquated browser support, architectural battles over tools and frameworks can get pretty hairy if you don’t approach them with the right frame of mind.

Big Enterprise is traditionally known for creating development environments that foster a “get it done” mentality, often rewarding results over correctness (mileage, of course, may vary).

My company uses IE6, and the application works in IE6, so it’s done!

This little quagmire is amplified by the fact that when using Open Web technology, there are many ways to get things done, and most of them are incorrect. But those mistakes don’t manifest themselves until the project is in the hands of the end user, whom we often punish for our oversight.

But there is hope. Using the power of web standards and Open Web best practices, we can achieve something panoramically, not microscopically, beautiful.

The secret sauce of building for the Web isn’t its distribution model, in which updates are managed on the web server without the need to update software on the client (although the Anti-IE6 vigilantes would tell you differently). It most certainly isn’t development efficiency, as most people new to the game will so readily inform you of. Cross browser quirks due to non-standard browser implementations of CSS and JavaScript, or vague standards specifications have seen to that.

When I was writing Visual Basic, I got my job done so much quicker and easier!

The power of the Open Web is Device Independence.

Visitors to our sites shouldn’t be met with warnings about what device they’ve chosen to use.

This site viewable only in IE7 , Firefox, Chrome, or Safari, and at minimum 1024×768 resolution.

This site requires Flash or Silverlight

I realize that this is a controversial stance, especially given that most sites are dropping support for IE6, and more are relying on Flash and Silverlight plugins. Architect applications to your client device usage statistics, and don’t let your tools shape the statistics for you. Using techniques like progressive enhancement, we can ensure that our sites degrade gracefully to the capabilities of the client device. At it’s truest form, this is basic accessibility. But, Device Independence might be a more accurate term, since accessibility is unfortunately an overloaded term scoped solely with devices tied to disabilities (screen readers, for example). While screen readers are a very important piece, there is a bigger picture.

When the iPhone came out, there was an uproar because it didn’t support Flash, for battery life and other reasons. But the uproar was from developers who had designed applications specifically for Flash! Would you say that those Flash applications were designed with device independence in mind? YouTube got around this by encoding their videos in MP4 format, which arguably has a higher device independence rating than the Flash format.

Keep in mind that we’re not attempting to handle every permutation of end user browser settings, since most don’t change the defaults. Instead we are trying to scoop up the largest base of supported devices with the least amount of effort! Who cares if an end user disabled JavaScript in their preferences? I’m more worried about the mobile browser that doesn’t even support JavaScript at all. But when you use Open Web properly, you get support for both!

Output Device Independence

Full Web Browsers: Does your site work in Opera? Don’t worry about pixel perfection, that’s something completely different — does it work?
Web Browsers on Mobiles
Search Engine Spiders and other Screen Scrapers
Screen Readers
Printers: Ever had to make an entirely separate page for print-friendly version of your application? Flash/Silverlight do not print well
Televisions: Xbox 360, Wii, and Other Media Center Devices
Projectors
and more…

Take a look at the CSS specification for media types. The standards are there! Support for CSS media types isn’t fool proof by any means, but the end goal is clearly visible.

Input Device Independence

But I’m not just talking about output device independence either. User interfaces should be adaptable to different input devices as well.

Mouse
Keyboard (often overlooked in web applications)
Touch Screens (Single and Multi-touch)
Voice, Motion Capture, and Facial Recognition (the standards and technology aren’t quite there yet, but progress is being made)
and more…

The world is developing the Open Web, and it isn’t limited by a single company’s goals and timelines. At times, Open Web may seem like it’s a very slow moving glacier headed our way, but what else can you do but laugh when companies try to power their Titanic right through it?

Article originally inspired by Yahoo’s Graded Browser Support.

Quick Performance Tip: jQuery and addClass

2009-06-30T00:00:00-05:00

Abstractions are helpful and dangerous. But the more we know about a library’s internals, the less danger we’ll be in later. Here’s an issue I ran into where I had assumed that jQuery would be optimized for this case, but it wasn’t. I’ll go over my bad assumption and how to workaround it.

As of jQuery 1.3.2, adding multiple HTML classes to an element using jQuery’s addClass method will add them one at a time, modifying the className property of an element for each class.

$('#myElement').addClass('myFirstClass mySecondClass');

Here’s the original code inside of jQuery 1.3.2. Note how the classNames string is split, and elem.className is changed for each split entry.

add: function( elem, classNames ) {
jQuery.each((classNames || "").split(/\s+/), function(i, className){
    if ( elem.nodeType == 1 && !jQuery.className.has( elem.className, className ) )
        elem.className += (elem.className ? " " : "") + className;
    });
},
// ...

This may cause longer than needed delays, as reflow may occur after every class is added individually. If absolutely necessary, you can always fall back to modifying the className yourself, like so:

$('#myElement').each(function() {
   this.className += ' myFirstClass mySecondClass';
});

Most likely, this isn’t a tip that will be needed, but it is useful to be aware of.

Performance Caveat with jQuery Selectors and Live Events

2009-05-08T00:00:00-05:00

Prerequisite: Knowledge/Experience with jQuery Live Events (new in jQuery 1.3), and the concept of Event Delegation.

When developing on the front end, it’s easy to prioritize correctness over performance. Performance is the step child that gets lost while you’re pulling your hair out worrying about cross browser compatibility. It’s very important to regularly benchmark your JavaScript code, using a profiler or some form of benchmarking code paired with a cross browser logging utility (see Firebug Lite, YUI Logger, or log4javascript).

Event delegation is a great way to program for performance. The live jQuery method was a great addition to the jQuery core, it makes event delegation really easy (see also the closest method). Unfortunately, it isn’t quite what I expected.

For example, say you have a page containing approximately 500 custom tooltip components on it (not typical, but stick with me, this is to prove a point). How might one go about adding a simple live event to activate each tooltip when the user hovers over it?

$('span.myTooltip').live('mouseover', function(event) {
    // activate tooltip
});

See the problem? jQuery will actually run the selector on the document, resulting in unnecessary overhead. jQuery is only assigning a single event handler to top level of the document, why does it need to know what nodes it will be binding to before assigning the callback?

What can we do? Let’s create a jQuery function, instead of a method, so it won’t query the document. Try this on for size:

$.live = function(selector, type, fn) {
    var r = $([]);
    r.selector = selector;
    if(type && fn) {
        r.live(type, fn);
    }
    return r;
};

Usage

// Single event type
$.live('span.myTooltip', 'mouseover', function(event) {
    // activate tooltip
});

// Multiple event types (you can call the jQuery live method on the return value from the function)
$.live('span.myTooltip')
    .live('mouseover', function(event) {
        // activate tooltip
    })
    .live('mouseout', function(event) {
        // deactivate tooltip
    });

Also, as a side note, keep in mind that jQuery live doesn’t support space separated events, like bind does.

// Will not work.
$('span.myTooltip').live('mouseover mouseout', function() {});

Have fun!

ALARMd Unix Time Format for 1234567890 Day

2009-02-13T00:00:00-06:00

In honor of 1234567890 day, I’ve added the Unix time format to ALARMd.

Hit Options, then the Clock Format tab to change to Unix Time. Enjoy!

Registration Forms Suck, Let’s Mitigate Suckiness

2009-01-10T00:00:00-06:00

A lot of people complain about registration forms. Some people have suggested getting rid of them altogether, allowing users to utilize login credentials from accounts they already have through OpenID. But even with a highly technical audience, OpenID adoption is problematic.

So, some sites have gone two ways, allowing OpenID, but also a proprietary registration system. This too, is problematic. It would seem that given a choice, the John Doe the Plumber style user will choose a proprietary account over the confusing user experience presented to them through OpenID.

But the annoyance doesn’t just lie with account registration for web applications. Typing your personal information on every blog you comment at is also repetitive and unnecessary. Some sites even require account registration for something so minor and transient as a blog comment.

Unfortunately, for the time being, it looks like registration forms are here to stay. So, what can we do to make those registration forms more usable, more efficient, and ultimately downright friendly? I know that you’re ahead of me on this one: Let’s auto-complete information for the user.

Please keep in mind that this power can be used for both good and evil. Essentially what we’re discussing here is data mining available information from various social networking sites on the internet, trying to glean personal information about an end user that has volunteered a piece of their data already. What can we get from what we already have?

Once a user has typed in their e-mail address, we can:

Retrieve Twitter profile information (example shown on Chris Heilmann’s blog):
- Full Name
- Short Personal Description
- Location
- Web site URL
- Time Zone
- Favorite Colors (used on their profile)
Retrieve an avatar if they’ve registered for the Gravatar web service (See my earlier post discussing this).
Get their upcoming calendar events from a public Google Calendar. (Perhaps not as useful for autocompleting forms, but interesting)
Find their UID on Flickr, which gives you a source for:
- Full Name
- Location
- Flickr Avatar

If you know any of their social networking usernames, you can:

find their MyBlogLog profile, if they’ve linked the service to their account (Sample query, I added my twitter). Now we have:
- MyBlogLog Screen Name and ID, from which you get their MyBlogLog profile:
  - Nickname
  - Picture
  - Age
  - Sex
  - Location
  - A list of tags they use to describe themselves.
- MyBlogLog Avatar

Those are only some of the proof of concept API’s that I’ve listed here. The interesting piece of this, is that once you have a small piece of information, it opens up the door to other searches.

One can only imagine how many leaves are in this tree. For example:

Facebook’s Users.getInfo (in JavaScript)
Yahoo’s Social Tools, get an end user’s GUID and go to town on their profile.
- Google Contacts, I didn’t even start to look through their API’s. Before you start jumping the privacy fence to a self induced heart attack, remember that all this information has been volunteered by each individual participating in each of these services. Remember, with great power comes great responsibility.
What do you think? Scary or useful?

Scare Your Visitors with this JavaScript Gravatar Plugin

2009-01-08T00:00:00-06:00

See the Demo

Download the Source Code

Here’s a use case. An unregistered visitor visits your blog, and decides that your content is so good that it merits a comment! Congratulations, you’ve fooled them! Now you can twply their account details for $1200 on Sitepoint! Just kidding. But generally, when you visit a blog’s commenting section (such as the Tournology Blog shown above), you’ll see a simple form to authenticate you’re not a spammer, generally including (among other things) an e-mail address field.

Well, since they’re typing their e-mail address, wouldn’t it be cool if we could show them their gravatar right there, inline with the blog comment form? Well, that’s now possible with my new JavaScript Gravatar Plugin! It doesn’t have any server side language dependencies.

Hell, gravatar.com could even use this to improve the user experience of registering your e-mail account. Right now it does a full page refresh and doesn’t even show you a preview!

See the Demo

Download the Source Code

Licensing

Licensed under the WTFPL, as highly recommended by Isaac Schleuter (see discussion).

JavaScript Dependencies:

Requires jQuery (Feel free to port and post a link!)
Requires md5.js

Example Usage:

Easiest form, onblur of email text input field:

$('#emailTextField').blur(function(event) {
    $(this).after($.gravatar($(this).val()));
});

Showing all options, again onblur of email text input field.

$('#email').blur(function(event) {
    $('body').append($.gravatar($(this).val(), {
        // integer size: between 1 and 512, default 80 (in pixels)
        size: 200,
        // maximum rating (in order of raunchiness, least to most): g (default), pg, r, x
        rating: 'pg',
        // url to define a default image (can also be one of: identicon, monsterid, wavatar)
        image: 'identicon'
    }));
});

Update: This script has been moved to Github.

DOMContentLoaded Inconsistencies (in Browsers and JavaScript Libraries)

2008-12-04T00:00:00-06:00

Quick Summary

Prototype and Dojo are the only major JavaScript frameworks that correctly time the DOMContentLoaded inside of an iframe in Internet Explorer. MooTools comes close and both YUI and jQuery both exhibit incorrect behavior.
Usually, browsers that have a native DOMContentLoaded event will fire it after both JavaScript and CSS (external script, link tags) have loaded. But Opera fires prior to CSS link tags loading.

We all know the problem, but we may not all call it the same thing. Every popular JavaScript library has its own name for the DOMContentLoaded event.

JavaScript Library	Event Name
YUI	DOMReady
jQuery	ready
MooTools	domready
Prototype	dom:loaded
Dojo	addOnLoad

But the naming scheme isn’t the only part about this event that’s inconsistent. There are a few hacks strewn around the net that have been bastardized (read: modified to the will of library authors) into each individual framework. These have been posted time and time again, but for post completeness are the following:

IE DOMContentLoaded Hack	Description
`doScroll` by Diego Perini	Uses a `doScroll` method call, which will throw an error if the `ondocumentready` event hasn’t fired on the primary document (take note of the usage of the word primary). Once `doScroll` doesn’t throw an error, it is assumed the DOM has loaded.
`onreadystatechange` and `readyState`	`onreadystatechange` “fires when the state of the object has changed,” and changes the `readyState` property of the object through the following states (not all apply to every type of element): `uninitialized`, `loading`, `loaded`, `interactive`, and `complete`. (source: MSDN) Usually set on the document object, or a script element (as used in the Script Defer method described next.
Script Defer by Dean Edwards	document.write’s a script tag with a `defer` attribute. Defer will cause the browser to delay execution of the script until the DOM has successfully loaded (using onreadystatechange on the script tag until its readyState is “complete”). Without defer, the browser would execute any script tag immediately.
HTC Behavior by Dean Edwards	Much less popular approach using proprietary HTC Behavior files. Generally avoided due to the addition of an extra HTTP request to the page in order to download the external .htc file. As a side note, if using this approach, the `"oncontentready"` event will work better than the “ondocumentready” event used by Mr. Edwards.
Ghetto Method	Of course, the easiest way to do it is to put a script tag right above your ending `</body>` tag that triggers the event manually. This really only works if you have full control of the content, and isn’t really a library solution. Worth noting though.

Benchmark for Library DOMContentLoaded Implementations

I created a benchmark trying to answer the simple question: when does the DOMContentLoaded event fire? Each implementation has different effects, especially in iframes and with stylesheets.

What Works

The Internet Explorer hacks presented above are reliable when used on a standalone document (not inside of an iframe).

Mozilla Firefox, Safari, Chrome, and Opera all contain a native DOMContentLoaded event that each framework uses to consistently fire at the correct time. So, it isn’t even worth summarizing the results for tests in every browser with a native DOMContentLoaded event, except Opera. Opera took a different design approach with their DOMContentLoaded event (certainly not wrong, just different), which we’ll analyze below.

Internet Explorer inside an Iframe

All libraries below did no branching based on IE versions, all used the same method for IE6, IE7, or IE8. I performed no tests in IE8, however.

JavaScript Library	Method	Waited for:
JavaScript Library	Method	<body> <script>	<head> <script>	<link> CSS	<img>
YUI 2.6.0	doScroll, setTimeout	Incorrect: Fires almost immediately (~20ms)
jQuery 1.2.6	window onload	X	X	X	X
Prototype 1.6.0.3	Script Defer	X	X	X
MooTools 1.2.1	doScroll and set innerHTML, setTimeout	*	X	X
Dojo 1.2.0	Script Defer	X	X	X
IEContentLoaded	doScroll, document.onreadystatechange	Incorrect: JavaScript error.
addDOMLoadEvent	Script Defer	X	X	X

For some reason, not only did the MooTools library not wait for the body script to trigger DOMContentLoaded, the body script never executed at all.

The most important takeaway from this blog post are the successful methods of faking DOMContentLoaded in Internet Explorer. The obvious library winners here are Prototype and Dojo, with the addDOMLoadEvent script also exhibiting correct behavior. MooTools is a close runner up, and I would be interested to find out why it didn’t execute the body script (that’s left for another day, or perhaps a generous commenter).

Opera 9.6

JavaScript Library	Method	Waited for:
JavaScript Library	Method	<body> <script>	<head> <script>	<link> CSS	<img>
YUI 2.6.0	Native DOMContentLoaded	X	X
jQuery 1.2.6	Native DOMContentLoaded + Code to wait for Stylesheets	X	X	X
Prototype 1.6.0.3	Native DOMContentLoaded	X	X
MooTools 1.2.1	Native DOMContentLoaded	X	X
Dojo 1.2.0	Native DOMContentLoaded	X	X
IEContentLoaded	N/A to Opera	X	X	X
addDOMLoadEvent	Native DOMContentLoaded	X	X

As you can see above, Opera typically will fire DOMContentLoaded prior to stylesheets loading successfully (ignoring the jQuery specific code to provide consistency cross-browser)

Thanks to Adam Koch for first pointing me in the direction of jQuery in an iframe ignoring DOMContentLoaded in IE.

Update: There is an open ticket for YUI on Sourceforge, and I’ve opened a ticket for jQuery on their Trac site.

Dear IE6: Please Cache my Images.

2008-10-18T00:00:00-05:00

A few months ago, I took on a new role at Union Pacific Railroad as the lead architect for an internal project: a Union Pacific UI Library used in our IT department on all new web-based projects. Based on jQuery, it is similar to a project like jQuery UI, but it has a few more components and they’re branded to our color scheme and programmed to our usability requirements.

The project has allowed me to expand my knowledge of browser quirks, improving my frontend-fu with every closed support ticket. What does that mean for you? More blogs posts. Learn from my mistakes (and from those I’ve inherited).

This week presented an interesting, albeit decreasingly relevant scenario, where a customer was seeing performance problems when loading a simple web page in Internet Explorer 6. The only hint to the root cause was a claim that he witnessed “400 items remaining” in his status bar. Naturally, this took awhile, but at least we had somewhere to start: Apache access logs.

Consider the following (jQuery) code to add three new images to the page using JavaScript:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
    <head>
    <script type="text/javascript" src="jquery-1.2.6.min.js"></script>
    <style type="text/css">
    img.bacon { width: 100px; height: 67px; background-image: url(bacon.png); }
    </style>
   </head>
    <body>
        <script type="text/javascript">
        jQuery(function() {
          jQuery('body').append('<img src="spacer.png" class="bacon"/>');
          jQuery('body').append('<img src="spacer.png" class="bacon"/>');
          jQuery('body').append('<img src="spacer.png" class="bacon"/>');
        });
        </script>
    </body>
</html>

Note how each image being added dynamically has a background-image as well.

In a normal web browser (read: Internet Explorer 7+, Firefox *), this would result in the following Apache access.log (with an empty browser cache) with only 4 HTTP requests (ignoring favicon.ico, which is irrelevant to this study):

127.0.0.1 – - [18/Oct/2008:22:59:09 -0500] “GET /ie6cache/ HTTP/1.1″ 200 657

127.0.0.1 – - [18/Oct/2008:22:59:09 -0500] “GET /ie6cache/jquery-1.2.6.min.js HTTP/1.1″ 200 55774

127.0.0.1 – - [18/Oct/2008:22:59:09 -0500] “GET /ie6cache/spacer.png HTTP/1.1″ 200 207

127.0.0.1 – - [18/Oct/2008:22:59:09 -0500] “GET /ie6cache/bacon.png HTTP/1.1″ 200 5416

In Internet Explorer 6, however, this is the resulting Apache access.log (empty browser cache) with 8 HTTP requests:

127.0.0.1 – - [18/Oct/2008:22:57:48 -0500] “GET /ie6cache/ HTTP/1.1″ 200 657

127.0.0.1 – - [18/Oct/2008:22:57:48 -0500] “GET /ie6cache/jquery-1.2.6.min.js HTTP/1.1″ 200 55774

127.0.0.1 – - [18/Oct/2008:22:57:48 -0500] “GET /ie6cache/spacer.png HTTP/1.1″ 200 207

127.0.0.1 – - [18/Oct/2008:22:57:48 -0500] “GET /ie6cache/spacer.png HTTP/1.1″ 200 207

127.0.0.1 – - [18/Oct/2008:22:57:48 -0500] “GET /ie6cache/bacon.png HTTP/1.1″ 200 5416

127.0.0.1 – - [18/Oct/2008:22:57:48 -0500] “GET /ie6cache/bacon.png HTTP/1.1″ 200 5416

127.0.0.1 – - [18/Oct/2008:22:57:48 -0500] “GET /ie6cache/spacer.png HTTP/1.1″ 200 207

127.0.0.1 – - [18/Oct/2008:22:57:48 -0500] “GET /ie6cache/bacon.png HTTP/1.1″ 200 5416

When a web browser parses your markup and sees three image tags with identical src attributes, it makes only one HTTP request to the server for that image, and the rest of the images are loaded from the local web browser cache (no more HTTP requests are made). This is standard behavior for all modern web browsers. But in IE6, as you can see from the above log, made 3 requests to the server for both spacer.png and bacon.png. Why?

Turns out there are two independent issues at play here:

The classic IE6 background-image flicker problem. This has been documented extensively, and the problem is that IE6 bypasses its local web browser cache for any image requests made for CSS background-images inserted on the page dynamically. The good news for this one is that the fix is a simple one.
```
if(jQuery.browser.msie && parseInt(jQuery.browser.version, 10) == 6) {
  try {
    document.execCommand("BackgroundImageCache", false, true);
  } catch(err) {}
}
```
Note the simple check for IE 6 execution only. This is optional, but keep in mind that this problem is not present in IE7+. During your testing, also keep in mind that Mister Pixel reports (and I can confirm) that once you run this command, this setting will persist in your browser, even if you empty your cache and remove the code from your scripts. You’ll need to close your browser window to reset the setting to default.

See also Dean Edwards’ and Hedger Wang’s studies on this issue for more information. But this is really only half the problem. This will fix the duplicate bacon.png HTTP requests, but we’ll still see 3 spacer.png HTTP requests in our logs.
The other issue is a separate but equal problem with IE6 caching. When inserting images with identical src attributes, IE6 will always go to the server (which means an extra HTTP request) for a new image. This is a documented feature in IE6, and the fix they have listed on their page isn’t ideal. The best solution here is to eliminate the need for spacer.png altogether. I can put these bacon background’s on a div tag just as easily, emphasizing pragmatism over semantics in this case (it’s a small sacrifice, you’ll live). If you have an <img> tag with a source you actually need, why not move it to the background image on a div tag? Unfortunately here, the takeaway is that your logic may need to be restructured to workaround this issue.
See also Mihai Bazon’s study for more information, but do keep in mind that grouping this issue with the background flicker problem is an incorrect categorization. They are two separate issues and the fixes represented on that page don’t really fix the issue at all. Implementing server side caching as a “fix” is like using a bandaid for a tourniquet. You don’t want an HTTP request to go to the server at all, I don’t care if the response is a 200 OK or a 304 Not Modified. No HTTP request is always going to be faster than a server side cached response.

These issues will present themselves more frequently if you have the “Every visit to the page” caching option enabled in your Internet Tools in Internet Explorer. Good luck.

Relative URLs including the Domain

2008-10-16T00:00:00-05:00

Just a neat little trick I saw while browsing the source code of Google Calendar. In some of their CSS files, they link to background-images using URLs that include everything but the protocol, which is something I hadn’t seen before.

The most common usage of a relative URL is linked from the root (note the slash at the beginning), like so:

You can also use ../ to navigate up a directory in your path, but that’s boring. The interesting question is: what if I wanted to load content from a separate domain, while at the same time transparently using the protocol used on my page?

Do what Google Calendar does and use the following style:

Note the lack of http: or https: from the URL. If this page were hosted on https (we don’t pay for certificates around here, so you’ll have to put up with the security warning), the last image source will load from https as well at no additional development cost.

This seems like it would be especially useful if you were using the YDN Performance tip to Split Components Across Domains. Remember, we’re not just talking images. This involves how the browser resolves URLs, so could be used inside href tags, css urls (as Google Calendar did), etc.

ALARMd is a Google Code Project

2008-10-08T00:00:00-05:00

Update: ALARMd has been moved to GitHub.

I received a request this week to participate in development of the internet alarm clock I developed awhile back called ALARMd. It has gone through two major revisions, and my interest in contributing additional source code to the project is waning. I’ve got other projects. So, I’ve decided to publish it to Google Code. I won’t be doing new development on the project, but will accept patches and commits to the repository. Feel free to ask me for project member status.

See ALARMd on Google Code.

Fight Registrastination. Register to vote!

2008-09-07T00:00:00-05:00

Apologies to international readers, this spam message is intended for citizens of the USA only. Thanks for understanding.

Have a friend that hasn’t registered to vote yet? Do your civic duty by guilting them into action. Help them fight registrastination by sharing a link to a big bold deadline.

Fight Registrastination. Register to vote NOW!

For those demanding technical content from each blog post, the page does use a nice JavaScript IP Address Geocoder hosted by MaxMind that’s worth a look. It also uses a previously mentioned JavaScript Pretty Date Difference script.

Here’s a few other things that one might also look at if they were making a location aware application:

Google Maps API: Geocoding
Gears GeoLocation API
Parse a Facebook user’s location.
Twitter’s API only provides update_location, not a way to get the current location.
As mentioned above, MaxMind’s IP Address Geocoding Service
Yahoo’s FireEagle, BrightKite, Plazes, and Dopplr

MaxMind’s seemed the best fit for my use case: guessing the State of an anonymous user.

Writing a Front End Engineer’s Resume (or CV)

2008-09-04T00:00:00-05:00

In the United States, we usually call this document a resume, but it would appear that the international term is actually CV. There are differences, but the tips used here can be applied to both.

Everyone is trying to sell something nowadays, and the most important product you can sell is yourself. My high school counselor used to tell all of her students that same advice, and unfortunately most of them became hookers. But if you’re not into prostitution, by now you’ve probably realized why so many people have said that blogs are the new resume. It’s true – I’ve had a few pretty meaty hooks dangled in front of my fish brain since I started this web site, and a lot of large companies are using blogs as a means of finding new talent.

But a blog will only get you in the front door, many employers still want to see a real resume prior to entry into the screening process. So, why not kick your resume up a notch? Let’s iron its pages, shave its hairy regions, and spray some web-based musk on that bad boy.

Tips for Putting your Resume on the Web

Don’t use anything that generates code (that means no DreamWeaver or heaven forbid, Microsoft Word). You want your “view source” to look like a marine’s hair cut: everything should be indented uniformly.
Sprinkle some microformats in there! There is even a specific hresume microformat. Some other good microformats to use are: hcard (like a personal business card, but can also be used to describe an organization as well), hcalendar (for any dates, or date ranges: like when you were employed), XFN (to describe relationships between people, think references), adr (for addresses). Of course, the good part about microformats it that there is overlap between them. hcard uses adr and hcalendar, and hresume uses hcard, etc.

Some social web sites have already provided some microformats that you can use as a starting point: Linked-in has an hresume for every profile, and twitter has a hcard that you can pilfer.
Add a favicon. As the Yahoo Performance team suggests, the browser is still going to request one, even if one isn’t in the markup, so you might as well have one.
Pick your DOCTYPE carefully. Make sure it’s not one of the “loose” ones, for obvious prostitution-based reasons described above — the stricter the better. Whatever DOCTYPE you decide to use, make sure your markup validates properly. No mistakes here. I chose to serve my document using HTML 4.01 Strict as text/html with UTF-8 encoding.
Your handwritten CSS should validate as well. If you have some library code that misses the mark in a few places, I think that’s okay. Remember: a good coder codes, a great coder re-uses.
Make sure it looks good when your future employer prints out 500 copies to pass around the company as an example of the best resume he’s ever laid his eyes on. Add a media=”print” stylesheet to beautify the print layout.
Make sure it all validates, loads fast, and doesn’t have any broken links. I like to use YSlow to test my page weight and see my ranking.

Bombs away! Those are the tips I followed to create my web-based resume. It has a YSlow score of 89, is 17.2K in size with 5 HTTP requests, and validates as HTML 4.01 Strict, and my non-library CSS is valid CSS 2.1 (I’m also using YUI CSS for layout, which doesn’t validate).

Once you’re finished, hresume even has a public wiki page where they let you post your resume. Have fun, or get rich trying!

Update: grammar nazi cullination.

Emulating onhashchange without setInterval

2008-08-21T00:00:00-05:00

There is one limitation that all of the major JavaScript browser history management plugins have to hack around: How to tell when there is a change to the location.hash? Sure, you can tell when you’re modifying the hash yourself, but what if the user hits the back/forward button?

YUI’s History component and Really Simple History both use setInterval with an internal variable to compare and find changes. But this isn’t really an optimal solution. As proper front end engineers, we should avoid timeouts as much as possible. Internet Explorer 8 will have an onhashchange event that clients will be able to subscribe to. That will be nice. But surely, a cross browser solution without the use of setInterval exists.

Look, a cross browser solution without the use of setInterval:

On initialization, we load an iframe onto the page that is positioned absolutely at -500px,-500px so the user can’t see it. It is a skeleton page that only needs cross browser code to add an “onscroll” event, and to be able to calculate the scrolled position of the iframe itself. For my example, I use jQuery and the dimensions plugin to accomplish this, but it could easily be trimmed down to only the bare essentials (or ported to a different library).
To add an AJAX history entry into the browser’s history under an assigned hash string, we first add a <a name="hashString">hashString</a> to the <body> tag of the iframe. Using css to increase the size of the a tag proportional to the iframe’s height, we can guarantee scrolling will happen.
Then, we change the location.hash of the iframe to point to that <a> tag. This will scroll the iframe to the content, and create a new entry in the browser’s history object.
Inside the iframe, we have our onscroll event that fires when the scrolling in the previous step took place. (Minor IE-related workaround: The browser’s history object is changed, but the hash property doesn’t when attempting to read it later. Instead, we find the <a> that matches up with the scrollY/pageOffsetY property inside of the iframe, and retrieve the matching hash from the <a> tag.)

The nice thing about this approach is that you don’t even need a history manager anymore. This little iframe will do all of your dirty work for you. And it will even maintain your history alongside any other iframe browsing on the page.

Advantages:

Can serve as back button support and full AJAX history manager.
Page Weight: the test page and iframe HTML files together weigh in at 2.76 KB. That includes the non-jQuery JavaScript needed to do everything.
Cross browser: Tested in FF3, IE7, IE6, Opera 9.5, (not Safari — see below)

Limitations:

No bookmarking support. We aren’t changing the top hash, we’re changing the iframe hash, so these aren’t bookmarkable.

Sample Example:

Update: Given time for more rigorous testing, it doesn’t look like Safari supports this approach. So, until WebKit fixes #9166, we’ll have to stick to timers in Safari. A more pragmatic programmer than I might hack around this approach by exploiting #19202, but that certainly wouldn’t be a long term solution. I’ve also updated the test page above, at Dean Edwards humble request, to support dynamic client size text size changes.

Double Whammy: OpenID and Microformats

2008-05-23T00:00:00-05:00

Microformategery

Own your Identity had a great post today detailing a great feature on the signup form of the Get Satisfaction site.

They rely on the fact that sites like Twitter and Flickr publish an hCard microformat for all of their users publicly on their website. If you go to my twitter page and view the source, you’ll find the following code available to anyone (without authentication):

<address>
   <ul class="about vcard entry-author">
      <li><span class="label">Name</span> <span class="fn">Zach Leatherman</span></li>
      <li><span class="label">Location</span> <span class="adr">Omaha, NE USA</span></li>
      <li><span class="label">Web</span> <a href="http://www.zachleat.com/" class="url" rel="me">http://www.zachle...</a></li>
      <li id="bio"><span class="label">Bio</span> <span class="bio">UI Programmer, JavaScript Enthusiast, Soccer Hooligan</span></li>
   </ul>
</address>

The premise here is that hCard tells you how to parse this markup to get usable information. The adr CSS class tells you what my address is. The fn CSS class tells you what my name is, and so on. So, Get Satisfaction goes and spiders this page behind the scenes and autopopulates your profile with what it can find. Pretty sweet.

Now, they don’t limit you to the services they provide, which are: Flickr, Technorati, Twitter, Upcoming, and last.fm. They provide an Other category for any hCard enabled URL (your personal homepage or perhaps an hResume you have posted on the web).

Integrate with OpenID

However, why not take it to the next level? Why not integrate this microformat functionality WITH an openid login system? You’d be able to kill two birds (not a twitter joke) with one stone in some cases, since both Twitter and Technorati are also OpenID producers (re-echo: We need more consumers).

So, not only do you get the benefits of having OpenID authentication on your website, but you’d be able to prepopulate a certain amount of profile data with an hCard parser. And the best part is, if you already have a nice clean user interface set up to handle different OpenID producers, there wouldn’t be any additional clutter on the interface to get this benefit. It’d be transparent to the user when it works, and fall back to a normal empty profile form when it doesn’t.

What I’d like to see, is more sites that are OpenID producers, also serve hCard microformats as well. If we can get all the major producers on board, we’d have a nice tidy little system going.

Selecting XML Nodes with JavaScript (Peril of getElementsByTagName)

2008-05-10T00:00:00-05:00

There are two popular camps for ajax data formats right now: XML and JSON. Both have their (dis-)advantages. The purpose of this article is to show you how to effectively parse XML in the browser.

Super Fast Beginner’s Primer

Case 1: Node (or un-namespaced node, null-namespaced node): a node without a prefix, such as child here:
<child/>
Case 2: Default namespaced node: a node without a prefix, but a parent node (or itself) has a xmlns attribute, like both root and child here:
<root xmlns="http://example.com/"><child/></root>
Case 3: Namespaced node: a node with a prefix, and a parent node (or itself) declaring a xmlns with that prefix attached, like both child and root here:
<prefix:root prefix:xmlns="http://example.com/"><prefix:child/></root>

/End Primer

Parsing XML in the browser can be a tricky beast. There are many different wrong ways to do it, which can leave you cold and naked in a snowstorm if you’re not careful. So, let’s put on the metaphorical electric one-sie of standards based code and let the power of Edison heat our JavaScript code like the innards of a tauntaun.

If there is one thing you can take away from this article, its that the problems with XML in JavaScript have already been solved, and there is library code out there to do the job for you. But libraries aren’t a substitute for knowledge (abstraction is a dangerous thing during education), so let’s learn why these problems are occurring so we can wrinkle our gray matter and increase our productivity at the same time.

Use Cases

These are the main use cases that takes place when selecting a node inside of an XML document:

Case 1: Selecting un-namespaced nodes (or nodes in the null namespace):
```
<root><child/></root>
```
This one is easy. If you can guarantee that your XML will never have any namespaces, you’re home free. Take your get out of jail free card and run for the hills. Using this assumption, you can query nodes inside of your XML Document object using nothing other than getElementsByTagName(). Lucky bastard.
```
// assume oDocEl is the documentElement inside of an XML Document 
var correctForCase1 = oDocEl.getElementsByTagName('child');
```
Case 2: Selecting default namespaced nodes:
```
<root xmlns="http://example.com/"><child/></root>
```
Tread lightly, this is about to get serious. In most cases, historically I had thought that using the solution described for Case 1 would be sufficient in this case. I had learned awhile back that Internet Explorer treats node names (including namespace prefix and local name together) as one string. So, the method for Case 1 should work for Internet Explorer, especially in the case of node sans prefix. In Firefox, you’d have to use getElementsByTagNS(), but that would be just a simple wrapper.

Then I met an Internet Explorer exception. The only unique thing about this installation of Internet Explorer 7 was that it had MSXML 6 installed, when all the other computers I had tested on were using MSXML 3. The obvious conclusion here is that MSXML 6 won’t select child nodes for Case 2.
```
var incorrectForCase2 = oDocEl.getElementsByTagName('child');
```
Here’s the right way to select nodes for Case 2. Fair warning, to keep the code examples here simple, this solution requires Sarissa (sarissa.js and sarissa_ieemu_xpath.js) to be included on the page prior to usage.
```
// assume oDoc is an XML Document object.
oDoc.setProperty("SelectionNamespaces", "xmlns:whatever='http://example.com/'");
var oDocEl = oDoc.documentElement;
var correctForCase2A = oDocEl.selectNodes('whatever:child');
var correctForCase2B = oDocEl.selectSingleNode('whatever:child');
```
Note how we’ve mapped what was the default namespace (without a prefix) to be a namespace WITH a prefix during the node selection.

It should be noted that when the resultant XML has a namespace attached (Case 2 and 3), Firefox works fine using getElementsByTagNameNS. IE doesn’t include support for that method, however, so we’re forced to find a more complete solution.
Case 3: Select a non-default namespaced node:
```
<root prefix:xmlns="http://example.com/"><prefix:child/></root>
```
As I mentioned in Case 2, normally (pre-MSXML 6), you’d be able to perform a getElementsByTagName('prefix:child') in IE and use getElementsByTagNameNS in Firefox as usual. But that has changed now. We need to set up the SelectionNamespaces property for IE, and we’ll use Sarissa to take it cross-browser for us.
```
// assume oDoc is an XML Document object.
oDoc.setProperty("SelectionNamespaces", "xmlns:whatever='http://example.com/'");
var oDocEl = oDoc.documentElement;
var correctForCase3A = oDocEl.selectNodes('whatever:child');
var correctForCase3B = oDocEl.selectSingleNode('whatever:child');
// Note, this is the same code as Case 2 (which is a good thing)
```
Note that we did not have to use the same prefix that was defined by the result XML. We can map it to whatever we want (literally).

Why is this important?

Because most libraries don’t handle Case 2 and Case 3, which are important parts of XML. Here’s some code straight from YUI 2.5.1 (DataSource component):

// Line 1394
var xmlNode = result.getElementsByTagName(key);
if(xmlNode && xmlNode.item(0) && xmlNode.item(0).firstChild) {
    data = xmlNode.item(0).firstChild.nodeValue;
}
else {
       data = "";
}

Notice how they just do getElementsByTagName. For shame :( jQuery doesn’t handle Case 2 or Case 3 either. (Proof is an exercise to the reader :P) So, if you have XML data sources with namespaces, it would do you well to use the solution presented in this article, or you’re going to have headaches later.

Springer’s Final Word

Don’t use getElementsByTagName. If you do, PLEASE include a note saying that your code isn’t going to support namespaced XML. Branch your selection code to check if Sarissa has been included on the page, and use Sarissa for namespaced XML if it’s there. It’s not fun to be pidgin-holed into the simplest case of XML.

Javascript Objects are NOT JSON

2008-05-09T00:00:00-05:00

The headline should more accurately read “Javascript Objects are not necessarily JSON.” But that waters it down a bit, don’t you think?

I know this has been posted a few times before, but this is not something I knew until recently, and after learning it, have noticed quite a few other people doing it wrong as well. So, to risk adding another reverb to the echo chamber, I’ll post a link to a good explanation by Jesse Skinner on the specifics of the JSON specification.

The main point here is that all object keys and strings in JSON must have double quotes. I encourage you to look through the train track specification to verify for yourself.

If you try to use Captain Crockford’s JSON Parser, it won’t parse your string with single quotes or (un/single)-quoted object keys. His parser has a nice regex checker built-in (and a walker callback to let you parse date strings into Date() objects). It’s a good way to verify that external data, or a data source not under your control, is safe to eval and use in your own code.

Here are a few quick examples:

Valid JSON

{"myKey": "myString"}

Don’t use single quotes. Don’t use unquoted object keys.

Invalid JSON

{myKey: "myString"}
{'myKey': 'myString'}

Credits to Jonathan Snook for the initial write-up and Crockford for formalizing JSON.

Surnamespacing

2008-05-07T00:00:00-05:00

Everyone has a library. Everyone has their own utility classes and functions they’re using in their own personal and contracted projects. And now that everyone has a blog too, they’re all releasing their libraries as open source, using the commando underoo philosophy of wild, free, and unrestricted naming schemes for their code. Not anymore. Let’s surnamespace.

What does surnamespacing give me?

Accountability: Your code is directly linked to your family honor. You’d be surprised how hard people work at test cases and increased code coverage when the respect of their lineage is at stake.
Connect with your Extended Family: Connect with programmers sharing your namespace, your family is now your development team.
Minimize Collisons: The ball and chain associated with an imposed naming scheme means that we won’t have everyone using foo and bar to hold their code, unless you’re the lucky son of a bitch that has inherited that top notch surnamespace real estate.
Faster Initial Development Cycle: Sometimes naming your library is the hardest part. Skip this step and just surnamespace it. Jesus Christ, please show me some examples:

JavaScript Surnamespacing

var Christ = {
    Jesus: {
        walkOn: function(obj) {},
        turn: function(from, to) {},
        respawn: function() {}
    }
};
// Sample Usage
Christ.Jesus.walkOn('water');
Christ.Jesus.turn('water', 'wine');
Christ.Jesus.respawn();

Java Surnamespacing

package Christ;
public class Jesus {
    public void walkOn(String s) {}
    public void turn(String from, String to) {}
    public void respawn() {}
}

PHP 6 Surnamespacing (projected usage)

namespace Christ {
    class Jesus {
        public function walkOn($obj) {}
        public function turn($from, $to) {}
        public function respawn() {}
    }
}

Update: Apparently I can’t write Java code. Don’t tell work.

Don’t Let the Door Hit You Onunload and Onbeforeunload

2008-04-22T00:00:00-05:00

Many people attempt a last ditch effort to save page state in the browser by using the onunload or onbeforeunload events. This has been studied at great length by Patrick Hunlock, who uses the perhaps now common knowledge of using a Synchronous Ajax call to perform the page state save.

Another use for the onbeforeunload event to allow the user to cancel the action that initiated the user leaving in the first place. Gmail uses this technique when the user is in the middle of writing a draft of an e-mail and attempts to leave the page.

Gmail pops up this prompt when the user attempts to leave the page while drafting an email.

Worthy to note, however, is that Opera doesn’t fire the unload event when the browser refreshes the page, or uses the back/forward buttons to browse off of the page (I had no success with the fix posted in the comments on that page). What’s worse, Opera never fires the onbeforeunload event. This creates a serious problem with attempting to save page state prior to a user leaving your page.

Browser support aside, I believe that the onbeforeunload prompt is not an ideal way to protect the user from lost work (or unsaved page state). Humanized has argued, and I agree, that an undo operation is much easier on the end user than a warning message. The strange thing is, Gmail could save the draft in a synchronous Ajax request in the onunload event. They aren’t using the prompt to save Opera users from losing their drafts, since the Opera web browser doesn’t even fire the onbeforeunload event. (Interestingly enough, they are using some sort of browser history management to fire a warning to the user when they press back, or forward, in Opera — but Reload can’t be caught using this method, so your draft email could be lost).

From a User Interface design standpoint, I would recommend just sticking with onunload. You can still perform your synchronous Ajax call in the method to save the state of your page, so that the user can later resume their state or undo the operation. (Except for Back/Forward/Refresh in Opera, until they support a better onunload or any onbeforeunload). The onbeforeunload prompt is an unnecessary evil, and doesn’t do much besides annoy the end user with another warning message and a mouse click.

Rethinking JavaScript Grids and DataTables

2008-04-13T00:00:00-05:00

In the world of front end engineering, one must consider the end-user of the interface first, and above all other things. The priorities should not start with development ease, nor external library preference. The priorities should start with the needs of the consumer of your end product.

Evolution of your engineering skill is also a vital trait in this world, which means that as a developer increases his knowledge of good practices and proper methods, sometimes he must shirk his previous assertions about the world as he previously knew it. And today I’m shirking a staple of the front end as all web users know it: The Grid (DataTable) Component.

Of course, I’ve written a few articles in the past about the YUI DataTable, during my long love affair with Yahoo’s User Interface library. Another popular one is jQuery’s TableSorter. Then there’s the Dojo Grid, a component inherited from TurboAjax. ExtJS has a variety of nice examples as well for their Ext 2.0 Grid.

And after using these Grids and DataTables, I certainly respect the programming that went into developing these components. But let’s take a step back for a second. Why do the users need the bells and whistles in these components? Are they worth the extra load time and complexity they add to the interface?

All we’re doing here is putting a nice coat of paint on a tag. Sure, it might have some nice ancillary features like Ajax Data Loading, but those don’t really matter – they are things that can be easily performed with some good Ajax and DOM insert utility functions. In fact, most of the core features included in these components could be described as feature creep, and not beneficial to the end user at all. Feature creep contributes to code bloat, which means the user is downloading bytes to their web browser that they don’t need, which can hamper performance. Libraries usually have online examples of their components, and the include sizes are seen below. (Gzip compression not considered)

Name	JavaScript Size	Minimized	Link
YUI DataTable	216.6 KB	Minimized	Example
Dojo Grid	338.4 KB	Unminimized	Example
Ext Grid	545.5 KB	Minimized	Example
jQuery TableSorter	66 KB	Minimized	Example

The JavaScript include sizes listed above are directly proportional to the feature set that the components provide, and should give you an idea of the overhead involved with using them. Do we need 545.5 KB of features coming down the pipe to give our users an extra bell, or an extra whistle? Let’s analyze the features to rationalize their usage, and remove items from the feature set.

Sorting
Modifying column order and display
Resizing columns
Editing of row data directly on the grid itself
Scrolling
Pagination

Sorting

Data should be used in the context of its usefulness. You have a list of messages in your e-mail inbox. What’s the most useful context for this list? In order of date received. The default sort order provided by the application, to facilitate proper use of the application. Is comparing the rows in the grid by any other method as useful? Does the user need to see the list of messages ordered alphabetically by subject? In these cases where the user is in need of a specific message, searching and filtering is more useful than sorting. The default sort is useful, but allowing the user to resort on the client, in most cases, is not as useful as other methods of finding a row.

Modifying column order and display

The same argument can be made for any of the other methods of customization provided to the end user. Does the user need to reorder or hide columns? The context provided by the application should be sufficient to use the applications data in the way it was intended. Don’t overcomplicate your user interface with needless features or a deluge of useless data. Provide succinct, appropriate data, and the user needn’t reorder or change the interface.

Resizing columns

The default HTML tag expands to fit the data inside of its cells. Even when you set the width of the table explicitly, the cells adjust themselves accordingly to fit the data. This should be the behavior of your table. You needn’t monkey around with widths, the browser is smart enough to do it for you. You can even customize a cell to wrap its text to multiple lines with CSS, if need be.

Editing of row data directly on the grid itself

If you’re providing an Excel spreadsheet interface for the end user to customize your data, you haven’t designed your interface correctly. Rethink how the user needs to interact with the data you’ve provided, and give them a better, simpler way to edit the data.

Scrolling

Everyone knows that internal scrollbars on a page are evil. I don’t even like scrollbars on textareas, to be honest. Previously, I had worked and reworked the YUI DataTable to handle horizontal scrolling. Looking back on this, it was a mistake. There are better ways to handle lots of data in a table, without the heavy mouse interaction and scanning that scrolling require. Which brings me to my next point.

Pagination

This is the one exception to the feature set cutting board. This is the one feature that’s is a requirement, when the data set has too many records to fit on a single page.

Keep these in mind, and look at the feature set provided by a few sites using tabular data centric interfaces that know a thing or two about interface design:

Examples

Google Mail

WordPress Admin

Google Reader

So, what should we include?

A simple CSS class to style your table is sufficient, with links to paginate the table (properly) and/or a hover for row selection if needed. You’re looking at 10-20 lines of jQuery code, maximum, and a few CSS declarations. In lieu of sorting, of course, you’ll need to program in a mechanism for searching and filtering as well. But really, the difficulty with programming this component is knowing what to leave out.

ALARMd 2 Beta, with Google Calendar Integration

2008-04-06T00:00:00-05:00

Take a look: ALARMd 2 Beta

Update: added Metric and Unit Circle time formats.

I know, some of you are reading this and thinking to yourself — genital herpes is more appealing than yet another online alarm clock. But to that I say, congratulations, that’s one of the new features in ALARMd 2!

Why did I make another online alarm clock? Mostly due to missing features and limitations in the old version, but also because it’s a good exercise in JavaScript programming and User Interface design. Everyone likes to hone their skills, and this is my publicly viewable work desk. But the real reason I went back to rewrite the old version is that I’m hooked on jQuery. I can’t get enough of that sweet, sweet, source code, and couldn’t stand to see my old, crusty, handwritten DOM manipulations polluting web browsers across the world. Users of the Yahoo User Interface Library (what I used for the original version of ALARMd) would do well to consider jQuery a nice plugin to be used alongside YUI. It will clean up your code MAX_INT-fold.

Here are a few new features and addressed limitations in ALARMd 2.

Easy Alarm Mode: No more fumbling around when you just want one simple easy-to-add alarm.
Google Calendar Alarm Mode: Customize your alarm schedule to your heart’s content, it will load your alarms straight from a publicly available Google Calendar. There are some great features with this:
- Load only the first calendar event of every day
- Day Limiter (Example: Only load calendar events within the next 3 days)
- Minute Adjuster (Example: Alarm me 90 minutes before work without adding a separate event)
- Google does a nice job of normalizing dates as well, so you don’t have to worry about calendar time syncing. If it says 8AM on your calendar, it’s going to alarm you at 8AM on your computer’s local time.
New Clock Formats:
- Human Readable Clock Format: Think “Half Past Two”, or “Quarter Til Twelve”. This idea is from Laurence Willmott’s Project “It’s about Time”. I took some liberties with his labeling scheme, I hope he doesn’t mind too much.
- Metric Time Format: Shows the measurement Centi-days in Local Metric Time. Basically, it’s a percentage of much of the day has passed. If it’s 80.000, 80 percent of the day has passed, which coincides with 7:12 PM.
- Unit Circle Time Format: Displays the time in radians that would be shown if a clock were pasted on top of a unit circle. If it’s 12 o’clock, it will read π/2. After programming this one, it’s starting to seem normal in my brain. Oh, it’s 3π/2? Time to eat dinner. How the hell did it get 2π/3??
Human Readable Alarm Dates: Think “29 Minutes”, “1 Hour”, “2 Days Ago”.
Much cleaner interface, using a jQuery accordion to display the options.
The old ALARMd required an internet connection for all sources, and provided no safeguard if your internet went down whilst you were sleeping. ALARMd 2 preloads all Youtube videos in the background when the page loads using the new Youtube JavaScript API. A nice benefit of this is that the browser window no longer requires focus to play the YouTube video.
Less clunky interface for adding new alarm sources.
Repeat option for YouTube videos and MP3′s. Turn infinite loop on or off. Careful with this one. Don’t leave ALARMd going if you’re not going to be home when it goes off.
CSS Skins, Use the really simple ones I’ve included for Red, Green, or Blue, or include your own URL to your own hosted CSS file. Have a good skin? I’ll include it in the select list and give you some props here, just link to it in the comments below. Use some CSS class hooks to spice up your skins (they are mutually exclusive). These are CSS classes that are added to the body tag to allow you to style the alarm differently depending on the alarm clock’s current state. Future enhancements might include more than just alarm-based hooks: Year, day of the year, and hour of the day might be useful, that way you could style the clock to show a lighter background during the day and a darker background at night.
- .alarmWithin30Minutes
- .alarmWithin15Minutes
- .alarmWithin5Minutes
- .alarmWithin1Minute
- .alarmActive (Alarm is being played)
Still has all the old favorites:
- Test Button to make sure the video or source is working and to check your volume.
- Count Down mode to show the time between now and the first alarm.
- Store your own list of alarm sources, using YouTube, MP3, Last.FM, or any URL (Pandora is included).
- Military time (24 hour clock) and seconds toggle.
- Naked mode (get rid of the extras)

Finished reading? I’m surprised you didn’t click the link at the top: ALARMd 2 Beta

Remember, this is BETA. That means it’s new. I’ve done my best to test and code out all the kinks, but there may be a few that slipped through. Try it out and please report any bugs. And once again, this code is released under the BSD license.

I’ll probably move this to the main ALARMd.com domain shortly.

Alarmd has been personally tested with Firefox 2, Firefox 3, Internet Explorer 7, Safari 3.1, and Opera 9.27, all on Windows. Google GDATA reports an unsupported browser error on Safari and Opera, which you can hide using custom CSS.

20000 Leagues Under the API: YouTube JavaScript

2008-04-05T00:00:00-05:00

Today, children, we’ll be exploring the wonderful world of the official JavaScript API published by YouTube a few weeks ago. I read a few interesting posts on the subject when it first came out, and it’s been on my list of things to explore for the next (and hopefully last) version of Alarmd. This isn’t going to be a long post so much as a laundry list of points worth mentioning and limitations there-of regarding the API itself.

If you want to change videos dynamically by loading a new video into an existing player, you must use the Chromeless player (which requires an API key). The loadVideoById() method is only available in the Chromeless player. Whatever you do, don’t try to dynamically destroy and create a new player, this will cause JavaScript errors in Internet Explorer (although not Firefox).
CSS properties: When the player has the css display: none applied, it will not play. When the css visibility: hidden is applied, the video will still play, but will not be shown on the screen. If you wanted a headless player, like what the music search engine Songza does, you’d want to take this approach. Word of warning, there’s some tricky shit going on when you try to dynamically change these properties on a player and run commands on the player at the same time (or close to the same). For instance, I got into a sticky situation where I’d try to show the player and load a new video into the player in the same method. I had to separate these with a timeout to get both to run without error.
To load, you must play. Unfortunately, I wanted to pre-load the video without actually playing the video. This is unsupported. To handle this, I had to play, then pause after a timeout (using window.setTimeout). Not the prettiest, but it seems to work. Obviously the API in this case has very low cohesion, as the loadVideoById method ALSO plays the video, not simply doing ONLY what the method name suggests.
Forcing a global? When the player first loads after you’ve used the SWFObject embedSWF() command, it will call the function onYouTubePlayerReady(), which you can’t customize. It must be that function name, and it must be in the global namespace. Keep in mind that onYouTubePlayerReady() is called every time the player is shown (when it was otherwise hidden using the css display: none)

Unfortunately, there is some voodoo going on here that I don’t fully understand. I’m not a flash guru, nor have I ever claimed to be. But there have been a few bugs in my experience with the API that have led me to believe that it’s not quite there yet. Maybe my use cases were a bit unique, but they weren’t that extreme. I should be able to hide and show the player without error. I should be able to destroy the player without error. I should be able to load a video without playing it.

But hey, it works.

Code Like the Big Boys: Flickr

2008-03-30T00:00:00-05:00

Code like the Big Boys is a series of posts about code solutions used by major websites. What can we learn from these professional websites to use in our own code?

JavaScript

Looking at the source code of the Flickr home page is actually pretty strange. For one, there is only one JavaScript source code file (other than the advertising scripts), a solution for PNG Alpha Transparency in Internet Explorer, included as an HTML Component. The source for the PNG Behavior script (credit to Erik Arvidsson) is unchanged, with the exception of the removal of some extraneous comments, but curiously enough no whitespace removed (a suggestion to save them a few bucks in bandwidth). Looking at their HTML source, they seem to emphasize whitespace and readability over bandwidth savings, which seems fine to me. At least their visitors (you and I) can more easily learn something from their code.

CSS
They’ve taken the same route as one of the tips from Jonathan Snook, and declared all styles for an element on a single line. They use your standard css to reset to a base starting point, much like YUI’s Reset CSS we’re all familiar with. One interesting declaration I noticed prominently inside of their CSS was the .Butt css class, declared on their primary Search form button. I’m curious to know the semantic meaning behind that one.

They use the tan hack as well to isolate a CSS declaration for IE browsers:

* html #featured-image cite {bottom: -1px;}

This is to workaround for an IE limitation to absolutely positioning content at the bottom of a relatively positioned div, in this case the black box containing the credits (or citation, hence the cite tag) inside of the feature image.

Another interesting CSS Hack they’ve employed involves the line-height for tags containing Unicode characters to select different languages. It starts out like Dustin Diaz’s min-height hack, but throws a loop.

height: 0px !important;
height /**/:13px;

I’m not familiar with the /**/ syntax, and would really appreciate any information someone has on what platform this is targeting. A comment would be nice!

Editors Note (2013): The /**/ syntax is to target everything but IE6.

HTML

Standard here, and they have some nice meta tags for the I-phone:

<meta name="viewport" content="width=950" />

All in all, it’s short and sweet code for a home page. It’s nice to see such clean code with an eye towards standards on a commercially successful site, many props to their programmers. I’m scared to do my next in the series, because I’m 100% sure it won’t be as nice of a read as Flickr was.

Tips for Programming JavaScript Functions

2008-03-28T00:00:00-05:00

This article is about my personal coding style, given little tips and tricks that I use to make my code cleaner and more readable.

Required and Optional Arguments

There are generally two styles used when programming a new function in JavaScript. The first, most obvious, and least extensible method is putting each argument as its own argument in the function definition, as so:

// For our purposes, assume arg1 is required, and arg2 and arg3 are optional.
function myFunction(arg1, arg2, arg3) {
   arg2 = arg2 || 'defaultValue';
   arg3 = arg3 || 'defaultValue';
}

One obvious downside to this method is that it requires a line of code for each optional argument to define a default value. What if you want to pass in an arg3, but not an arg2? Your call could end up like: myFunction('myArg1', null, 'myArg3');. This might work in the beginning, but what about when you have more than 3 arguments defined? That’s going to get messier than a Dick Cheney hunting party.

The next method people generally move to when they have a lot of optional arguments in their function definition is to put all the arguments into a single object argument, like the following:

// taken from jQuery
 $.ajax({
   type: "POST",
   url: "some.php",
   data: "name=John&location=Boston",
   success: function(msg){}
 });

The benefit to this method is that you can populate all the defaults easily by using jQuery.extend, like so:

// simulated code, not from jQuery
$.ajax = function(args)
{
    var defaultArgs = {
        type: 'GET',
        data: '',
        dataType: 'text'
    };
    // overwrites defaultArgs with args values, stores result into args.
    args = jQuery.extend({}, defaultArgs, args);
    if(!args['url']) {
          return;
    }
};

The args object would end up with the following value:

{
   type: "POST",
   url: "some.php",
   data: "name=John&location=Boston",
   success: function(msg){},
   dataType: 'text'
}

This method can be easily seen as extensible. You could put a metric shit ton of optional arguments in your function (the option is there, I won’t judge you), and you could define them in any order inside of the object without having to put in null spacers like the previous method.

But what about required arguments? The Ajax method above requires a URL, and the script can’t guess a default for that variable. But it isn’t immediately obvious to the end-user that URL is always required. And what’s more, you’ll have to put specific code inside your function to check that the required arguments were sent in the object. (Think if(!args['url']) { return; } as shown two code blocks up.)

Which leads me to my favorite way to define functions: a combination of the two methods. Declare your required arguments as explicit arguments, and pile the rest into an optional arguments object. Here I’ll show you how I would define the Ajax function using this method:

// jQuery doesn't use this argument structure, so don't copy and paste this.
 $.ajax('some.php', {
   type: "POST",
   data: "name=John&location=Boston",
   success: function(msg){}
 });

This way, it is immediately obvious which is a required argument and which is optional, and your required arguments will never be accidentally assigned a default value in your code. If the end-user doesn’t send in all of the required arguments, the resulting error message will be obvious and easily fixed, without a ton of code inside of your function to check that the end-user obeyed the function defintion.

Setting Default Values for Optional Arguments

When developing code, sometimes it is obvious that the method described above for optional arguments may be overkill for a tiny little utility method. Sometimes you just want a boolean flag, or a single optional argument. When that occassion arrives, it’s time to put on your robe and coding hat, because we’re going to town.

In the beginning of JavaScript maturity, my <body> was going through a lot of changes. I was confused about a lot of things, and you’d see a lot of lines of code like this (embarrassingly enough):

function myFunction(runDoSomething)
{
     if(runDoSomething == null) {
          // never make your default true, as I'll show you below
          runDoSomething = true;
     }
     if(runDoSomething) {
          doSomething();
     }
}

Ugh, checking against null? Janet Reno looked better in the morning. But now that I’m a full grown man that can open his own pickle jars, I’ve got some guidelines:

When the argument is optional and might be left out, define it in your code in such a way that if it does have a value, it will not evaluate to boolean false (0, false, undefined, null, ”, NaN). In other words, don’t make the value the user passes in for this argument be false. False is the value it should have when it’s empty. See the example below:
```
// runDoSomething is still optional
function myFunction(runDoSomething)
{
     if(runDoSomething) {
          doSomething();
     }
}
```
We didn’t have to assign a default value to arg1, because if it’s null, then doSomething() won’t execute. Don’t ever use arg1 in a way that would have you passing in false, because false and null are the same in a boolean comparison.
When using non-boolean optional arguments, another way to avoid assigning a default value to an optional argument is to use the OR operator to give you a default value where you’re using it. This is really only useful when you use the argument in one single place inside of your function. If you’re using it more than once, it’s best to define the default value at the top of the function.
```
 function myFunction(arg1)
 {
      // arg1 is used only once
      jQuery('#myId').html(arg1 || 'myDefaultValue');
 }
 function myFunction(arg1)
 {
      arg1 = arg1 || 'myDefaultValue;
      // arg1 is used multiple times
      jQuery('#myId').html(arg1);
      jQuery('#myOtherId').html(arg1);
 }
```

Hopefully you’ve learned something from this post. It is the byproduct of many mistakes and overcomplicated functions that I’ve refactored to end up with this result.

Architecture Choices: Callbacks and Events in JavaScript

2008-03-28T00:00:00-05:00

Warning: Blog Post written for Beginner and Intermediate JavaScript Developers

Like any well intentioned programmer, you’re writing reusable code in JavaScript. Maybe it’s a simple widget, maybe it’s a higher level plug-in for your favorite JavaScript library. But now you want to provide a mechanism for your friendly neighborhood developer to extend your code by hooking into it with a little bit of code of their own. How do you accomplish this?

Generally, it can be done one of two ways:

A callback function
A custom event

A callback function is a function passed into your code as an argument that will be executed at the time the library code specifies. For instance, callback functions are usually supplied for for Ajax XmlHttpRequest’s to execute, one callback if the Ajax Request is successful, and another on failure. See the following code as an example:

End-Developer’s Code:

 $.ajax({
   type: "POST",
   url: "some.php",
   data: "name=John&location=Boston",
   success: function(msg){
     alert( "Data Saved: " + msg );
   }
 });

Library Code (from jQuery):

// taken out of context, just know that s stands for the options object passed into $.ajax() above.
if ( s.success )
  s.success( data, status );

In the above code example taken straight from the jQuery documentation, the success key of the object being passed into the ajax() function is a callback function. It will be executed after the Ajax request has successfully completed.

The other mechanism you can use for controlling dependent function execution is a custom event. Custom events provide more flexability because they use the publish/subscribe mechanism. That means, instead of the library author deciding how many callbacks he or she is going to allow you to pass into their method as arguments, he or she will just trigger a custom event, which will fire all functions the end-developer has said they want to subscribe to that event. See the following example from the jQuery documentation.

End-Developer’s Code:

$(document).bind("myCustomEvent", function(e, msg){
   alert( "Data Saved: " + msg );
});
$(document).bind("myCustomEvent", function(e, msg){
   alert( "More Data Saved: " + msg );
});
// We can subscribe as many functions as we want to myCustomEvent.

Library Code:

// again, no context here
$(document).trigger("myCustomEvent", [ "My Message" ]);

As you can see above, custom events are much more extensible and customizable to your needs. Want to attach 10 functions to myCustomEvent? Sure, go right ahead. Want to try to attach 10 callbacks to the ajax success method above, that’s going to be a bit more work. The benefit to using callbacks lies in their disposability and isolation. Perhaps you don’t want to publish to the world when your Ajax Request completes — maybe you just want to handle the completion and be done with it.

Let’s Review.

Callback Functions: Private Disposable – Limited by Design of Parent Code (Number of callbacks)
Custom Events: Extensible (Any number of functions attached) – Public – Not Disposable (Functions stay attached after execution, and continue to fire when triggered)

Yet Another Pretty Date JavaScript

2008-03-23T00:00:00-05:00

I can’t let this Pretty Date thing go. I decided to use a modification of John Resig’s Pretty Date JavaScript implementation written by Dean Landolt and shared in the comments on John’s page. The script was an obvious choice for the next iteration of Alarmd, which is nearing completion as I type.

The more I used Dean Landolt’s script, the more problems I began to see with his implementation. It was a good start, but definitely had bugs. His assumptions translating from integer second differences to human readable labels stretched too far at times (there is an error in logic to say anything between 24 hours and 48 hours from now can be labeled “Tomorrow”), and he was a bit loose with his difference categories (assumed average month length was 28 days, and always used Math.floor instead of rounding — 47 hours from now would be labeled “1 Day”). It was great code otherwise, and I definitely liked the way he used the while loop to run through the comparisons.

So, I’ve cleaned up his great start, and am releasing it to the world in the spirit of cooperation and open sauce. You just read that typo out loud didn’t you?

Download: Yet Another Pretty Date Implementation (2 KB)

Update: Dates for this script must have a specific ISO8601 format: YYYY-MM-DDTHH:MM:SSZ (in UTC) where T and Z are literals.

Update: This script has been moved to Github.

Minor Annoyances with Firefox Development

2008-03-23T00:00:00-05:00

When you’re developing web applications in Firefox, do you find yourself constantly clearing your cache? Cache is a useful facet of web browsing for everything but the continuous testing environment of web development. Here’s a nice alternative so that you don’t have to disable your cache entirely:

Use the Firefox Plug-In called (humorously enough) JohnnyCache. I added the pattern ‘http://localhost/’ to my preferences and now I don’t have to worry about cache on my local machine anymore. Simple, easy, effective.

Now only if I knew how to disable the Firefox preference that autopopulates form fields with default values when F5 is hit to refresh the page. Try creating a page with a single text field, type a value into the form, and then hit F5 to refresh the page. Your value will be prefilled into the form.

I find myself always hitting “CTRL L” (goes to the Location Bar) and “Enter” to avoid that one. I looked through about:config, but only found: signon.prefillForms (related to usernames and passwords), and browser.formfill.enable (related to autocomplete dropdowns for forms, not default values).

Anyone know an easier method?

Specific Inheritance with TIBCO’s General Interface

2008-03-03T00:00:00-06:00

Sorry about the title, I couldn’t resist.

TIBCO created the General Interface (GI) toolkit for one-page in-browser applications back before I was in my JavaScript diapers. I hadn’t even graduated from high school yet when they were building Rich Internet Applications using some of the most feature crippled browsers in Internet history, back when cross browser meant Internet Explorer and Netscape Navigator, not the Firefox/WebKit/Opera’s of today. But when I did finally start to get my feet wet in the world of JavaScript, this is the tool I started on. I learned what a DOM was, earned my stripes in XSL, and discovered the power of the browser.

But just like any programmer nearing the end of their relationship with a tool, I must take a few moments to evaluate my experiences with it, not only for my benefit, but so that you, the reader, might also gain a golden nugget of wisdom from the treasure troves of its sparkling source code.

When I first started using General Interface almost two years ago (~June 2006) on version 3.1, it wasn’t a cross browser tool. It had support for Internet Explorer 6, and that was it. Truthfully, it was an executive decision to use the tool, and we were using it for an intranet application. Looking back on that decision raises a huge red flag now — internally supported web browsers are subject to change, and so are audiences — applications may turn out to be more external that previously suggested. And while Firefox support was included with version 3.2, to this day I hear complaints that the application doesn’t work on the Safari browser (or, in turn, the iPhone).

General Interface relies heavily on a JavaScript XSLT interface (this is why they won’t ever have support for Safari 2, or the iPhone, neither of which support a JavaScript XSLT interface), leveraging XSLT stylesheets to generate markup for the page, which turns out to be quite the speed demon when generating large amounts of markup from XML documents (or GUI components serialized into XML documents). However, a large chunk of that speediness is lost due to a heavy reliance on inline CSS. A majority of the style associated with components is generated on the fly and inserted inline using the browser native style attribute. This can cause a lot of problems when attempting to do a simple restyling of a GUI component using CSS. For example, in a DataTable/Grid component, there is no option to style the background-color of a selected row. The only option for the style of a selected row is a background-image, which I believe resulted from the inline style limitation and the background color already being specified for zebra-stripe row coloring. If you specified the background-color for the selected row, it wouldn’t know which background-color to go back to when the row was unselected, due to an unfortunate avoidance of the CSS class construct.

Another drawback to General Interface is development of the GUI. I won’t get into it too much, but will just meantion that to create interfaces in GI, you must create your GUI components and layouts using the an in-browser IDE developed using the power of dog food. That’s right, it’s written in GI itself.

However, General Interface has got it right in some cases. They were (I believe) the first JavaScript library/toolkit to include a mechanism for large result set DataTables/Grids. In fact, their Matrix component (the equivalent of a YUI DataTable, or a Dojo Grid) supports more features that most libraries have even begun to plan for: complete inline editing with great keyboard navigation support, clientside sorting, column reordering, dynamic column hiding and adding, hierarchical tree grids, easy options for pagination caching, as well as 4 different rendering modes (the latest YUI DataTable 2.5.0 just added their first rendering mode, what GI calls “Chunked” rendering). They were the first toolkit to include a very sophisticated client side charting package, with support for more charting types than you’d even want to put into a single demo. They’ve been developing the package with a clearly object oriented methodology in mind, and that can be easily seen in their source code. They have taken the package open source and released it with a BSD license (which is a delight of course, muddling through that obfuscated source the first year was a pain).

If nothing else, TIBCO is a company with some great ideas, and you can see those ideas represented in General Interface. This tool has shaped a lot of my views on clientside development, and I’ve learned a lot from its developers. For instance, I feel like XSLT is one of the most underrated tools for speed improvements in clientside DOM manipulation (using innerHTML to insert the result of an XSL transform), especially with Safari 3 including a JavaScript XSLT interface. If you’re developing an application that deals a lot with XML web services (SOA) and you want to create a single-page in-browser application (RIA), why not give it a look? Just keep those caveats I’ve meantioned in mind and you’ll be fine. Trying something new can change your perspective, and if you keep an open mind, you might learn something.

PHP Pretty Date

2008-02-10T00:00:00-06:00

This class is pretty much a direct port of John Resig’s JavaScript Pretty Date to PHP 5. A few notes:

Requires PHP >= 5.10, due to the usage of PHP’s new DateTimeclass.
The new DateTime object parses strings using PHP’s strtotime, so you don’t need to pass in an ISO8601 formatted date, as in JavaScript Pretty Date. Try “now”, or “next Wednesday”, or “ 2 weeks 4 days 23 hours 9 seconds”.
Extended to handle Months and Years in the past (JavaScript version only goes to weeks)

Usage:

// pass in a String DateTime, compared to another String DateTime (defaults to now)
$myString = Date_Difference::getStringResolved('-7 weeks');
$myString = Date_Difference::getStringResolved('-7 weeks', '+1 week');

// pass in a DateTime object, compared to another DateTime object (defaults to now)
// useful with the Propel ORM, which uses DateTime objects internally.
$myString = Date_Difference::getString(new DateTime('-7 weeks'));
$myString = Date_Difference::getString(new DateTime('-7 weeks'), new DateTime('+1 week'));

Download PHP Pretty Date (PHP 5.10 , 1.86KB)

http://www.zachleat.com/Projects/phpPrettyDate/Date_Difference.phps

Quine using XHTML and JavaScript

2007-12-28T00:00:00-06:00

Programming Hilarity! He has a generator, and a pre-generated example. Wait, what’s a quine, you say?

In computing, a quine is a program, a form of metaprogram, that produces its complete source code as its only output.

– Courtesy of Wikipedia: Quine (computing)

Faster YUI DataTable with 5 Lines of Code

2007-12-27T00:00:00-06:00

Holy Reflows Batman! The typical usage of a DataTable in the Yahoo User Interface JavaScript library involves passing a string into the constructor signifying the ID attribute of the container you want to attach the DataTable to. However, the YUI DataTable loves the DOM and creating nodes individually using DOM methods. Normally that’d be fine, but one of the first things it does in the constructor is create the table element and attach it to the live DOM. This is a no-no. Now, every time they append a new node (for a new row or a new cell inside of a row), it causes a reflow in the browser! What does this mean? Really bad lag when you insert 40 or 50 rows. Recognize this piece of code?

var myDataTable = new YAHOO.widget.DataTable("myContainer", myColumnDefs, myDataSource);

Straight from the docs. No no no!

Instead, you should pass in an unattached DOM node instead of a string!

Try this code on for size:

var myDataTable = new YAHOO.widget.DataTable(document.createElement('div'), myColumnDefs, myDataSource); 
myDataTable.subscribe('initEvent',function() {
    // CHANGE THIS -- match the id of the container you want.
    var d = document.getElementById('myContainer');
    // remove previous DataTables
    while(d.firstChild) { d.removeChild(d.firstChild); };
    d.appendChild(this._elContainer); });
}

enterval, an automatic setInterval chainer.

2007-12-23T00:00:00-06:00

Hello internet. Today we’ll be exploring the magical wonders of setInterval. Have you ever worked on a project that needed multiple timers going simultaneously? Have you ever wanted to bind all of those timer callbacks into just one timer without restructuring your code manually? Well, being the Curious George that I am, I wanted to know the performance benefits of the grouping callbacks and eliminating unnecessary timers. Here’s the code I used to do it:

Instead of:

window.setInterval(function(){ /* Payload! */ }, 100);
window.setInterval(function(){ /* Payload! */ }, 100);
window.setInterval(function(){ /* Payload! */ }, 100); 
// results in three separate timers.

You can do:

enterval.set(function(){ /*Payload */ }, 100);
enterval.set(function(){ /*Payload */ }, 100); // combines with the first 100ms interval.
enterval.set(function(){ /*Payload */ }, 100); // combines with the first two 100ms intervals.
// results in one timer, containing all three callbacks.

Here’s the code:

var enterval = (function()
{
    var intervals   = {};

    function add(callback, interval)
    {
        var index = 0;
        if(intervals[interval]) {
            index = intervals[interval].length;
            intervals[interval].push(callback);
        } else {
            intervals[interval] = [callback];
            window.setTimeout(call, interval, interval);
        }
        return interval+':'+index;
    }

    function call(interval)
    {
        var d = intervals[interval];
        for(var j=0,k=d.length;j<k ;j++) {
            if(typeof d[j] == 'function' && d[j]() === false) return;
        }
        window.setTimeout(call, interval, interval);
    }

    return {
        set: function(callback, interval, data)
        {
            return add(callback, interval, data);
        },
        clear: function(id)
        {
            var s = id.split(':');
            delete intervals[s[0]][s[1]];
        }
    };
})();

Unfortunately, in the limited benchmarks that I performed, it didn’t seem to operate all that much differently from recursive setTimeout calls, even with (10ms, 100ms, or 1000ms) intervals and (50, 100, 1000) timers (with the payload doing nothing other than creating a date for benchmarking purposes. This code does get around the oddly performing setInterval inside of a loop bug. There may be some other benefit in ordering the interval callbacks after assignment, but I haven’t included that in the functionality above. Feel free if you wish.

Obscurity, Security, and Captcha

2007-11-01T00:00:00-05:00

On Ajaxian recently, there have been a few posts touting new and inventive replacements for the more traditional distorted and discolored “What does this image say?” Captcha gatekeeper for your web form. Of course these are all intended to provide a mechanism to tell the difference between an automated web bot that is spamming your web form and a human being.

Obviously there are some accessibility issues with Captcha images, in that they are useless to those that are vision impaired. Some sites provide an alternate link to an audio file that speaks a random word that you must then enter into the form.

One of the easiest ways to implement a Captcha on your site is to use the reCAPTCHA plugin. But that’s not what I’m going to talk about here. What I want to talk about is these new methods being introduced.

The first that was recently linked was a method that involved drag and drop to authenticate the user. Obviously this method is flawed, especially if the automated robot has access to fire JavaScript events. It does nothing but introduce a different door that the spammer may not have seen before. When this method gains any sort of popularity, or if a spammer decides to attack the site implementing this method specifically, it would not be difficult to bypass the Captcha. This is referred to in the computer world as “Security through Obscurity“. This is not good practice.

The next post I read was regarding an implementation that presented the user with 8 boxes, with one of those boxes colored differently with an invitation to find and click on the differently colored box. The was implemented by Passpack (a password hosting service — should be focused on security, right?). Correctly me if I’m wrong, but how is this difficult for the Spammer at all? The whole point of a Captcha is to distort the text inside the image so much that the image can’t be read by an Optical Character Recognition (OCR) program. Basically, they’ve simplified it down to a one pixel image, which is an infinitely easier optical recognition problem. You don’t even have to recognize characters, you can just see if the pixel is a 1 or a 0. Forgive me for asking, but is that problem NP complete?

I am all for having more friendly humane methods of Spam Bot detection. Just be wary of the methods you’re using. Are they actually secure, or are they just obscure?

Forward Compatibility and JavaScript

2007-11-01T00:00:00-05:00

Many developers (myself included) complain endlessly about the problematic ECMAScript implementation that Internet Explorer uses called JScript. And after reading one such very detailed complaint in the comments on Dave Massy’s website at MSDN, and reading Chris Wilson’s post about ECMAScript 3, it has become increasingly obvious of Microsoft’s opinion on the subject of Forward Compatibility with JavaScript. It’s something they keep pounding their fists on the ground about, how they are adamant that new versions of their browser not “Break the Web.”

Of course, “Breaking the Web” refers to the amount of code on the internet today that is an equal and opposite reaction to the broken bug-ridden JavaScript implementation of their browser. It describes the unimaginable future in which Internet Explorer fixed the many well documented intricacies of JScript and thereby ruins the code that was originally written to support the problem. What a conundrum.

But haven’t we already been through this problem? Isn’t this the same exact thing we saw in the early days of CSS? And how did the major browser players react? By implementing both a Quirks and Standards mode for CSS through DocType switching. Now my question is:

Why haven’t we seen a Quirks and Standards Compatibility Mode for JavaScript?

I’m not necessarily encouraging the Quirks and Standards modes to be toggled with the DocType (as with CSS), but why not have these two modes? To enable your site to use the Standards mode of JavaScript, the browser might require a certain DocType to be declared, or it might require a different script type in the browser:

<script type="text/javascript" mode="standards">

Either that, or I could just use Base2.

Nursery Rhyme Code Poem [CSS]

2007-10-27T00:00:00-05:00

Code Poems are fun! The trick is to take a nursery rhyme (but really, it could be any commonplace work of writing – Famous Speeches, Bible Verses, Famous Quotes, etc.), and then turn it into pseudocode. The code must follow both the programming or markup language you’re using and the rhyme as closely as possible. See how precise you can make your rhyme fit. I accept critiques and suggestions for improving me rhyme code (or you could just rewrite my rhyme as you see fit).

#theChurch {}
#theChurch #theSteeple {}
#theChurch .door[state="open"] .people { visibility: visible; }
#theChurch #theParson { display: none; }
#theChurch > .upstairs #theParson:active { display: block; }
#theChurch #theParson:lang(prayers) { display: block; }

The above code poem is released under the BSD license. To use in production environment without error, do not include an element with an id attribute of “theChurch”. Obviously I’m kidding, don’t use this code. Not even for enterprise software.

Nursery Rhyme Code Poem [PHP]

2007-10-26T00:00:00-05:00

<?php
class I {
    public __construct()
    {
        $star = new Star();
        $star->size = 'little';
        $star->twinkle();
        $star->twinkle();

        self::wonder($star, 'What are you?');

        $world = new World();
        $world->elevation = 'So High';
        $star->setAbove($world);

        $d = new Diamond();
        $d->position = 'In the sky';
        $star->setLike($d);

        $star->twinkle();
        $star->twinkle();
        $star->size; // returns 'little'

        self::wonder($star, 'What are you?');
    }

    public static function wonder($obj, $query)
    {
        $obj->query($query);
    }
}

The above code poem is released under the BSD license. To use in production environment without error, please precede with the following command: error_reporting(0); Obviously I’m kidding, don’t use this code. Not even for enterprise software.

Nursery Rhyme Code Poem [JavaScript]

2007-10-26T00:00:00-05:00

(function()
{
    function BlindMouse() {}
    BlindMouse.prototype.tail = true;
    BlindMouse.prototype.run = function(after) {};

    function Mice(mouse1, mouse2, mouse3)
    {
        this.mice = [];
        this.mice.push(mouse1, mouse2, mouse3);
        this.declare = function()
        {
            return this.mice.length + ' Blind Mice';
        };
        this.run = function(after)
        {
            for(var j=0,k=this.mice.length;j<k ;j++) {
                this.mice[j].run(after);
            }
        };
        this.cutOff = function(prop, weapon)
        {
            for(var j=0,k=this.mice.length;j<k;j++) {
                this.mice[j][prop] = false;
            }
        };
    }

    var mice = new Mice(new BlindMouse(), new BlindMouse(), new BlindMouse());
    alert(mice.declare());
    alert(mice.declare());

    function seeHow(they, func)
    {
        they[func]();
    }

    seeHow(mice, 'run');
    seeHow(mice, 'run');

    var farmersWife = function()
    {
        var weapon = 'Carving Knife';
        return {
            cutOff: function(creatures, prop)
            {
                creatures.cutOff('tail', weapon);
            }
        }
    }();

    mice.run(farmersWife);

    farmersWife.cutOff(mice, 'tail');

    function haveYouSeen(obj, timeSpan)
    {
        return true;
    }

    if(haveYouSeen('Such a Thing', 'Your Life')) {
        alert('as ' + mice.declare() + '?');
    }
}());

The above code poem is released under the BSD license. To use in production environment without error, please enclose with a try-catch block. Obviously I’m kidding, don’t use this code. Not even for enterprise software.

Namespacing outside of the YAHOO Namespace

2007-08-28T00:00:00-05:00

YAHOO.namespace(). A lovely little utility function subject that I’ve written about before. If you’ve never heard of YAHOO.namespace or aren’t even familiar with namespacing, I’d read that article first.

I’ll be honest, using the YAHOO namespace to store my own code makes my bunghole tighten just a little bit. What if I had written code stored under YAHOO.tool, which was unused prior to YUI 2.3.0? What would I do now? I’d have to rewrite my code, or never include any of the wonderful YAHOO.tool.TestCase, put together by Nicholas Zakas. As is traditional with most of my weblog posts, I try not to just complain about a problem without giving you a solution (but let’s be honest, only if it doesn’t take too much work).

Let’s rewrite the YAHOO.namespace function to work outside of the YAHOO Namespace, so we can do things like this:

namespace( 'zachsWorld.partyTime' );
zachsWorld.partyTime = function() {
  alert( 'Excellent.' );
}
zachsWorld.partyTime(); // obviously would alert: Excellent.

Here’s some code:

function namespace() {
    var a=arguments, o=null, i, j, d;
    for (i=0; i<a.length; i=i+1) {
        d=a[i].split(".");
        o=window;
        for (j=0; j<d.length; j=j+1) {
            o[d[j]]=o[d[j]] || {};
            o=o[d[j]];
        }
    }
    return o;
};

Obviously this is just a modification of the YAHOO.namespace function. I’d recommend putting this under your own namespace (I’m trying to put most of the code I write on this website under the Y2 namespace, but everyone should have their own parent namespace), like so (any namespaces you create using this function won’t use the parent namespace assigned here by default):

if (typeof Y2 == "undefined") {
    var Y2 = {};
}
Y2.namespace = function() { /* copy function contents from above. */ };

But you can do whatever you want. This is one of the functions that I think separates YUI from the other frameworks out there, giving an easy utility to organize your code. This is something I think jQuery seriously lacks, noting from the code inside the many jQuery plugins contributed by end users. Many jQuery contributors do not organize their code, putting multiple unnecessary top level functions into jQuery.fn as methods, or into the jQuery object itself as functions. People whine about polluting the global namespace… I suppose it might be considered nitpickey to whine about the jQuery namespace. Okay you whiney bastard, let’s help out and put this into jQuery!

// include jQuery first.
jQuery.namespace = function() {
    var a=arguments, o=null, i, j, d;
    for (i=0; i<a.length; i=i+1) {
        d=a[i].split(".");
        o=window;
        for (j=0; j<d.length; j=j+1) {
            o[d[j]]=o[d[j]] || {};
            o=o[d[j]];
        }
    }
    return o;
};

Please note, this method does NOT work using jQuery methods with an element context, such as jQuery(‘div’).myNamespace.myMethod(). Your element context won’t be carried through to myMethod().

However, you can use it for jQuery functions, such as this:

// definition
jQuery.namespace( 'jQuery.debug' );
jQuery.debug.test1 = function()
{
    alert( 'test1 function' );
};
jQuery.debug.test2 = function()
{
    alert( 'test2 function' );
};
// usage
jQuery.debug.test1();
jQuery.debug.test2();

For more information, you can read Global Domination, an article written by Douglas Crockford, or Best Practices for Writing jQuery plugins.

Updated: fixed some weird source parsing errors introduced by the code formatting plugin.

ALARMd now supports URLs

2007-08-21T00:00:00-05:00

When you add an alarm source to ALARMd, the Internet Alarm Clock, it will now default to opening the input URL in a new window, if the URL is determined not to be an MP3, Youtube video, or a LAST.FM user or tag.

I added this to use maLArquee as an alarm. For instance you can try adding this one to your ALARMd for a nice wake up message.

http://www.zachleat.com/Projects/Malarquee/index.html?text=Jnxr%2520hc!!!

Of course the obvious downfall of this approach is that your target website would need sound if you wanted to actually use it to wake up. But you could also use it to open up a new window at a specific time to prank a friend, coworker, or loved one. Try setting up ALARMd to use a naked lady website as a target url on your coworkers computer and set the time for right after lunch! Or open ALARMd up on your colleague’s computer and get it to open a competitor’s website during a big presentation to the company president.

Fun to be had by all, I’m sure.

maLArquee, Bringing Back the Marquee

2007-08-20T00:00:00-05:00

What did you spend your Saturday afternoon on? Did you kick up your feet in your hammock with a nice glass of lemonade in the shade of your favorite tree and read the HTML specification? Me too! Who knew that we’d have so much in common? Since you’re obviously like me, you’ve probably wondered to yourself: where did the marquee tag go? Why isn’t the internet graced with scrolling text gently flowing like a babbling brook across the pixels of your web browser? Well since you spent your Saturday reading the HTML specifications, you would know that the tag was only supported by Internet Explorer, and wasn’t even a part of the HTML spec. Unbelievable right? And to think the tag I came to know and love wasn’t part of the spec either! I’m just offended as you, let me reassure you.

Well today, we’re going to solve all of that. Today, I’m going to show you a full screen web browser marquee that will both amaze and excite you. Here we go:

Malarquee

param name="movie" value="http://www.youtube.com/v/9OiF8Hd6Db0">

What is it for?

There are a few obvious uses, I suppose. You can send someone a nice greeting in an email link (it does a ROT13 encoding to mask the text inside the link). Try one of these:

For a spouse: I want a divorce.

For an employee: You’re fired.

For a doctor: I’m sorry but you have anal warts.

For your son or daughter: You were adopted.

So, what else does it do?

I knew you’d ask. If you click the Options link in the top right corner, you can scroll your text across multiple web clients! Input the number of clients you’d like to use and the number of your current client. Hit the update and save button to refresh your page. It will automatically parse your text accordingly (adding extra spaces at the end as blank slides if needed). You can test this using one computer by bringing up the following two links in separate windows side by side (you can use a different web browser for each link if you’d like):

maLArquee Client #1
maLArquee Client #2

You could also go into a computer lab and scroll some text on a couple different computers.

Why?

I think it’s fun to try new things on the web, experiment a bit. That’s also why I made ALARMd, an Internet Alarm Clock. For this project, I think it might be fun to try a new JavaScript library, just to get a little bit more experience with a range of different coding types. So I decided to use MooTools, and wrote a little review on my experience, coming from a YUI and jQuery background.

How does it work?

Every 5 scrolls (I reserve the right to change this number at any time I so wish to conserve bandwidth), the page makes an XmlHttpRequest to the server, gets the server time, and adjusts the delay of the next scroll event to synchronize scrolling between multiple browsers. Ideally, if every computer were the same, we could just do a single XmlHttpRequest at page load and do a standard interval for scrolling. But we all know that every web browser is different, and just because you do a setInterval(yourFunction,1000) doesn’t mean it’s actually going to run yourFunction every second. It might run in 1010 ms or 990 ms. Thus, the XmlHttpRequest is needed to resynchronize all of the clients to a standard clock.

If there is any interest, I’ll post the code to the time.php script that returns the JSON containing the server time.

What would you do different next time?

I told my gracious web host about this project after I was approximately 90% complete with it, and his response was: “Did you use NTP?”, with which I replied: “What is NTP?” Ugh. There is even a JavaScript implementation.

In order to provide balance and order to the universe, please read the following link.

YUI Code Review: YAHOO.namespace

2007-08-09T00:00:00-05:00

This is the first in a one part series of posts (the is optional) reviewing the actual code contained in the YUI library. This series is not intended for advanced JavaScripters, so if you’re insulted by reading things you already know, you probably aren’t a very good student.

YAHOO.namespace. This is a great little utility function that gives you an easy way to encourage low coupling throughout your JavaScript code. Divide your functions into functional units! If you already know how to use this function, you can skip to the bottom to learn a few JavaScript tricks Yahoo has put in. If not, keep reading! Are you making a new package you want to put under the YAHOO namespace? Just declare it in a string argument passed into the YAHOO.namespace function:

YAHOO.namespace( 'myNamespace' );

This will create a YAHOO.myNamespace object that can be used many different ways. You can assign a single function to it:

YAHOO.myNamespace = function() {};

YAHOO.myNamespace();

Or you can assign multiple functions to it (with private variables included) using the amazing Module Pattern:

YAHOO.myNamespace = function() {
  var myPrivateVariable;

  return {
    myFirstFunction: function() { return myPrivateVariable; },
    mySecondFunction: function() {}
  }
}();

var hisOrHerPrivateVariable = YAHOO.myNamespace.myFirstFunction();
YAHOO.myNamespace.mySecondFunction();

Did you know that you can pass multiple arguments into YAHOO.namespace? I’ve been using YUI all this time and didn’t know about this feature. But the more I think about it, the more I doubt it’s usefulness. When are you going to declare two unrelated namespaces adjacently in code? For example, doing this is redundant in YUI:

YAHOO.namespace( 'myNamespace' );
YAHOO.namespace( 'myNamespace.myNestedNamespace' );

The second call to YAHOO.namespace will reuse ‘myNamespace’ if it exists, and create it if it doesn’t. But the point here is that you can do something like the following:

YAHOO.namespace( 'myNamespace', 'myOtherNamespace' );

which will create YAHOO.myNamespace and YAHOO.myOtherNamespace, and return a reference to the last one created, in this case YAHOO.myOtherNamespace.

Here’s the code from this nice little function:

YAHOO.namespace = function() {
    var a=arguments, o=null, i, j, d;
    for (i=0; i<a .length; i=i+1) {
        d=a[i].split(".");
        o=YAHOO;

        // YAHOO is implied, so it is ignored if it is included
        for (j=(d[0] == "YAHOO") ? 1 : 0; j<d.length; j=j+1) {
            o[d[j]]=o[d[j]] || {};
            o=o[d[j]];
        }
    }

    return o;
};

var a=arguments: They’re iterating over the arguments passed into the function to declare multiple simultaneously. Arguments is the variable passed into every function that you can use if you want to handle a variable number of arguments. You can also declare a few arguments in the function( myArg ) and use the arguments variable if you want.
j=(d[0] == "YAHOO") ? 1 : 0 They reuse the YAHOO top level object if not explicitly included into the declaration. Start the index at 1 if YAHOO was declared to skip defining it twice.
o[d[j]]=o[d[j]] || {}; They reuse existing namespaces if they have already been created. The OR || declaration means that Javascript will use {} (an empty object) if o[d[j]] is undefined.

What Sound Does a Cow Make? MooTools.

2007-07-22T00:00:00-05:00

Frameworks, Frameworks everywhere. There are the big six: Dojo, jQuery, prototype/scriptaculous, Ext, Mootools, and YUI. (Honorable meantion to Open Rico and Mochikit) I’ve had limited experience with all of these frameworks, but have actually worked on projects involving YUI and jQuery. So when I was shopping around for a framework that I didn’t have extensive experience with for my next project, I decided to with Mootools. They’ve been getting a lot of traffic lately for posting their SlickSpeed Selectors Test, so I figured why not try their wares.

Originally coming from the YUI Library (a strictly namespaced, well organized package), and then learning jQuery (a language with object chaining, a more object oriented approach, and a much larger community), the Mootools package definitely caught me off guard.

My first surprise was that it put functions EVERYWHERE! The Core file puts approximately ten functions in the global namespace, with the only indicator that they belong to Mootools being that they had a dollar sign prefix (e.g. $extend). Couldn’t these go into one global Mootools object? $E, $ES? These are given shortcuts with the normal $ and $$ functions. It just seems all over the place.

That being said, there is a lot of good functionality in the base Mootools distribution. A built in class to do Json communication (something YUI is lacking, although I’m sure it wouldn’t be too hard to port it in from Captain Crockford’s Code on his website), a class to Scroll to elements with nice transitions. It seems like everytime I would hit a “functional” snag in my project, I could find the exact code I needed already included in the core file.

I love their download page! Autopackaged code using Dean Edwards’ Packer. One small complaint is that there is no option to disable automatic include of dependencies. They want you to package Mootools into one single file everytime (which is unwieldy, considering I have to maintain my own text file of which packages I put into the source code, if I don’t want everything), and don’t let you download just a certain package for separate inclusion. But when the whole thing weighs in at 40KB, why does it even matter? I would recommend just downloading all the Components together and just not worrying about it.

All in all, I’m quite happy with my Mootools experience. I’ve definitely found that their SmoothScroll class and easy Color fading techniques are used pretty heavily by developers using Mootools, which gives you a sixth sense that the page you’re viewing is using the Mootools library. Sometimes I can just tell without even looking at the source files, which in this case is a good thing, given that we’re talking about animation techniques and not raw widget style. But I plan on writing more about my pet peeves with framework widget styles later on.

If you’ve been using one framework for a really long time, I would recommend checking out Mootools. Or any other framework. The more frameworks that you’ve tried, the better your perspective is on JavaScript in general, and what your framework’s strengths and weaknesses are. Mix it up!

20/20 Hindsight, a Look Back at ALARMd

2007-07-22T00:00:00-05:00

Now that the traffic has died down a little bit on ALARMd, I’d like to write a little bit about my experiences with something I don’t think anyone predicted would garner so much interest.

The day I sent the link to the LifeHacker editor, I purchased the alarmd.com domain. My thoughts on the domain were that I should have it just in case I decided to host the clock on the domain for easy access, and I certainly didn’t want anyone else to have it. That turned out to be a good idea since an unnamed internet charlatan purchased a similar domain mere hours after I had purchased mine and pointed it to his website. This same person was going onto various blogs and websites where ALARMd had been posted saying that it was a ripoff of his site, which of course was not true. I’m sure he got some traffic from it, and certainly am curious about the liberties he takes with the truth just to make a buck. Obviously I am not going to post a link to his website, since I do not want him to receive any traffic to his Google Ads machine. I hope that you, as a reader of my website, will trust that anything linked to this guy’s name is not worth any of your time.

The link was posted to LifeHacker, and my meager website went from an average of 50 hits a day to receiving 87000 hits in two weeks. In the end, I got more visitors from stumbleupon than LifeHacker, which is really a testament to that website’s popularity.

It was on delicious popular bookmarks for a while. It actually also ended up being on television. I know, I know, it seems ridiculous to even put websites on television, but it was. A lady named Erin O’Hearn does a segment called “Right Now on the Net” for Channel 6 Action News in Philadelphia. She had a blurb about it and you can even watch it here [Skip to 1:07]. I guess it was also on an internet radio show called “Techtalk Radio” and was featured as their site of the week. You can listen to that podcast here [Skip to 47:09], even though they pronounce my name “Zach-A-Lot” and are obsessed with the “Naked” checkbox. But to be fair, who isn’t obsessed with Naked checkboxes?

And just recently, I put up the alarmd.com domain as a redirect to the site for all the hard-core users still going to it and using it. It’s still getting a couple of hundred hits a day.

So, hindsight. The alarm clock is a device that everyone uses and easily relates to, but also a device that people have low expectations for. Most alarms only have one or two times they go off for, and with only a few options for alerting: buzzer or radio. Most go off every day, even on the weekends when you want to sleep in. But people put up with their crappy alarm clocks because there is literally no good alarm clock hardware out there. And some of the features I’ve put into ALARMd can also be seen in alarm clocks that cost over $100 USD. Ridiculous. I would bet that there is a huge market for someone to come out with an alarm clock that doesn’t suck and costs $40, or maybe people just want to use their cell phones all the time. I wonder if the iPhone alarm is any good. Look for my next project, which will be just as, if not more, retarded as the Internet Alarm Clock.

DOMDom, easy DOM Element Creation

2007-07-07T00:00:00-05:00

Generally when approaching a complex problem involving web programming in JavaScript, the first question I ask myself is ‘What would Jesus do?’ As much as I am entertained by a mental picture of Mr. Jesus himself sitting on his Jesux Distro appending children (and parents) into his DOM, I am instead distracted by an intense “passionate” hatred for Mel Gibson swelling in my chest. It’s actually quite distracting to the problem I am having, but I calm myself by punching my 4 foot tall inflatable Mad Max and wonder how much time I waste doing this. I figure it happens about twice an hour. (Digression)

The DOM. Arch-nemesis of web developers attempting to support the ultimately tiny (I think it’s down to about 5 or 8% now?) sliver of browser market share that Internet Explorer currently entails. Let’s make it easier on ourselves and make a little package to do it for us. Run a function, pass in an argument with a description of the DOM node(s) we wish to create, and have the package auto-correct any bugs we would have encountered during manual creation, and maybe even have it inserted or appended for us.

But wait, why are we doing this when there are literally 80 billion other DOM element creation classes already out there? It’s all about syntax. The existing packages are incredibly verbose, focusing too much on a complex object structure to describe the nodes, in some cases even having separate objects for attributes inside a single node. Why not use the syntax we’ve already come to love in the various DOM query libraries that are available? Why not use DOMDom? Let’s see a few examples:

Single Node String

'div'

<div></div>

Single Node String with ID and Classes

'div#id1.class1.class2'

<div id="id1" class="class1 class2"></div>

Single Node String for a Form Element

'input[name="myTextBox",type="text",maxlength="5"]'

<input name="myTextBox" maxlength="5" type="text"/>

Single Node String with Style Syntax

'div{height=80px,color=#f90,border=1px solid #000}'

<div style="border: 1px solid #000; height: 80px; color: #f90"></div>

Complex Single Node String with ID, multiple classes, Style, and Namespaced Attribute)

'div#id1.class1.class2[style="width:60px;color:#f90",@class="class4",@att="true",@namespace:att="false"]'

<div id="id1" att="true" namespace:att="false" class="class1 class2 class4" style="width: 60px; color: #f90;"></div>

Multiple Node String: Linear (Parents with one Child)

'div span div'

<div>
     <span>
          <div></div>
     </span>
</div>

Multiple Node String: Non-Linear (Parent with more than one Child)

{ 'div': [ 'span', 'span' ] }

<div>
     <span></span>
     <span></span>
</div>

How Does It Work?

By default, it’s set up to do HTML Fragments (innerHTML) because they are much speedier than the manual DOM element creation (createElement). But if you desire, you can toggle a boolean in the code and it will switch back to DOM element creation. When in DOM element creation mode, it will account for the following browser bugs:

(IE6) Standardized for attribute representation (pointer to htmlFor)
(IE6) Standardized case for accesskey, usemap, maxlength, and frameborder attributes.
(IE6) Standardized checked attribute for radio and checkboxes.
(IE6) Special consideration for dynamic handling of name and type attributes (on form elements).
(Firefox) Works with whitespace that is treated as a node.

Syntax

You should already be able to tell how to create a node from the examples above. Here are some more things you might not have guessed:

Creating a node with an id

'div#myId'

Creating a node with CSS classes

'div.class1.class2'

Creating two nodes at the same level

[ 'div', 'div' ]

Creating a node with two children

{ 'div': [ 'div', 'div' ] }

You can mix the {} and [] syntax wherever you like, but if you want a node to have non-linear children, you have to use the {} object notation.

Creating a text node (start the node declaration with a #, you can change this to another non-conflicting character in the code if you like)

'#Any Text Here'

Creating a node with attributes (the @ is optional)

'div[class="class3",style="width:60px;color:#f90",@att="true",@namespace:att="false"]'

Creating a node with a Style Shortcut (mixing with a style attribute is handled properly)

'div{color=#f90,border=1px solid #000}[style="height:80px;background:#fff"]'

A few notes on attributes. Quotes are required on attributes (single or double but be consistent), but are not required in the style shortcut declaration. Quotes are not allowed to be nested inside of attributes (a single quote cannot be inside of a double quote and vice versa).

And of course, all of the above can be mixed together

'div#myId.class1.class2{color=#f90}[customAttr="true",@customAttr2="false"] div#child1 div#child2'

Usage

Appending at the end of a parent’s children:

DOMDom.append( 'div', yourParentNode );

Replacing the children of a parent:

DOMDom.replace( 'div', yourParentNode );

Unshifting (inserting at the beginning of a parent’s children):

DOMDom.unshift( 'div', yourParentNode );

Inserting before a certain integer index of a parent’s children:

// must have at least 3 children, the index is 0 based, if index is null with unshift by default
DOMDom.insert( 'div', yourParentNode, 2 );

Templates

Use <$var> to indicate a variable, in this example <$test>

// "Compile" the template
var str = DOMDom.compile( { 'div.test span': '#Test <$test>' } );

// Use your template in some context, notice the test variable being set.
for( var j = 0; j < 1000; j++ )
{
    // knows we're using a compiled template since we're passing in variables as a third argument.
    DOMDom.append( str, d, { test: j } );
}

Benchmarks

(If you have Firebug open, make sure it's not on the HTML tab, this will slow down the benchmark significantly)

Most of my work here has been inspired by the DomQuery and DomHelper classes written by JavaScript rock star Jack Slocum (the guy's initials are J.S. for God's sake), so I modeled my benchmark after his benchmark hosted on his website to test the DomHelper class. I'm running the same nodes he's testing on his website, so the results should be comparable. You can test my benchmark for DOMDom here. Here are some results, reporting the average of 3 results with the format of an uncompiled element first and the compiled template in square brackets.

DOMDom Results

Internet Explorer 6: 666 ms [328 ms]
Firefox 2.0.0.4: 1880 ms [666 ms]
Safari 3.0.2 [Windows]: 546 ms [151 ms]
Opera 9.21: 343 ms [140 ms]

Comparative numbers from Jack Slocum's DomHelper

Internet Explorer 6: 2458 ms [677 ms]
Firefox 2.0.0.4: 672 ms [458 ms]
Safari 3.0.2 [Windows]: 291 ms [119 ms]
Opera 9.21: 370 ms [166 ms]

The thing to take away from this is the question of why Satan is haunting my benchmarks? Two 666 averages? Anyway, DOMDom is quite a bit faster in the most popular browser, Internet Explorer, although I haven't tested it on IE7 yet. In Firefox, the opposite is true, with DomHelper taking the lead. Opera is comparable and Safari is faster in DomHelper as well. You can run your own tests using the links above.

Dependencies

This library was built to work with Yahoo User Interface (YUI), but could be trivially ported to another library by changing the function dependencies listed in the ADAPTER variable in the code.

var ADAPTER = {
  setStyle: YAHOO.util.Dom.setStyle,
  addClass: YAHOO.util.Dom.addClass,
  isString: YAHOO.lang.isString,
  isArray: YAHOO.lang.isArray,
  isNumber: YAHOO.lang.isNumber,
  isObject: YAHOO.lang.isObject,
  get: YAHOO.util.Dom.get
}; // to port, change these references

If you're still reading this encyclopedia, here are some links:

-dom suffix denoting condition or state, as in freedom, wisdom, or DOMDom

Update: changed the variable syntax to allow variables inside of nodes (not just text).

Wake up to YouTube on my Internet Alarm Clock

2007-06-18T00:00:00-05:00

Update: Try the new ALARMd 2 Beta, with Google Calendar integration and offline Youtube caching.

Did you take your contacts out last night and you can’t see the time on your alarm clock from all the way across the room?

I’m here to calm your fears. Enter ALARMD, the Internet Alarm Clock. Wake up to any Youtube video (that allows embedding), a last.fm user stream or tag, or any mp3 hosted online. There are a few defaults in there, but you can add and modify your own.

Features:

Supports multiple alarms (ALT R to add an alarm or use the Add Alarm button).
Options for 24 Hour (Military) time and Seconds display
Supports MP3 (hosted online), YouTube videos (that allow embedding), and last.fm user or tag streams.
Key Mash Mode to kill the alarm (hit five random keys in one second)
Time Font Size customization (automatically size to the width of the window using the Max option)
Typical alarm clock colors: Red, Green, or Blue
Alarm Toggle based on the Day of the Week
Test button to make sure your speaker volume is set correctly.
Sleep Mode button to get rid of the extra GUI while you don’t need it.
Save all of your settings, URL’s, and alarms locally in a cookie (you don’t need yet another account to use this)

Things to think about:

Power Settings – disable your screen saver, or any sort of automatic suspend or sleep setting. In my testing, having your monitor go into power save mode is acceptable, and the alarms will still sound (but you might want to test this yourself and leave a comment with your result).
You might not want to use with a CRT, for fear of burn in.
Personally, I like to use this in Opera, just because their default full screen mode (F11) doesn’t have toolbars or a status bar. But you can use the Fuller Screen Firefox plug-in to soup up your Firefox for similar functionality.
Word of warning, the window must have focus to autoplay YouTube videos.
Make sure your local time on your computer is correct, especially if you are traveling between time zones. It doesn’t do any server side validation on the time (yet?).

Possible Future Improvements:

Countdown mode, displays amount of time until next alarm in place of the clock (good for timed presentations, where you want to see how much time is left before you have to quit).
Google Gears integration for offline mode (if your internet goes out during the night)
Support customizing source URL’s on a per alarm basis.
Support days of the week toggle on a per alarm basis.
Support user specified color customization.
A crescendo alarm MP3 that increases in volume for a more peaceful wake up experience.
An alarm MP3 with especially violent noises for heavy sleepers.
An alarm MP3 of my mom’s voice to get that nice feeling of childhood back.

This internet application was built using the Yahoo UI Libraries (YUI) and Jack Slocum’s Ext DomQuery class. It is written entirely without using any server side programming languages, and therefore can be saved to your local machine. Not that anyone might want to use the Internet Alarm Clock, but if you do, I declare it officially released under the BSD license. Just don’t forget to cite the source when you redistribute.

Update: added a couple more things to think about.

Screen Readers and Listening at the Speed of Sound

2007-05-17T00:00:00-05:00

Here is a presentation given by a guy named Victor Tsaran on how he personally uses screen readers to browse the web. As web developers, accessibility is an important aspect of our work and cannot be ignored. How many websites have you browsed that had flash navigation? If you’re not a web developer, you need to skip ahead to time stamp 25:44 to see the mega-fast speed this guy uses the screen reader at. I couldn’t understand a single word coming out of my speaker.

Google Using YUI Grids CSS

2007-04-05T00:00:00-05:00

Head over to the Google Homepage. Log In using your Google Account. Make sure you’re at your Personalized Homepage. Take a look at the source CSS file ig.css included on the page. There are a few peculiar lines of code that I recognized from another source, the Yahoo User Interface Grids CSS file. Yahoo has provided a set of standard CSS definitions under the BSD license that allow a developer to easily make fluid or fixed width column layouts. And on the Google Personalized Homepage, there are the following class definitions:

#modules .yui-b{position:static;display:block;margin:0 0 1em 0;float:none;width:auto;overflow:hidden;}
.yui-gb .yui-u{float:left;margin-left:2%;*margin-left:1.895%;width:32%;}
.yui-gb div.first{margin-left:0;}
#modules,.yui-gb{zoom:1;}

This code includes identical Class names taken from the Yahoo User Interface library Grids CSS component. Here is the source in the grids.css file from Yahoo (truncated for simplicity).

#yui-main .yui-b{position:static;}
.yui-t7 #yui-main .yui-b {
  display:block;margin:0 0 1em 0;
}
#yui-main .yui-b {float:none;width:auto;}
.yui-gb .yui-u{float:left;margin-left:2%;*margin-left:1.895%;width:32%;}
.yui-gb div.first{margin-left:0;}
#bd,.yui-gb{zoom:1;}

Obviously, it’s the same code, with a few minor differences.

The interesting thing to note is that the YUI Grids CSS source code is licensed under a BSD license, which includes the following provisions:

Redistributions of source code must retain the above copyright notice, this list of conditions and the
following disclaimer.

The copyright notice they’re referring to is not included anywhere on the Google Personalized Homepage (and would seem to be a violation of the license). Now this may seem like a small infraction when we’re just talking about 4 lines of CSS code. But really, if they think the code is good enough that they will use it in such a prominent way and not write it from scratch using their own means, they should follow the licensing agreements stipulated.

Update
Google has added the BSD license statement and attribution to Yahoo in their CSS file (ig.css):

/* ===============BEGIN BSD LICENSED PORTION============= */
/*
Copyright (c) 2007, Yahoo! Inc. All rights reserved.
Code licensed under the BSD License:
http://developer.yahoo.net/yui/license.txt
version: 2.2.0
*/

#modules .yui-b {
  position:static;
  display:block;
  margin:0 0 1em 0;
  float:none;
  width:auto;
  overflow:hidden;
}
.yui-gb .yui-u {
  float:left;
  margin-left:2%;
  *margin-left:1.895%;
  width:32%;
}
.yui-gb div.first {
  margin-left:0;
}
#modules,.yui-gb {
  zoom:1;
}
/* ===============END BSD LICENSED PORTION============= */

Sorry to everyone visiting the page for the extra millisecond or two it will take to load these comments.

Logical XOR in JavaScript

2007-03-23T00:00:00-05:00

Of course there wouldn’t be an XOR function in JavaScript when I needed one. So I googled around and found an implementation at How To Create. But it only took two arguments. So I rolled my own supporting a variable number of arguments. In my personal stuff, I’ve put it into a Math library under the YAHOO namespace, and you can decide if you want to do that on your own.

function xor()
{
  var b = false;
  for( var j = 0; j < arguments.length; j++ )
  {
    if( arguments[ j ] && !b ) b = true;
    else if( arguments[ j ] && b ) return false;
  }
  return b;
};

Usage:

xor( false, true ); // true
xor( true, true ); // false
xor( false, false, true, true, true, false, true, false ); // false
xor( false, false, false, true, false, false, false, false ); // true

Conservative Design Example: Hierarchical Options

2007-03-23T00:00:00-05:00

Welcome, one and all, to the second installment of actual code examples for the Conservative Design series. The decision was made (by me) to rename the component in question from the original Hierarchical Select to Hierarchical Options, due to the fact that the hierarchy can consist of any multiple option component, and is not limited to just a select. And to this face, this particular component was documented in the original post entitled Conservative Design: Hierarchical Select Boxes.

Click the image above to go to the example.

Notes on the example: The Tree structure is as follows:

Primary
- Secondary
  - Tertiary
    - Quaternary
      - Quinary
  - 2nd Tertiary (is a static element that doesn’t hide)

So without further adieu or out of place french, what do we have? 3 out of 4 requirements and 1 of 2 luxury items.

Handles any number of select elements in a linear or tree (luxury item) like structure.
Child select elements are optional based on parent selection. Can hide entire div element or display a message stating no options are available.
Compliant with the Reset button.
Right now only loads from standard HTML markup (not yet from JavaScript or JSON or an XMLHTTPRequest)
Only supports Select elements for now, in the future should be abstracted to support Checkbox Lists or any multiple option component.

Outstanding Bugs:

Opera button doesn’t reset properly with Reset Button
Clicking off of the default and then back onto the default has the original selections downstream (but doesn’t propagate more than one level)

OMG SOA

2007-03-12T00:00:00-05:00

In today’s Web 2.0 world of ultimate abstraction, you don’t need to be bothered with the rudimentary low level programming functions of everyday languages. Client Side implementation of JavaScript functions across the browser landscape is unreliable at best, so why should you trust it for anything? So using forward thinking and futureproof compatibility design, naturally we will turn to the next great phase of web’s evolutionary growth, the Service Oriented Architecture (SOA). Using SOAP envelopes to package our function calls, I will now demo what is certainly to be the future of web development, and maybe, all programming endeavors. I call it: OMG SOA.

Are you programming a for loop? How do you know that the client will increment your integers through the loop correctly? That’s why you need to call our Incrementer Web Service to increment your loop counter.

Sample Service Calls:

Are you programming an array that needs to be magically combined into a string? Do you think you can reliably count on Internet Explorer to perform the function in the same way as your Firefox’s, or your Opera’s, or even your (God Forbid) Safari’s??? No, dare I say it, no.

But don’t fear. We are here to comfort your pain, with a shot in the arm of standarditity. Welcome the String Concatenation Web Service.

Sample Service Call:

Concatenate string1 with string2 with string3

And finally, are you feeling lost in this sea of amorphous web technologies mixing and mashing together to form the gelatinous blob of money and media whores we know as Web 2.0? Don’t worry, OMG SOA is here for you again to solve all of your identity crisis problems. Ask our Are you Web 2.0 Web Service with your URL and the magic 8 ball service will answer your question.

Sample Service Call:

Is www.zachleat.com Web 2.0?

Update: apparently there is already a company called the Object Management Group with a website about SOA. Whoops?

Conservative Design Example: Multiple Option List

2007-03-10T00:00:00-06:00

All of the posts in the Conservative Design series so far have been brainstorming of design patterns. But how about some real life examples, some actual code? Let’s dive in.

The first example I decided to tackle was the Option List, specifically the variant that allows multiple options to be selected. Let me start out by saying that I didn’t abstract out the type of source element that you could put into this example, I only programmed the element for a element. For the impatient, let’s just start with the result:

Click the image to see the actual example.

This element was constructed using the YUI Library and Jack Slocum’s DomQuery selector class, as well as using the new form validation CSS and JavaScript code I’m currently developing entitled ‘Valdi‘.

It includes 3 of the 4 of the minimum features required as set in the original specification.

Features:

Validation: there is no submit button, but if there were, it would validate if the form has been entry has a value.
Quick Links: Select All, Select None, and Sort the Options
Customizable Options: Allow the user to add their own options for selection.
Does not abstract option types (checkbox, etc)
Keyboard Support: CTRL A inside of the select box selects all options, Delete or Backspace removes the selected options, Enter key inside Add input field automatically adds option to the select.
Can be easily transformed into a Single Option List by removing the multiple=”multiple” option in the html.
Sort will toggle between Ascending and Descending and maintain the selected options
When the number of options outweighs the select size, the number of options is displayed next to the Add button. Try adding 5 or more options to the select list.

Screenshots for the Lazy People:

Multiple Options are Added

Validation when an Option is not selected:

Success, they selected something and submitted:

Watch for another separate article about Valdi later on.

Conservative Design: Command Line Interface

2007-03-07T00:00:00-06:00

This is another post in the series entitled Conservative Design Patterns for Form Elements.

The argument has existed since the dawn of the Graphical User Interface (GUI). Which is better, keyboard-exclusive Command Line or mouse-intensive GUI’s? As more enterprise architectures are moving from terminals to web interfaces for their products, and as time is moving forward with the everyman user desiring an interface that looks pretty and easy to use, we’re seeing a drastic reduction in the utilization of the keyboard.

But with the exception of form input, we’ve almost completely moved away from the keyboard as a means to execute functions and navigation. I’m proposing that we bring back the power of the keyboard. Obviously we can’t get rid of the GUI altogether, but instead complement it with a powerful command line.

This component could exist as a standalone command line interface component or as a supplement to any search bar your page may contain. The basic premise of the Command Line Interface component is to provide a standardized method of navigating your website using nothing but the keyboard. It could fulfill more complex operations, but the scope of this article will just cover command line rudimentary navigation.

Screen Printing: Fake Command Line Example

Screen Printing: Fake Command Line Example of AutoComplete Capabilities

Minimum Feature Set: (source)

Autocomplete: must be able to finish the current command being typed by presenting a list of available options to the user. Must be compatible with keyboard navigation:
- UP and DOWN arrows to select from list
- TAB autocompletes to first option
Markup Scanning for Applicable Links: scan the current dom for tags with a href element that could be used in autocomplete.
Quick commands: markup options (custom attributes?) to allow the programmer to define commands in the html. These are one to three character combinations that execute a link or event.
Standardized Command Set: standardized hot key to force focus to the command line. Also, for navigation options that are standardized between every website, have a standard set of commands that will execute with the same behavior, regardless of navigation implementation (Home [H], Login [L], Register [R], Forgotten Password [FP], Contact Us Page [C], Privacy Policy [PRIV], Terms of Service [TOS])

Luxury Feature Set:

Markup Scanning for Events: sometimes navigation is executed through event handling. Scan the events assigned to nodes for any available options that could be executed in navigation.

Limitations:

Limitations on any sort of mouse-required interface: drag and drop
Interaction with flash?

Idea Credits:

Beaten to the Spiked Punch

2007-03-03T00:00:00-06:00

No matter what you think, someone else is thinking the same thing. I guess this guy might just be living with my same brain waves but a year or so earlier. It has never been a better time to just stop thinking.

Conservative Design: Option List

2007-02-26T00:00:00-06:00

This is another post in the series entitled Conservative Design Patterns for Form Elements.

Next we’ll look at a web component that is almost ubiquitous among user interfaces today, the Option List. The Option List can take any one of the following three forms.

Multiple Selections: User can select any number of the options presented to them. Types: Checkbox Group, Multiple Select Element
Single Selection: User can select none or one of the options available. Types: Radio Group, Select Element
User Input List: User types in the options that they want to use. All inputs are marked as selected. Types: Group of Textboxes

We’ll describe each of these variants separately.

Multiple Selections:

Minimum Feature Set:

Validation: The user can select at least one, an integer range of options, or any number of the options presented.
Quick Links: optional links to select all options, clear the options, and toggle the options to the opposite value of what they currently hold.
Customizable Values: optionally allow the user to add their own options (one, an integer range, or many) to the list.
Other Variants: Any Select Element, as described in the original post.

Single Selection:

Minimum Feature Set:

Validation: The user can select at most one of the options presented.
Quick Link: optional link to clear the options
Customizable Value: optionally allow the user to add their own option (only one is required, since only one can be selected).
Other Variants: Any Select1 Element, as described in the original post.

User Input List:

Minimum Feature Set:

Validation: The user must have at least one of the text fields with a value (doesn’t matter which one). Or the user must have an integer range number of fields with values.
Quick Link: optional link next to an element to remove that element from the list (not clear it, remove it)
Customizable Values: optionally allow the user to add their own options (up to an integer limit).
Other Variants: Any List of InputX Elements, as described in the original post (could be passwords or textareas).

The images above for all three component types show a textbox for the addition of another option, but this should also allow customization to allow any type of (Select or InputX) element for the addition of another option.

Conservative Design Patterns for Form Elements

2007-02-22T00:00:00-06:00

Have you ever been to a web site that looks as though it has been built exclusively using pre-made bulky widgets cookie cuttered right onto the page? Lovely grid components, sweet over-featured WYSIWYG editors, maybe a Google or Yahoo map thrown in on the page for good measure. Conformist web sites using the conditioning forced upon them by time, executive, or work-ethic based constraints. The widgets on these websites either seem too bulky, reinventing the wheel with avant-garde user interaction for a confusing user experience, or they are just too lightweight to justify using at all.

What I’m proposing is a standard set of Design Patterns for form input, as an extension to already existing HTML form elements. By describing the best practices for certain use cases of input, we can form a set of building blocks that can be used to enhance existing forms, instead of replacing them with totally new ways of user interaction.

So keeping away from the spirit of inventing names for things that are already being done, I won’t be trivializing this idea with a catch phrase. Instead I hope you will realize the value of BUILDING BLOCKS over cookie cutters.

These components be used to handle the tween cases of GUI development, where the interaction doesn’t warrant a full blown widget, but requires more than a standard HTML form element. I would be excited to see work done at this level of GUI development inside of the JavaScript libraries that are out there instead of work on the overblown “Widget Set” that seems to be the buzz in the community.

Spectrum of GUI Elements

Raw HTML Inputs (Text, Password, Select…) -> Smidgets -> Full Blown Widgets (Editable Grid, Rich Text Editor)

Legend

Toggle Option On or Off (Toggle)
Select 0-1 Options From a List (Select1)
Select 0 Options From a List (Select )
Input 0 Characters into an Element (InputX)
Input is obfuscated to prevent from being read (Obfuscated)

To describe what we want, let’s first see what we have.

Existing HTML Elements

Buttons (clicking performs a data altering action or form submission action)
- Submit
- Reset
- Push (without attached behavior)
Checkbox (Toggle)
Checkbox Group (Select )
Radio Group (Select1)
Select Single (Select1)
Select Multiple (Select )
Text (InputX)
Textarea (antiquated due to CSS styled word wrapping multi line Text input) (InputX)
Password (InputX, Obfuscated)

And because this is going to be a series, I’ll continue with my first case of a Conservative Design Form Element in a new post.

Let me just reiterate that I do hope you take the ideas for these GUI components and develop them in your favorite JavaScript library. The purpose of this is to come up with a set of feature-based standards so that people don’t have to keep developing their own components over and over again. Do you have an idea for a feature that you think should be included in the standard or luxury feature set of a component? Post it in the comments of that component blog post and I’ll certainly modify the post with your suggestions.

Conservative Design: Hierarchical Select

2007-02-22T00:00:00-06:00

This is a post in a series entitled Conservative Design Patterns for Form Elements.

For now, I’ll start off with an easy web component that a lot of you have probably already had some experience with. But, strangely enough, it is not included in any of the JavaScript libraries that are out there, that I’ve seen. If you know of one, go ahead and post it in the comments.

Hierarchical Select Boxes (sometimes called Dynamic Select Boxes if you’re doing a web search)

Behavior: 2 or more select boxes working in parallel, where selection of an option in a parent dynamically adjusts the options of the child.

Screenshot (Prior to any selection):

Screenshot (After an option is chosen in the first select box):

Minimum Requirements for Acceptable Feature Set:

Must be able to handle any (reasonable) number of select boxes in a linear structure: parent elements only have one child.
Child select elements can be optional depending on parent selection. Maybe a continent doesn’t have any countries, so don’t display a child select element. It would be nice to have a visual indicator showing whether or not a parent option had children (triangle, folder(?), arrow or other customizable icon).
Must have functionality that allows it to be reset with the form reset button, as Matt Kruse has done (Example 3).
Load options in child select’s dynamically from multiple data sources (describe in raw HTML code, local JS file, remote JSON object or XML file using an XMLHTTPRequest)

Luxury Feature Set:

Must be able to nest select elements in a tree structure: selecting an option in a parent element could modify 2 child select elements.
Could be able to modify the options for any element that displays options (Select1 or Select as described in the Conservative Design Post: Checkbox Group, Radio Group, Select Single or Multiple)

Screen Printing, Fake Interfaces Part 1

2007-02-20T00:00:00-06:00

Why not error messages that tell you when your internet has been disconnected? How about one that tells you when you’ve been logged out (maybe in another window) and allow you to reauthenticate to the server right there? I don’t believe there are any architecture problems with these two ideas.

Checklist for Web Applications

2007-02-20T00:00:00-06:00

As the first post in this new category of web development, I’ve decided to keep it simple and post the different components and architecture considerations a developer must consider when making a new application, especially in today’s world of in-page dynamic interaction and the complications that has put on the problems that were considered solved in yesterday’s page level world. Mostly this is a place to collect my thoughts on this subject.

Automatic Print Styling: Is the page going to be able to be printed properly without a “Printer friendly” link? CSS style sheets can be used to modify the output of the page using the @media print declaration. Are the widget components you’re using in your JavaScript library able to support easy printing?
Browser History Management: Will your application support the back button, especially with the increased usage of AJAX interactions on a full page application. Don’t use XMLHTTPRequest’s to fetch the entire content of a page. Just redirect them to a new page when you are only saving the header and the footer.
Graded Browser Support: support of the web browsers with a large percentage of market share using the ideas put forth by Nate Koechley in his Graded Browser Support descriptions.
Bookmark and Permanent Linking: is the behavior of your JavaScript application changing how data is being displayed? You’d better modify the URL to allow the user to bookmark link straight to the same view.
File Compression: Minimize your CSS and JavaScript for delivery. GZip your CSS and JavaScript for browsers that support it (most all modern browsers do).
Efficient Caching Mechanisms: server side caching of data is necessary for high volume traffic.
Internationalization (i18n): will your application be viewed in other countries by non-English speakers? Are your dates in an international format? How about 24 hour time formats? Time zones? Do they observe Daylight Saving Time?
Error Logging: Both server side and client side (using AJAX to log JavaScript errors can be very helpful)

Recommended Luxury Items

Support mobile devices: How will your application look on a Blackberry? How does it render in Opera Mini?
Offline Mode: Add and modify data offline, with the ability to automatically synchronize changes when an internet connection becomes available.
Exportable data: PDF, Excel, RSS, even offline static HTML. JavaScript can sometimes give unknown results when using the browser to save the page locally. Make sure this is supported. Don’t force your users to save screenshots.

Enterprise Client Side Widgets

Data Grid: businesses just love data grids. Nothing like a nice standard set of cookie cutter constraints to force upon your data.
Charts and Graphs: metrics are important. Existing client side JavaScript charting packages can be limited when it comes to printing, or even saving the chart as an image file. These are important.

There are many facets that a developer must consider when designing a new application. I hope this list will at least make you think about some things that you may not have considered before. Thanks for reading.