Web 3.0, 6 Bladed Razors, 7 Minute Abs

Emulating onhashchange without setInterval

Zach Leatherman — Thu, 21 Aug 2008 06:00:13 +0000

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 hashString to the 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 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 that matches up with the scrollY/pageOffsetY property inside of the iframe, and retrieve the matching hash from the 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, and Safari 3.1.2***

Limitations:

No bookmarking support. We aren’t changing the top hash, we’re changing the iframe hash, so these aren’t bookmarkable.
***Safari 3 had an intermittent glitch when adding the first AJAX history entry, but then worked fine afterward.

Sample Example:

Double Whammy: OpenID and Microformats

Zach Leatherman — Fri, 23 May 2008 06:13:01 +0000

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

class="about vcard entry-author">

class="label">Name class="fn">Zach Leatherman

class="label">Location class="adr">Omaha, NE USA

class="label">Web href="http://www.zachleat.com/" class="url" rel="me">http://www.zachle...

id="bio"> class="label">Bio class="bio">UI Programmer, JavaScript Enthusiast, Soccer Hooligan

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)

Zach Leatherman — Sat, 10 May 2008 23:27:02 +0000

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

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

>/>>

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:

xmlns="http://example.com/">/>>

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:

prefix:xmlns="http://example.com/">:child/>>

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.

Technorati Tags: JavaScript, XML, selectNodes, YUI, jQuery, getElementsByTagName

Javascript Objects are NOT JSON

Zach Leatherman — Sat, 10 May 2008 04:47:55 +0000

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

Zach Leatherman — Thu, 08 May 2008 01:30:31 +0000

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

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

Zach Leatherman — Wed, 23 Apr 2008 04:51:08 +0000

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's 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 could draft email 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.

Technorati Tags: JavaScript, onunload, onbeforeunload, Ajax, Undo, Opera, Gmail

Forgive My Feed

Zach Leatherman — Sat, 19 Apr 2008 04:56:57 +0000

This is going through a bit of maintenance. I'm tagging and recategorizing my old posts, so feel free to "mark all as read" if you get a bunch of new items.

Rethinking JavaScript Grids and DataTables

Zach Leatherman — Sun, 13 Apr 2008 20:29:26 +0000

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:

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.

Technorati Tags: Interface Design, Dojo, Ext, jQuery, YUI, Grid, DataTable

ALARMd 2 Beta, with Google Calendar Integration

Zach Leatherman — Sun, 06 Apr 2008 07:31:59 +0000

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

Zach Leatherman — Sun, 06 Apr 2008 03:47:33 +0000

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.