What I've Learned

Too many drafts

2011-12-08T09:44:00.001-08:00

It's come to the point that I have more drafts than published posts in my account... and life isn't slowing down. I've started a new job, am expecting a new baby (my first), and there's still a lot I need to figure out. Writing doesn't come easy for me, but I thought to post something that gets the ball rolling. More to come!

Passing Second-Class Arguments

2011-03-09T22:57:00.000-08:00

Before it's current incarnation, I was frustrated by my own, soon-to-be-renamed, Proxy object. [Mind you, I don't mean the upcoming E5 Proxy object.] As a function manager, Proxy offers the benefit of passing secondary execution information, to it's managed routines. (These "extra" arguments permit comprehensive forking.) As with many function managers, this well-intentioned practice wound up restricting the number of arguments allowed in managed routines, resulting in a polluted signature.

Determining when a signature is polluted can be difficult, since such judgement is subject to the code's intended use - not it's explicit structure. For example, within an event-dispatch context, an argument signature is expected (if not required) by the handler routines - in order to properly process data from the dispatched event. On the other hand, I discovered that Proxy had a polluted signature, only after using it with a non-conforming routine. Thus, it's the problem-domain which reveals whether the solution suffers from this type of symptom.

The Subtle Condition
To clarify the problem, let's invent a silly function manager. (For arguments sake, I'm reducing the concept of function "manager" to any routine that calls another using the apply or call methods.) Below is an example of such a routine - I've named it "Silly" - which sends secondary information (albiet trifling) to the function(s) it calls (or "manages").

function Silly(fnc) {
  return function () {
   var num = 5,
   rand = Math.random();
   return fnc.call(this, arguments[0], num, rand);
  }
}

You can see that Silly will invoke fnc, passing one given argument while adding two of it's own values (num and rand). The example demonstrates an organic principle of JavaScript functions: argument order connotes primacy. Many function managers take advantage of this principle, in order to distinguish "extra" from "core" arguments, in their calls to external functions. For instance, below is line 870 in attribute.js, of YUI 3's Attribute Object (version 3.3.0).

retVal = setter.call(host, newVal, name);

The line above calls an external function which can (according to their documentation) "manipulate the value which is stored for the attribute." In this case, newVal is the core argument - to be tested and manipulated. However, name is passed after the core argument. Again, the data is passed to support robust functionality, but is definitely not central to functionality.

In and of itself, there is nothing inherently wrong or dangerous in either example. Since it is the problem-domain which reveals the issue, let's now use Silly to create two functions (rather augment two closures). One will reveal when our mandated signature becomes a pollutted signature.

var stringify = Silly(
  function (x) {
   return x + '';
  }
);
stringify(5); // -> '5'

var sum = Silly(
  function sum(x, y) {
   return isNaN(x + y) ? 0 : x + y;
  }
);
sum(5, 20); // -> 10

While the stringify function is fine, the sum function is now broken, or - at least - not working as designed. Because Silly only passes the first given argument, it greatly impacts the output of it's managed routines. Sure, that's not good, but how can we tell which function needs fixing? More to the point: How can a function pass non-critical arguments without impacting the arguments expected by the routines it invokes?

Regarding the first question. Were our example intended to work with any routine, then we can safely state that Silly has failed, and suffers from a polluted signature. However, were there documentation stating the limitations our routine placed on called functions, then our sum function would be the culprit... The line is blurry, because the structure of our code doesn't hint to either intention. Drawing that line in documentation (or worse, comments) is the last place we want to write code. We'd like that line to be self-evident in the code's structure.

Clarifying Code Structure
The problem is that most managing functions attempt to communicate an argument's relevance with it's order; an abuse of the order-equates-primacy principle. That is, the greater the arguments index the less a called routine should consider it within it's logic. This is how our Silly function works, along with earlier versions of Proxy, and (perhaps even) YUI's Attribute Object.

The truth is that there are no secondary arguments in a single arguments object. You might think of it as an overriding principle: all arguments should be useful. After all, arguments exist to impact the logic of a function. Otherwise, what are they arguing for (excuse the poor pun)? Nevertheless, order communicates primacy. With the arguments object, relevance is given by inclusion alone.

While trying to solve this same problem in Proxy - using order alone - I ran through a number of options. (Mind you, my final option was to document it's proper usage, and move on.) I'll sum them up with our example function, below. None of these variations net a less polluted signature in Silly, because all continue to require that called functions use a specific signature. Nonetheless, I've listed them below.

// pass all given arguments as the first argument
function Silly(fnc) {
  return function () {
   var num = 5,
   rand = Math.random();
   return fnc.apply(this, [arguments, num, rand]);
  }
}
// prepend a variable number of arguments
function Silly(fnc) {
  return function () {
   var args = [].slice.call(arguments),
   rand = Math.random();
   return fnc.apply(this, args.concat(num, rand));
  }
}
// append a variable number of arguments
function Silly(fnc) {
  return function () {
   var args = [].slice.call(arguments),
   num = 5,
   rand = Math.random();
   return fnc.apply(this, [num,rand].concat(args));
  }
}

In all cases, the code structure does not communicate the relevancy of the "extra" arguments. In fact, once passed to a called function, attempts to distinguish "core" from "extra" arguments (using order alone) are blurred. Thankfully, there's more to an arguments object than it's values...

Using the Call-Stack
The call-stack is a temporal structure, accessible (oddly enough) via the arguments object itself. Accessed by a jungle of callee and caller properties, any function can reference it's calling function (and it's calling function, etc.) - all via the arguments object.

Each "step" thru the call-stack goes backwards, to a function which is waiting to complete. Each stacked function (like any executing function) has it's own arguments object (containing the values it was initially passed). The farther back one goes, the less relevance that stacked function would have on the logic of the one executing. Thus, the call-stack is a structure for identifying relevance.

By executing a closure, before calling a managed function, and passing it non-critical data, our example function can now work with any routine.

function Silly(fnc) {
  return function () {
   var that = this,
   args = arguments,
   num = 5,
   rand = Math.random();
   return (
   function () {
   return fnc.apply(that, args)
   }
   )(num, rand)
  }
}

Silly now passes all given arguments to the managed routine, which can access the tiered or second-class arguments as it sees fit. Of course, this insertion of secondary (or second-class) arguments in the call-stack will require extracting. Though our old sum routine would now work just fine, it could be recoded as follows, to include the second-class data in it's logic:

var sum = Silly(
  function sum(x, y) {
   var sArgs = arguments.caller.callee.arguments;
   return isNaN(x + y) ? (sArgs[1] || sArgs[0]) : x + y;
  }
);

Conclusions
By using the call-stack, non-critical, execution-only data can be passed to a function indirectly. The routines managed by functions that employ this technique will need to change their logic, in order to access this second-tier of data - or, second-class arguments. However, eliminating polluted signatures, reducing an API's dependence on them, makes for flexible, clearly-structured code with a longer shelf-life.

I've done no performance research on the impact from unnecessarily increasing the call-stack in this manner. I am sure this technique does impact memory footprints and processing power, but suspect it's negligible, compared to the aforementioned gains.

Epilogue

Naturally, second-class arguments have vastly improved the usefulness and expanded the application of my own Proxy code. However, I quickly realized that the process of extracting this data was tasking and bothersome.

Thus, I defined a static method for Proxy, called getContext. The method takes a function's arguments object and does all the long syntax to build object-literal containing the second-class data. So instead of Proxy users having to target index 1 from "arguments.callee...." in order to get the "alias" value, they can simply use this line within the functions given to Proxy.

var alias = Proxy.getContext(arguments).alias;

If you're a library author who uses managing functions, I highly recommend a similar convenience method if you employ this technique!

Proxy and the ES5 (Harmony) Proxy

2011-02-23T11:09:00.000-08:00

I didn't know it then, but Proxy is a native object in ECMA-Script 5 (ES5), the next web programming language. What this means is that I must change the name of my Proxy object to something else - yet to be determined. Moreover, I'm sure there will be inquiries (from all two of you) about the differences and similarities between my Proxy object and "theirs".

Approved in 2009, much of ES5 is supported by several current and upcoming browsers. However, the Proxy object didn't seem to get much attention until mid 2010. To date, FireFox 4 is the only browser supporting the ES5 Proxy API (with their own extensions, natch). Still, it's here and clearly my work's namesake is in the shadows of a looming standard.

Thus, the tangible similarity between ES5 and my work is the namespace "Proxy". An intangible similarity is the overlapping purpose of both objects. Both provide wrappers to "base" objects, for security, simplicity... many of the benefits described in the ES5 wiki for Proxy. Actually, I'm rather glad there is language to describe and capture why such an object is needed in web programming - a difficult task for me. I'll be sure to update my wiki pages to reflect the shared intentions.

Everything else between my Proxy and ES5's is different, however. After all, it's an entirely new language, using constructs unavailable to the environment that my Proxy object was designed for. My work is still a viable alternative to native getters and setters, and will continue to be for older browsers that don't support ES5 - which makes heavy use of these and other new constructs. Must be nice designing a language...

Does my Proxy object do anything ES5's doesn't? From what I've read so far - and I'm not claiming to be an expert, ES5's Proxy is a one-way street. That is, there doesn't seem to be a way to capture the source object - what they refer to as the "subject" - from a given ES5 Proxy. Therefore, one could return a Proxy (of either type), but only mine allows extracting the subject again for further manipulation. My Proxy does so securely, using a signature object.

The hardest part: parting with the name. Obviously, I can't keep calling my object a "Proxy". Granted, the term "proxy" is generic enough. Even after you isolate it to programming, it still has a variety of meanings and applications. I've considered "Alias", "Mirage" or "Mirror" (to flatter AmbientTalk - I think they had a hand with writing/inspiring the ES5 Proxy draft). Of course, I'm open to suggestions from readers.

One driver to change the name, is my latest project: Flow. I hope to present and blog about soon, but know that it uses my Proxy object extensively. In some cases, that project would do better using the ES5 Proxy - assuming better performance and less memory. I'll save discussing that project for another day... First, I'm going to make sure that name isn't slated for another ECMA-Script standard!

Clear options in a MULTI-SELECT field without loops

2010-12-21T13:32:00.000-08:00

If I've published anything that qualifies as a "tweet", this post does. Though I have been busy, it has been a while and I sorely miss blogging. With the holidays all around us, small posts make for published posts.

Perhaps I've never had to auto-select OPTION elements in a multi-SELECT field, but I discovered a simple method for doing so, that was worth noting.

I had a multi-select field and needed to select various options, based on the numeric indexes from another array. Before looping through the array of options (to select), I needed to ensure the form field had no previously selected options present.

Since the options property of a select field, is like an array, I first thought to iterate over them with a for-loop, but then I'd have two loops...

// deselect all options

for (var i = 0; select.options[i]; i++) {

select.options[i].selected = 0;

}

// select the targeted options

for (var i = 0, j = targets.length; i < j; i++) {

select.options[targets[i]].selected = 1;

}

I don't like looping through overlapping collections - such as select.options and then the list of target options... Maybe a nested loop? Well, that means even more wasted cycles, since the browser is processing the same array multiple times.

// loop through all options

for (var i = 0; select.options[i]; i++) {

// deselect this option

select.options[i].selected = 0;

// loop through all targets

for (var q = 0, z = targets.length; q < z; q++) {

// if the option should be selected...

if (i == targets[q]) {

select.options[i].selected = 1;

break; // exit this nested loop

}

So that idea was out - if not, undesired. If your thinking cap is on, you've wondered aloud about the selectedIndex property of the select field. This index is mostly used with single-select fields (aka, the drop-down menu), to dynamically select an option. Happily, it works the same way for a multi-select field, with the added benefit of deselecting all other options.

// select the first option

select.selectedIndex = 0;

// deselect the first option

select.options[0].selected = 0;

// select the targeted options

for (var i = 0, j = targets.length; i < j; i++) {

select.options[targets[i]].selected = 1;

}

So we select the first option (doesn't matter which really), then immediately deselect it. Library authors would ensure there is a zero-indexed option to select-then-deselect, first. Also, I don't know if a repaint or redraw occurs when toggling active options - so you might hide it via css before doing all of this.Though we do loop through an array next (to select certain options), we avoid the initial/nested loop scenario. Pretty simple!

Yes, the solution takes less time than writing a blog post. I needed to get back in the swing of things (or I'd never blog again). If the new year is kind and time permits, I hope to blog about my next adventure into open-source this January!

Happy-everything all!

Learning to Open-Source via Proxy

2010-09-12T17:22:00.000-07:00

The Internet is a relentless, fast-paced, consumer of content, and I'm a bit of a recluse. My engagements had been brief and trifling; irc chatting, a blog comment here, a forum post there. Then, as a test use of github.com - a popular code-sharing service - I published Proxy. It was my debut in the open-source JavaScript world¹, and I was determined to see it through to the end. However, in the reverse time-warp that is the Internet, I've learned that the end never comes...

So here you are, now, reading about code I'd rather move past. "Now" could be the day I posted this article, but it's more likely some months or years later. Admittedly, I promised to discuss Proxy, and my efforts to document it, in an earlier post. Now felt like a good time.

Introducing Proxy

Proxy allows you - the JavaScript developer - to share and use privileged objects easily. (A privileged object has functions that execute within a scope different from the current one.) Proxy began within a larger project that has a public API of privileged objects. Each privileged object uses getter and setter styled methods to manipulate it's private-object counterpart. As I optimized and refactored that code, a pattern emerged for defining these getter/setter methods, which is now employed by the Proxy constructor.

Before I continue, it's important to note the differences between Proxy and native getters and setters. First, the native option uses a recent JavaScript construct - supported by all modern browsers except Internet Explorer (natch). Syntax aside, they also have different applications. The native method is designed to mask an object's individual properties, while Proxy is designed to mask the entire object. With a compliant browser, you can do the latter with the former, but not vice-versa. Ultimately, given their distinct application, I won't compare these two in this article.

To be clear, Proxy is nothing new or unique. But that's because creating versions of objects - or proxy-like objects - is also not new or unique. If you were tasked to create proxy-like objects in code, it might go something like this. Define a function that makes an object literal that has methods to get and set properties of some source object. Here's an example, below.

Simple enough, and there is already a perceptible degree of repetition in the defined methods. If you had to do this for more than one property, you might refactor it like below.

Proxy takes this one step further, by identifying three phases of our getter and setter functions: get, vet, and set or GVS. The get and set phases isolate when a getter/setter retrieves or assigns a value. The vet phase isolates when a setter function is validating a value, before assigning it to the source object's property. With this abstraction, we can describe each phase of our getter/setter function with an object. Proxy uses an indexed array, called a GVS array, where each index corresponds to each phase - the first is the "get-index", and so on. Proxy accepts and compiles GVS arrays, so they execute like traditional getter/setter methods.

Each index can be a string, function, or any other truthy or falsy value. When the get and set indexes are strings, they reference the source object property to retrieve and assign, respectively. When the vet-index is a string, it specifies the object type required in order to set a value. [The next version of Proxy will accept an array of object types.] For the sake of comparison, below is a traditional proxy-like object, with a same-name setter/getter function that retrieves property "x" and accepts a number for property "y", and the same function described as a GVS array in a Proxy constructor.

There are many possibilities for defining simple to complex getter/setter functions via a Proxy GVS array. (The Proxy wiki will be updated to explain all of them.) Of course, Proxy doesn't limit you to GVS arrays, and can accept regular functions as well. However, the efficiency of the GVS pattern is the primary reason I use it, instead of defining proxy-like objects traditionally.

Learning to do it right (next time)

Open-sourcing takes work and a greater commitment than open-source advocates proselytize. Documenting Proxy, improving it, defending it, naming and explaining concepts like "GVS pattern" have destroyed my productivity. Before announcing Proxy, I spent a weeks documenting it (i.e., less than two-hundred lines of commented code). Now, a month later, I've finally come around to blogging about it directly, if not completely.

This post doesn't mark the end of anything regarding Proxy. I've resigned myself to the fact that this code is my baby and always will be. I've begun to integrate Proxy updates into the larger project it spawned from. I also have plans to improve it's documentation and packaging - which will finally include unit tests. I've filed tickets against myself (a highly recommended practice), and plan to add a roadmap to the wiki.

Though Proxy is more than I expected, it's just what I asked for: a trial run at open-sourcing my work. I've de-romanticized the notion of shared code equating to community-supported code. That kind of interest and support comes way down the line, after useful criticism and outright derision. By dragging Proxy (and myself) to higher levels of recognition and professionalism, I'm discovering what it might take to push larger projects, in the future.

¹ Actually, my first JavaScript routine was posted to codingforums.com in 2002. A message-board is not a code-sharing service per se, yet my code remains archived and accessible to this day.

The smallest boolean in JavaScript

2010-08-20T11:00:00.000-07:00

One of my projects has a pretty large API, with lots of methods returning boolean values. At first, I returned 1's and 0's - which are not actual booleans, but are certainly good enough (for most applications). However, for a public API, I knew they would need to return true or false... After making the edits, my file size jumped. Which is how I found the smallest boolean in JavaScript.

JavaScript coders have used boolean variations and equivalents since the language's inception. No matter an object's type, it can be a boolean. They are about the nicest values out there! There are truthy and falsy booleans, primitive boolean values, and Boolean objects - which aren't really booleans, but can be used in boolean comparisons. Then there are JavaScript expressions, which can also be booleans.

My habit with boolean expressions, was to return the inverse of some variable at the end of a function. As in, initialize a boolean flag (that is, any variable with a boolean value), then invert it's value before returning it. This silly function below, illustrates my point.

   function isOk() {
   var notOk = false;
   // do some logic
   return !notOk;
   }

So the boolean expressions I used involved variables, and I'd somehow trained myself to code this way. This wasn't going to work in my project. I didn't have or want variables to flip in all my functions. Nor was continuing to use keywords like true and false. Lastly, I couldn't continue returning 1's and 0's, since they weren't actual booleans.

Then I recalled that numbers are expressions - they're just missing an operator (or have an implied one, for you uber-geeks). When placing a logical NOT operator before any variable (or, in this case, a number), the result is a boolean value! Thus, with two characters, I can express the smallest boolean in JavaScript.

function doAndConfirm() {

if (doThing())

return !0;

else

return !1;

}

For some, there are performance implications to consider. I have not tested this, and frankly assume that a computer won't choke on such a minuscule expressions. However, there is a real readability drawback. Plus, I do confuse sending the number 1 instead of "!0".

Proxy - You've come a long way, baby.

2010-08-17T11:19:00.000-07:00

I began this post three weeks ago and should have published it then. For it has been an exciting three weeks, for me. I'm proud to announce Proxy, my first opensource JavaScript project, is available on github.com. Alas, this post is only about the journey to that destination...

One function (a constructor, to be precise), just under two-hundred lines of code, took one day to code and three weeks to document. Finding my "voice" while documenting, proved the biggest hurdle. I spent an entire weekend writing one paragraph - over and over and over. Of course, there was feature creep - yes, even for a single function. Plus my low self-esteem never failed to remind me of my imperfections, and convinced me delay my debut until otherwise.

Sigh... I certainly broke myself, publishing this code. That "sense of achievement" everyone talks about? If you're like me, it requires overcoming an insidious "sense of failure" first. After so many years of writing code I'll never share, Proxy is the surest sign that I've turned the corner, gained momentum, and hit the bottom... of my excuse barrel, that is! (Ha, ha, ha!)

Seriously, I noticed thought patterns that stopped me in my tracks, causing me to drag myself over procrastination every day. (They are still there). It might take a month or longer to document my next project, but knowing I finished this means I will finish the next. With the utmost confidence, I can say that my wife, Stacy made all the difference. Our life together, and my vision for our future, have changed all my hopes and habits. To Stacy: Thank you, and I love you.

My apologies to those who thought this would be a technical post on Proxy. Or, to those who expected some insight about using github.com. (You were warned.) There is time for that, and I'll be sure to write on both subjects soon. For now, I'm just glad to have something to share.

Use JavaScript comment-urls instead of the traditional void(0) method

2010-07-30T09:00:00.000-07:00

The longstanding compromise, between reducing inline JavaScript and preserving accessibility, has been to use "javascript:void(0)" in link hrefs and form-element actions. These elements and attributes are the hardened fall-back to DOM Level 2 events, and (unlike myself) many believe something must be there. Well the ubiquitous technique has a successor that is new to me. I'm no more excited about it's purpose, but glad something new has come along.

Unlike most of what I post here, I did not learn this technique but rather observed it, while using Mint.com. Instead of invoking the method which returns nothing (actually, void() returns "undefined"), they instead use JavaScript that does nothing, with a single-line comment. These JavScript comment-urls work in all web browser, supporting JavaScript version 1.0.

Wherever you use the JavaScript void() method, like so:
<a href="javascript:void(0)">Do Something</a>

Simply use a JavaScript comment, like so:
<a href="javascript://">Do Something</a>

I prefer this approach because it's a shorter string - taking up less bandwidth, uses fewer threads/cycles, and is poetic in it's simplicity. If you want JavaScript to take over yet do nothing, I couldn't imagine anything less than a comment. Again, I do not generally advocate JavaScript-urls, but feel if you must use them, use this one.

Do share if you've found a JavaScript capable web browser that does not support this technique. Or, let me know why you (too) think JavaScript-urls should not be employed... It's an opinion of mine (which I'd like to avoid on this blog), but I might post about that later.

Saving to buy things

2010-07-26T10:31:00.000-07:00

Remember how your elders would tell you to save in order to save? As in, "this money should never be spent"? Reality check: that's hard to do. Sure, I save money (all I can); I even save to save it. But then I need (ok, want) to buy something, and there goes my savings. That's normal, but the problem is I never spend my money on the reason I'm saving my money.

After discussing finances with my wife - an exciting topic for us both - I ventured online and discovered SmartyPig.com. It's a dream service for penny pinchers, like myself. The site facilitates saving towards financial goals, and provides the literal and proverbial "bucket" to separate your monies.

Now, I already use Mint.com - a financial management service that is entirely useful towards monitoring my spending across various accounts. (Thanks Malaney!) It also offers goal oriented savings, and will track your progress like SmartyPig. The difference is SmartyPig actually gives you an account, a temporary one, to fund your goal. If Mint had this ability (they suggest regular third-party savings accounts), I wouldn't use SmartyPig; but Mint only tracks money.

On top of giving you a bucket to put your money in, SmartyPig rewards long time planners with APY of 2.15%. My wife and I are saving for a home - which takes some time to fund - and that kind of benefit really appeals to me. Plus, I don't have to leave my favorite bank to do it. The fact that my money comes back to my account, means I'm not in bed with SmartyPig longer than I like.

This is not a tutorial on using SmartyPig (the are plenty of tutorials online), just a hearty applause to the digital age. I learned that my money doesn't have to be tied down to a bank or risked in a nervous stock market. Today, I can shop for the things I want and not harm mine or my wife's future finances. Good and finally!

Ah hem, lest I forget... SmartyPig also lets you receive public contributions. See the bottom of my sidebar, if you'd like to try that out! (wink) Many, many thanks in advance!!

Inferring node placement via special sourceIndex values

2010-07-23T09:00:00.000-07:00

I needed to know whether a node was in the DOM. Figuring there was a native property or method towards this end, I scoured Mozilla's documentation but could find nothing. Then Microsoft (yes, them) offered hope with Internet Explorer's sourceIndex property:

Retrieves the ordinal position of the object, in source order, as the object appears in the document's all collection.

sourceIndex (MSDN)

Put simply, this proprietary property holds the numeric index of a node within the "all collection" - an IE construct reflecting everything in the browser DOM. Thus, I wondered what the index would be for nodes in memory; that is, a node not yet - or previously - appended to the DOM.

A quick test proved the sourceIndex property has special values for each scenario:

A value of -1 means the node has never been placed in the DOM.
A value of 0 means the node has been removed from the DOM.*

* While the first case is pretty straight forward, the second (when 0) has an implied caveat. All array-like constructs are zero-based, and there is always a node at the zeroth index of document.all. Therefore, unless you know more about your node, a sourceIndex of 0 could be a false-positive and the node may still be in the DOM.

The generous folks at http://help.dottoro.com added my findings to their sourceIndex reference. Given their due diligence, I feel they've verified the application of my discovery.

I don't feel this proprietary property was intended as a node-placement indicator - hence the title of this blog entry. However, I've used it to great success as one, in a project where an IE only solution was needed (rare, I know).

Finally, for those interested in a cross browser solution, search stackoverflow.com to determine when a node is in the DOM.

w3c browsers fire bubble listeners before capture listeners

2010-07-19T16:11:00.000-07:00

In w3c browsers, the event object's eventPhase property may indicate when it is in capture or bubble mode with a 1 or 3, respectively. A value of 2 indicates that the event object is "at" or processing the target node. However, when the eventPhase is 2, the event's mode is fuzzy.

I discovered this while seeking to branch a handler function's execution based on the mode. My handler not only had trouble distinguishing the mode for the target node, the eventPhase was actually 2 twice. Once at the end of an event's capture mode, and again at the start of it's bubble mode (since both end and begin at the target node). It seems that modern browsers are equally confused.

More often than not, w3c browsers will trigger bubble listeners before capture listeners for the target node - as if the browser too can not distinguish the mode. You can preview this odd behavior in a demo at http://jsbin.com/adena3/2/. As usual, do share your results for your browser(s), as a comment to this blog entry. So far, though nowhere near consistent, Firefox performs as expected for a few form elements.

I doubt this is a bug, but rather it is by design. After all, there are only three phases. To explicitly signal an event's mode and location, as it traverses the DOM, requires four values. Plus, no document requires that browsers execute listeners in the order they were assigned... The problem is that historically, w3c browsers have done a pretty good job of executing listeners in the order they were assigned.

Still, even as a bug, it's one most developers will not encounter. Observing best practices (like event delegation), and considering common interface requirements, few will ever assign a capture listener to a target node. As well, listener order matters less on the target node, since the event is neither capturing nor bubbling at that moment, and thus all listeners would execute. Technically, w3c browsers are not behaving badly.

Thus, my issue is with the addEventListener() method. It's "capture" parameter implies that a given function will execute in one of two modes (capture or bubble), and capture listeners execute before bubble listeners. I fear, when it comes to the target node, passing any capture value to this method, equates to "either".

Internet Explorer doesn't bubble click events to the window

2010-07-14T20:56:00.000-07:00

This is a simple one. I put some sample code on jsbin.com to show how IE doesn't bubble click events to the window, while w3c browsers do. This is important, because I would normally think to use the window as a "global event listener", not the document. Yeah, I learned this one the hard way.

Learning about which browser events bubble to which top level object is critical to my current project. Expect more posts about which events bubble/capture from/to what node/object... Wow, I just wrote put three sentences into one.

Help my research (or research for others) and share your results on various browsers. Just open the demo, click around a bit, and let me know if the click event hit the browser or not. Or, revise my code to test other events and share those results.

Many thanks!

Debug easier by naming your closures

2010-07-14T11:03:00.000-07:00

I was profiling some code when I noticed that several routines were listed as "(?)()" in Firebug, and "JScript anonymous function" in MS's Visual Studio. This proved frustrating, as recognizing my closures were critical to evaluating my code - I couldn't tell which were performing well, let alone executing.

It was burdensome, but I named all the anonymous functions. Hopefully today's JavaScript optimizers and minimizers know enough to remove such useless text (otherwise, I'll have to), but it sure helped my debugging effort.

So, if your code has lines like these:

obj.critical = function () {};

useCriticalFunc(function () {});

You might try naming the anonymous functions, like so:

obj.critical = function criticalMethod() {};

useCriticalFunc(function criticalFunc() {});

Now, you should be able to recognize the closures, in your debugger of choice!

Internet Explorer sanitizes events between nodes

2010-07-14T09:46:00.000-07:00

Events are hard in IE. That is just a fact.

I'm not here to gripe about how IE's event object doesn't adhere to standards, nor offers alternatives. Really, I'm not. This is actually a surprising discovery that has less to do with the standard IE/MS diatribe, and more to do with a unique aspect of their event object.

Of all it's properties, the IE event object allows you to edit two: returnValue and cancelBubble. The returnValue property may be set to anything, while cancelBubble is converted to the boolean equivalent of whatever you assign.

You may add arbitrary properties to the event object, via a handler function. (As with w3c browsers, be careful not to cause an exception by writing to a read-only property.) However, you may not prototype the event's constructor in IE (it doesn't have one). Nor does IE implement the ever-popular hasOwnProperty() method. (Why? That's another post, let alone blog.)

Now after mangling an event object sufficiently (and within the aforementioned limits), how should that object look when it bubbles to the next node in the DOM? Unfortunately, with IE, it will be the same way it began in the previous one. Only the returnValue will retain the previously assigned value. (So would the cancelBubble property, but that doesn't matter since it wouldn't reach the next node anyway.) This behavior is observed in IE 6 thru 8.

IE either sanitizes the event object between nodes, or provides a new one altogether. There is no way I can tell which from looking at the object, alone. But recalling that, causes me to gripe about how the object doesn't have a standard timestamp property, or an equivalent native means to uniquely identify one event object from the next...

Mind you, this does not mean handler functions cannot pass arbitrary properties amongst themselves. The "sanitization" IE does is between nodes (or what an event bubbles through), not the numerous handler functions listening to one.

I might post a demo for this, but it's a tad complicated to prove a negative. Anyway, I discovered this while coding recently, and it blew chunks. Hope my experience helps!

Try, try again

2010-07-14T08:05:00.000-07:00

I've failed miserably at blogging before. Blogging had been a confronting exercise, where I had to impress my readers with coherent arguments and razor sharp wit. Perhaps that has always been the problem, in all my writings. There was a time, when I would take hours to write an email. It had all the burden of a delicate surgery - the patient being a relationship.

This time, I plan to write short posts. Indeed, twitter may be the proper forum for my thoughts. I aspire to more, however, I'm alright with doing less. Even now, while at work, I don't have time to write this post. But I need to begin somewhere.

I'll blog about what I've learned. What sparked this diary-style blog is my current work, in coding JavaScript. I realized that all the places I look to understand how to code well, were also blogs (of a sort). I'd learned things while coding. Why not start a blog of my own?

I do seek fame and recognition - one hopes fortune will follow either. Above all, I want to use what I've learned in future endeavors. Yesterday, I ran into a roadblock because I presumed something about my work, and never wrote it down. That bit me in the arse - ruined the days outlook, in fact.

I'll post on other learnings, which is why coding isn't explicitly in the title. Right now, I've on a mission to be achieve my goals and earn what I deserve. I am writing to you, but for myself. Hope we enjoy the ride!