I just noticed the other day that his latest post gives some props to my Emulating CSS word-wrap for Mozilla/Firefox blog post, but his version adds some much needed cross-browser support for browsers I neglected.

Nice One, HedgerWow!

The major problem here is that there is only one mechanism available for accessing a CSSStyleSheetDeclaration object and its corresponding CSSRule collection.

And that (rather unfortunate) mechanism is by zero-based index, which means you need to know exactly where in the DOM a particular stylesheet lives and exactly where in said stylesheet the particular rule you're interested in lives.

Needless to say, accessing these sheets and rules by index is risky, since any update to your CSS may require an update to the code which accesses your CSSRule by index.

You might be thinking that one solution is to put the rule (or rules) that interest you in a predictable place (e.g. the very first rule of the very first stylesheet in your page), but even this is risky and error prone (I know; I did it, and it once came back to bite me).

In light of these issues, I wrote a function that, given a CSS selector rule, finds the the corresponding CSSRule (if it exists). Since this is not necessarily a cheap process, the results are cached so that future requests for the same rule are returned in constant time.

The full code is offered below, with explanations of anything interested embedded in comments.

The findCSSRule(..) function

Caveats:

This function isn't perfect by any means -- a few things need to be called out.

1. Specifying media type could be more flexible: I'm just doing a simple indexOf(..) check on the stylesheet's media attribute, which means that if you want to filter by more than one media type, you'll need to specify the comma separated list yourself, and you'll need to make sure you do it in the right order if you want the indexOf(..) check to pass. A more robust solution might be to parse a comma separated string of media types for the user, or to allow the user to specify multiple media types in an array.
2. Memory consumption could be an issue: I don't think it's likely, but if you're grabbing lots and lots of rules, the cache could become large and memory leaks could become an issue (since the cache is created in a closure). I'm not overly concerned about this though -- you can decide for yourself is this is a big deal.
3. No mechanism for handling dynamically created styles: If you happen to load a stylesheet later in page's lifetime (after the initial load) this function is still going to return the unsupported() function, since it does its check once, up front, to decide whether or not accessing stylesheets/rules is feasible. I'm okay with this, but again, you can decide for yourself.

Examples:

Now that the function is written, a few examples are in order. Assume the following stylesheets:

- stylesheet 0 - (media = "print")

div>span
{
   border: 10px solid red;
}

.christmas
{
   background: green;
   color: red;
}

.pascha
{
   background: purple;
   color: yellow;
}

- stylesheet 1 - (media = "screen")

div>span
{
   border: 5px dotted blue;
}

#main div~span
{
   background: pink;
}

Accessing any of the above styles is fairly trivial.

// returns the div>span rule from stylesheet 0
var r1 = findCSSRule('div>span', 'print');
   
// also returns the div>span rule from stylesheet 0 (since media default to empty string, the first stylesheet with this rule will match)
var r2 = findCSSRule('div>span');
   
// returns the div>span rule from stylesheet 1
var r3 = findCSSRule('div>span', 'scren');
   
// returns the .pascha rule from stylesheet 0
var r4 = findCSSRule('.pascha');
   
// returns null
var r5 = findCSSRule('.halloween');
   
// returns the #main div~span rule from stylesheet 1
var r6 = findCSSRule('#main div~span');
   
// returns null (b/c the rule doesn't exist in a stylesheet with media = "print"
var r7 = findCSSRule('#main div~span', 'print');

And there you have it!

Comments, questions, suggestions, complaints? Bring 'em on!

]]> http://blog.stchur.com/2008/04/09/programmatically-accessing-the-css-rules-in-your-pages-stylesheets/feed/ 3 http://blog.stchur.com/2007/11/21/setcapture-with-gimme/ http://blog.stchur.com/2007/11/21/setcapture-with-gimme/#comments Thu, 22 Nov 2007 04:44:01 +0000 sstchur http://stchur.com/blog2/2007/11/21/setcapture-with-gimme/ In my last blog post I talked about how to re-route events in Javascript. It comes in handy from time to time, but some people prefer an alternate paradigm -- one that is probably more familiar to Win32 programmers.

It's called setCapture. It's proprietary, and it's native to only the IE browser (as far as I know).

What's .setCapture() good for?

Put simply, .setCapture() redirects all mouse events to a specified DOM element until a call to .releaseCapture() is made. Why would you want this? I can think of a couple scenarios.

1. Drag n' Drop: you wire up mousedown to some element to start the drag operation, but wiring up mousemove and mouseup on that same element could be problematic -- the user may mouse too fast and your code might not be able to "keep up." Using .setCapture() on said element however, will redirect all mouse events to the appropriate element so that the mousemove and mouseup handlers are guaranteed to execute.
2. Dropdown Menus: you want the next mousedown to dismiss a dropdown menu. A first crack at this might be to wire up mousedown to the <body> element, but if some other element on the page is listening for mousedown and is stopping event propagation, the mousedown may never make it to the <body> element -- .setCapture() will solve this problem.

These aren't the only applications of .setCapture() of course, but they're two of the most common and they're a good illustration of how .setCapture() can be useful.

Gimme's version of .setCapture(..)

Even though Mozilla/Firefox and other W3C browsers don't natively support .setCapture(), Gimme solves this problem by simulating the capability for browsers that don't natively support it. Using Gimme's version is a snap.

// just a shortcut for document.getElementById(..)
var dragElem = Gimme.id('dragElem');

// #dragElem will capture all mouse events until
// a call to Gimme.Events.releaseMouse() is made
Gimme.Events.captureMouse(dragElem);

A simple call to Gimme.Events.captureMouse(myElem) will do the trick (where myElem is the DOM element that should capture all mouse events).

This example, of course, doesn't accomplish anything very useful, but here's an example that's a bit more practical.

This snippet gives drag/drop capabilities to all elements marked with the class "draggable" (it looks long but that's just comments and a big font).

g('.draggable').iterate(makeDraggable);
function makeDraggable(idx)
{
   // variables to keep track of the drag element's start position
   // and the initial mousedown position
   var elemStartPos, mouseStartPos;

   // wire up mousedown to start the drag operation
   // and stop click events from propagating (just in case)
   this
   .addEvent('mousedown', mouseDown)
   .addEvent('click', stopEvent);

   function mouseDown(e)
   {
      // instruct all mouse events to be redirected to the current dragElem
      Gimme.Events.captureMouse(this);

      // prevent the mousedown event from propagating
      e.stopPropagation();

      // create a gimme object from the element being moused down on
      var gObj = g(this);

      // keep a ref to the dragElem's start position
      // and to the initial mousedown position
      elemStartPos = gObj.getPagePosition();
      mouseStartPos = Gimme.Screen.getMousePosition(e);

      // now, hook the mousemove and mouseup events
      gObj
      .addEvent('mousemove', mouseMove)
      .addEvent('mouseup', mouseUp);
   }

   function mouseMove(e)
   {
      // prevent the mousemove event from propagating
      e.stopPropagation();

      // get the current mouse position
      var mousePos = Gimme.Screen.getMousePosition(e);

      // position the dragElem (element's start position + mouse delta)
      g(this)
      .setStyle('top', elemStartPos.y + (mousePos.y - mouseStartPos.y) + 'px')
      .setStyle('left', elemStartPos.x + (mousePos.x - mouseStartPos.x) + 'px');
   }

   function mouseUp(e)
   {
      // instruct Gimme to stop capturing mouse events
      Gimme.Events.releaseMouse();

      // prevent the mouseup event from propagating
      e.stopPropagation();

      // remove the mousemove and mouseup handlers
      g(this)
      .removeEvent('mousemove', mouseMove)
      .removeEvent('mouseup', mouseUp);
   }

   function stopEvent(e)
   {
      e.stopPropagation();
      e.preventDefault();
   }
}

Before I get into an explanation of the code, the following note is significant:

The current version of Gimme (Belisar) doesn't offer Gimme.Events.captureMouse(..). This capability is new to Gimme (Caspian) which is currently in a pre-release state. You can access Caspian now by visiting the Source Code Section on the Gimme Codeplex site, or you can wait for the official release of Caspian, which should be sometime in late January.

Explanation

If you understand Gimme, the code here is really pretty straight-forward.

A mousedown event starts the drag operation by recording the mouse down position and the element's start position. Then, the mouseMove handler ensures that the element moves along with the mouse delta (delta from the mouse start position). Finally, the mouseUp handler ends the drag operation by removing event handlers that are no longer needed and releasing capture.

We prevent events from propagating (bubbling) in all cases, so that we don't get other elements interfering during a drag operation. And we use Gimme's Gimme.Events.captureMouse(..) capabilities to ensure the the mousemove and mouseup events are directed to the appropriate element. Otherwise we risk some other element "stealing" the mousemove or mouseup away from the intended element.

What does this refer to exactly?

Good question; it's the one thing in the Gimme drag/drop code that I can see tripping people up. The this keyword is somewhat polymorphic in Gimme, so what does it refer to exactly?

The answer is that is depends on context. Most of the time in Gimme, you'll be using this inside of an event handler function. In that case, this refers to the DOM element to which the event was wired up. For example:

g('#myElem').addEvent('click', function(e)
{
   // alerts "myElem"
   // since 'this' refers to #myElem in the current context
   alert(this.id);
});

In some cases though, you may want to use the Gimme .iterate(..) function. In that case, this refers to the current Gimme Object being iterated over, not a DOM element, but it's possible to combine both concepts. For instance:

g('#container > .funny').iterate(function(idx)
{
   // here, 'this' refers to the current Gimme Object,
   // which is why .addEvent(..) is okay here
   this.addEvent('click', function(e)
   {
      // here, 'this' refers to the DOM element receiving the click event,
      // so we can access native properties, like .parentNode
      this.parentNode.removeChild(this);
   });
});

In case you hadn't figured it out, the above snippet makes it so that all elements with the class "funny" that are direct children of #container will be removed from the DOM when clicked -- pretty trivial with Gimme.

But this is all secondary to the discussion at hand: capturing mouse events, which, thanks to Gimme, is also pretty trivial!

If you're new to Gimme, check out the Gimme Promo Page and the Gimme Codeplex Page.

You can also download a debug version of Caspian here if you just want to monkey around with it.

Note once again, that an official (and compressed) version of Caspian will be available sometime in late January.

Comments welcome.

]]> http://blog.stchur.com/2007/11/21/setcapture-with-gimme/feed/ 0 http://blog.stchur.com/2007/06/22/introducing-gimme/ http://blog.stchur.com/2007/06/22/introducing-gimme/#comments Fri, 22 Jun 2007 17:08:16 +0000 sstchur http://stchur.com/blog2/2007/06/22/introducing-gimme/ It's been quite a while since I've blogged anything significant regarding Javascript. This is largely due to the fact that I've been spending a good bit of my free time working on an open source project I started, called Gimme.

Gimme is a Javascript Library designed to make performing common tasks, not only easier, but down-right trivial.

What does Gimme look like?

Gimme is remarkably easy to use and was purposely designed to be very readable. Take the following snippet.

g('.moveable').addClass('hasBeenMoved').slideToPoint({x: 0, y: 0});
 

This code snippet grabs all elements on the page that have the class "moveable", adds to them, the class "hasBeenMoved," and then slides the elements (in a nice accelerated fashion) to the point (0, 0) on the page. Pretty easy right?

Believe it not, most tasks in Gimme are this easy (or easier).

Get started with Gimme

• See it in action on the Gimme Demo Page
• Learn what it can do at the Gimme API Reference Page.
• Download the source on the Gimme Releases Page.

Your Feedback

Gimme is still very young, but I'd love to get your feedback. Please don't hesitate to try it out and let me know what you think.

]]> http://blog.stchur.com/2007/06/22/introducing-gimme/feed/ 2 http://blog.stchur.com/2007/04/26/optimize-your-javascript-cross-browser-code-through-branching/ http://blog.stchur.com/2007/04/26/optimize-your-javascript-cross-browser-code-through-branching/#comments Thu, 26 Apr 2007 17:24:20 +0000 sstchur http://stchur.com/blog2/2007/04/26/optimize-your-javascript-cross-browser-code-through-branching/ Dustin Diaz recently published an article outlining seven Javascript techniques that you'd be wise to start using in your scripts. It's a well written article and you should definitely give it read if you haven't already. Whether you're just beginning with Javascript or you consider yourself an expert, Dustin's article surely has something for you.

One concept he writes about that I particularly like is that of "branching." I've never actually heard it called that before, but it's a very sound concept and one that I doubt is being utilized often enough by today's Javascripters.

What is branching?

Put simply, branching (in Javascript) is the use of closures to get the browser to interpret a block of code only one time, when otherwise, it would interpret that block over and over and over again (presumably, each time you call your function).

Why would you want to do this? Because, when it comes to cross-browser code, chances are you have a lot object detection code whose primary purpose is to determine if the browser supports a particular feature/property, like this:

function addEvent(el, evt, fn)
{
   if (typeof elem.addEventListener !== 'undefined')
   {
      // w3c event wire up here
   }
   else if (typeof elem.attachEvent !== 'undefined')
   {
      // ie event wire up here...
   }
}

The above is a very simplified version of a cross-browser addEvent(..) function that takes care of (some of) the differences in event models between IE and W3C browsers. This is all well and good, but consider what happens when I do the following:

var elems = document.getElementsByTagName('div');     // assume 5000 <div> elements returned
var i, len = elems.length;
for (i = 0; i < len; i++)
{
   addEvent(elems[i], 'click', function() { alert('Hi there!'); });
}

Five thousand times the browser is checking: if (typeof elem.addEventListener !== 'undefined')... -- once for each element in the elems array! Gosh, that feels like a waste, doesn't it? Wouldn't it be good if we could somehow tell the browser: Hey browser, once you've figured out that .addEventListener(..) is supported, don't bother checking again for the next 4999 iterations!?

It turns out you can achieve something like this, through the use of branching.

Branching in action

In a sense, branching is a lot like conditional compilation. Similarly to the way you can use #ifdef directives to instruct your C-style programs to conditionally compile certain blocks of code into your executable, branching allows you to conditionally "compile" (as it were) certain blocks of code into your Javascript.

This is accomplished by creating separate functions that contain your cross-browser logic and then wrapping them up inside of another function, which will return the appropriate function when executed. The nifty part though, is that this outer function will only be executed one time (that's the sort of "conditional compilation" part).

An example should help illustrate this:

var addEvent = function()
{
   function ie_addEvent(el, evt, fn)
   {
      el.attachEvent('on' + evt, fn);
   }

   function w3c_addEvent(el, evt, fn, useCap)
   {
      el.addEventListener(evt, fn, useCap);
   }

   if (typeof window.addEventListener !== 'undefined')
   {
      return w3c_addEvent;
   }
   else if (typeof window.attachEvent !== 'undefined')
   {
      return ie_addEvent;
   }
}();   // <= This is the critical part!

In the preceding example, I've separated out the logic for IE and W3C browsers into two separate functions. Those functions have been declared within the scope of the addEvent(), so they're not accessible from outside.

The most critical thing to notice though, is the use of }(); at the very end of the code. It's important to realize what's happening here. We're declaring a function, addEvent, with the code: var addEvent = function() {, and then we're immediately executing that function at the end of its declaration with }();.

What it means for you

This means that as the Javascript interpreter is parsing your code, it will execute the addEvent() function right away, whose logic instructs the browser return one of two functions (but not both)!

The net effect of this is that addEvent will be equal to ie_addEvent when IE is being used, and it will be equal to w3c_addEvent when W3C browsers are being used. In either case, the browser only needed to execute the if-conditional one time. Beautiful!

You can prove to yourself that this works, but simply executing: alert(addEvent.toString()) in both IE and in a W3C browser. Notice that you'll get the proper function for each browser, but that neither function includes any if (typeof blah_blah_blah)... checks.

Conclusion

It's no surprise that this is going to be much more efficient than the original addEvent(..) function, which did not utilize branching. After all, it's 4,999 fewer if (typeof ...) checks for the browser to execute!

This concept isn't necessarily limited to cross-browser code either. Branching can be useful in lots of situations. As always, I'd recommend analyzing your particular situation and determining if branching is going to beneficial for you (chances are, it will).

If you haven't already, be sure to check out Dustin's article. Besides branching, he covers six other useful techniques that every Javascripter should be aware of.

Comments welcome.

]]> http://blog.stchur.com/2007/04/26/optimize-your-javascript-cross-browser-code-through-branching/feed/ 3 http://blog.stchur.com/2007/04/06/serializing-objects-in-javascript/ http://blog.stchur.com/2007/04/06/serializing-objects-in-javascript/#comments Fri, 06 Apr 2007 06:12:06 +0000 sstchur http://stchur.com/blog2/2007/04/06/serializing-objects-in-javascript/ It's worth noting that this post is rather old at this point. I don't use the function listed in this post anymore and haven't for a rather long time. If you are using it and it's working for you, great! But as Ron in the comments sections points out, there are a few issues with regards to strings and special characters. I recommend following the link he posts if your needs merit a very robust version of JSON serialization. I'm leaving this post up though, as I think it's helpful for folks who want to understand the general concept of recursion and serialization.

Recently, in a personal project I'm working on, I came across a need to be able to represent any Javascript object as a string. This isn't a problem since just about every object in Javascript can be represented with JSON (Javascript Object Notation). Every modern browser can parse JSON for you easily enough through eval(..), and Gecko-based browsers even have the ability to reverse the process ("uneval" if you will) and give you back a string representation of an object through a call to .toSource().

If you need this ability in any other browser though, you're gonna have to write it yourself. I needed this ability, so I wrote it (and posted it here for your enjoyment!)

Gecko-based browsers, .toSource():

Gecko-based browsers provide a handy function: .toSource() that you can call on any object in your Javascript code to get back a JSON-like representation of that object.

function Cat(name, age)
{
   this.Name = name;
   this.Age = age;
   this.Speak = function() { alert('Meow!'); };
}

var garfield = new Cat('Garfield', 5);
alert(garfield.toSource());

/* garfield.toSource() yields:
({Name:"Garfield", Age:5, Speak:(function () {alert("Meow!");})})
*/
 

Pretty simple right? You have an object; you want a string. Just invoke the object's .toSource() function.

Serializing objects in other browsers:

Serializing an object manually (as is required by non Gecko-based browsers) requires a bit of recursion. Simple types like integers, booleans, and even functions are trivial to represent as strings. Objects though, are more complicated because they can contain simple types or custom objects (which would need to be serialized themselves). Those "inner" objects could in turn, contain more custom objects, which would also need to be serialized, and this pattern could (theoretically) go on forever.

In practice of course, this pattern will (had better) come to an end. And we can leverage that fact to write a recursive function that will return a string representation (in JSON format) of a given object.

The serialize(..) function:

First the code, then the explanation.

function serialize(_obj)
{
   // Let Gecko browsers do this the easy way
   if (typeof _obj.toSource !== 'undefined' && typeof _obj.callee === 'undefined')
   {
      return _obj.toSource();
   }

   // Other browsers must do it the hard way
   switch (typeof _obj)
   {
      // numbers, booleans, and functions are trivial:
      // just return the object itself since its default .toString()
      // gives us exactly what we want
      case 'number':
      case 'boolean':
      case 'function':
         return _obj;
         break;

      // for JSON format, strings need to be wrapped in quotes
      case 'string':
         return '\'' + _obj + '\'';
         break;

      case 'object':
         var str;
         if (_obj.constructor === Array || typeof _obj.callee !== 'undefined')
         {
            str = '[';
            var i, len = _obj.length;
            for (i = 0; i < len-1; i++) { str += serialize(_obj[i]) + ','; }
            str += serialize(_obj[i]) + ']';
         }
         else
         {
            str = '{';
            var key;
            for (key in _obj) { str += key + ':' + serialize(_obj[key]) + ','; }
            str = str.replace(/\,$/, '') + '}';
         }
         return str;
         break;

      default:
         return 'UNKNOWN';
         break;
   }
}

Explaining a recursive function can be difficult, but I'll give it shot:

The function accepts just one parameter: the object (_obj) to be serialized. If you'll remember, I mentioned previously that simple types (string, boolean, number, etc...) were trivial because they all have an obvious string representation already. Complex types though, are more difficult because they can be made up of additional complex types, which in turn could be made up of additional complex types (and so on).

Of course, this pattern will eventually end; ultimately, everything is made up of simple types that have a string representation. The trick is figuring out how to traverse through this maze of "types within types." Recursion (simply stated: a function that calls itself) is perhaps the easiest way to solve this "types within types" problem.

Recursive functions always have a termination case -- something which causes the function to stop calling itself. Otherwise, the function would go into an infinite loop. In our function, there are actually four different cases in which the serialize(..) doesn't need to call itself:

1. typeof _obj is a number
2. typeof _obj is a boolean
3. typeof _obj is a function
4. typeof _obj is a string

If any of the above four conditions are met, returning a string representation is trivial, so we simply do it.

You'll notice that strings are treated separately from the other 3 types. You'd think strings would be the most trivial case, but actually, there is one thing we must do before returning the "string representation" of _obj when it is of type string: wrap it in quotes. We need to do this, because JSON expects it, and if we ever want to be able to eval(..) the result of a serialize(..) call, we'll need these quotes.

The only other case to deal with is when _obj is of type object. Within this case though, there are two "sub-cases" we need to deal with. The first is when _obj is an Array, or when it has a .callee property (more on that later). The second is well... anything else.

Basic Object Types

Your every-day, run-of-the-mill, object in Javascript can be represented as JSON with:

{ key1: val1, key2: val2, ... }

Where the keys are strings and the vals can be any simple type, or some custom object you've dreamed up. The logic I've used is to simply loop through a given object's keys and build a string of comma delimited, serialized key/value pairs that are wrapped in { and }.

Notice I said serialized key/value pairs. Here, our function is calling itself as it builds the object representation. This ensures that any objects within the object being serialized will also be serialized. If we didn't do this, we'd end up with a lot of strings that looked (something) like this:

{ key1: [object Object], key2: [object Object], etc... }

And that's clearly not what we want. We want those inner objects to be serialized as well, and that's what the recursive nature of our function will take care of for us.

Arrays

When _obj happens to be, not just any object, but more specifically, an Array, we have a better way of representing that as a string:

[ val1, val2, val3, ... ]

The logic I used here is to simply iterate through the array building a comma delimited list of serialized values, wrapped in [ and ]. Arrays in Javascript already have a .toString() function, but we can't use it here; if the Array contains objects, then the result of the Array 's .toString() could end up something like:

[ [object Object], [object Object], etc... ]

Again, not what we want, so we need to make sure we recursively serialize all of the elements in the array.

Arguments (the .callee "gotcha")

There's one bit of code I haven't discussed yet and it deals with the (possible) .callee property of the passed in _obj. It turns out that .toSource() (native function used by Gecko-based browsers) doesn't do anything very useful when called on an arguments object.

The arguments object is an array-like (but not an Array) object that is automatically available within the scope of every function. Unfortunately, no matter what is contained within that arguments object, calling .toSource() on it will always return "({})"

In order to be able to serialize an arguments object then, we need some way to detect it and then treat it like an array. The .callee property is a good choice because arguments objects have it, but other objects (to the best of my knowledge) do not.

In the case of the serialize(..) function, I decided to use the native .toSource() function whenever it was available, unless the object were an arguments object, in which case, I send Gecko-based browsers down the same path as all other browsers for serialization.

Finally, just for good measure, I've added a default case which returns the string UNKNOWN to handle a situation where no other cases applied. Of course, we probably don't want UNKNOWN showing up in the our serialized strings, but it probably won't do much (immediate) harm if it ever does show up, and its presence would be a helpful indicator that there is some case not being met (that probably needs to be).

Conclusion:

What would you ever use a function like this for? Well, In my case, I wanted to use a Javascript object as the key for a hash, but if I tried to do that, Javascript would just represent all of my (different) objects as the same string: [object Object], which wouldn't do me any good. By serializing the object, I can then use that serialized representation as a key in the hash.

It's worked well for my need so far, but I haven't tested it a great deal. If you find any bugs or short-comings, please let me know.

As always, comments are welcome.

]]> http://blog.stchur.com/2007/04/06/serializing-objects-in-javascript/feed/ 29 http://blog.stchur.com/2007/03/28/split-broken-in-ie/ http://blog.stchur.com/2007/03/28/split-broken-in-ie/#comments Wed, 28 Mar 2007 03:40:40 +0000 sstchur http://stchur.com/blog2/2007/03/28/split-broken-in-ie/ I discovered last weekend, something about IE which I had previously never known (probably because I use Firefox/Firebug to write and test most of my Javascript). It turns out that the implementation of .split(..) is broken in IE (for more complex cases). If you stick with the simpler cases when using this function, then you probably won't have ever noticed this. For example, the following works just fine:
var s = 'This-is-a-hyphen-delimited-string';
var split = s.split('-');  // returns  ['This', 'is', 'a', 'hyphen', 'delimited', 'string']

The above code will work in just about every browser under the sun, including IE, but of course, it's the simplest case scenario for the .split(..) function. Many programmers will probably be aware that you're not limited to passing in a string; you can also pass in a regular expression, which IE (mostly) supports, but this is where things can start to fall apart on you (in IE anyway).

Read on to learn more.

The .split(..) function is pretty robust. You can pass in a simple string, which indicates what character (or characters) you want to use use as a delimiter, or you can pass in a regular expression instead of a string. Take the following example:

var s = 'My~Silly.Test-String';
var split = s.split(/~|\.|-/);   // returns [ 'My', 'Silly', 'Test', 'String' ]

In the above example, the string, s will be split by any of the characters: "~", ".", or "-". The regular expression makes this really easy to do. But one thing you'll notice is that the delimiters themselves are not captured. This might not be a problem for you; in fact, you might not want the delimiters captured, in which case no problem. But suppose you do. Suppose you want the result of your split to be:

[ 'My', '~', 'Silly', '.', 'Test', '-', 'String' ]

In that case, you need to modify your regular expression, and unfortunatly, the needed modification isn't going to work in IE. Here's how's you'd accomplish it in most other browsers (it's remarkably easy).

var s = 'My~Silly.Test-String';
var split = s.split(/(~|\.|-/)); // returns ['My', '~', 'Silly', '.', 'Test', '-', 'String']

You'll notice (or maybe not, since the change was so minor) that I didn't have to do much to get the desired result. All that was needed was wrapping the contents of my regular expression in parenthesis, thus indicating a regular expression grouping.

Unfortunately, in IE's implementation of .split(..), it completely ignores the grouping request. So while your result will still be an array split by the requested delimiters, those delimiters won't be included in the array!

So, what do we do when IE won't cooperate with with us? Why, we beat it into submission of course, and here's how.

The .xSplit(..) function

I call it xSplit(..) because it's a sort of "eXtended" version of the native .split(..) function. Anytime I'm writing/enhancing a version of a function that already exists, I like to use the "x" to help my eyes quickly distinguish between the preferred native function and my own custom implementation (actually, I don't really do that; I just made that up now, but it seems like a reasonable idea, so maybe I'll start!).

The xSplit(..) function will work more or less like the native function, with just one small difference: it will only accept regular expressions. Strings won't be accepted; the native .split(..) function for that.

Here is the full code, with an explanation to follow.

String.prototype.xSplit = function(_regEx)
{
   // Most browsers can do this properly, so let them -- they'll do it faster
   if ('a~b'.split(/(~)/).length === 3) { return this.split(_regEx); }

   if (!_regEx.global)
      { _regEx = new RegExp(_regEx.source, 'g' + (_regEx.ignoreCase ? 'i' : '')); }

   // IE (and any other browser that can't capture the delimiter)
   // will, unfortunately, have to be slowed down
   var m, str = '', arr = [];
   var i, len = this.length;
   for (i = 0; i < len; i++)
   {
      str += this.charAt(i);
      m = str.match(_regEx);
      if (m)
      {
         arr.push(str.replace(m[0], ''));
         arr.push(m[0]);
         str = '';
      }
   }

   if (str != '') arr.push(str);

   return arr;
}

Explanation:

The code isn't too hard, but it's worth pointing out a few specific points.

First, I'm extending the native String object using .prototype. I know some people aren't comfortable with this, and if you're one of them, feel free to write a stand-alone function where you pass in a string variable, as well as the regex.

Second, Most browsers actually will capture the delimiter when you use regular expression grouping, so if the client happens to be using a browser that can do it, we'll want to use the native implementation, as it will be much faster. We do it like this:

if ('a~b'.split(/(~)/).length === 3) { return this.split(_regEx); }

The above code does a very simple test in which we check to see if the split of "a~b" on the character "~" returns an array of length 3. If so, we assume support for regular expression grouping with the .split(..) function. Otherwise, we're forced to do this manually.

Now, if we do need to do this manually, the regular expression had better have its global (/g) flag set. Why? Because we're executing a .match(..) on the _regEx later on in the code, and in order for that to match more than just the first delimiter it finds, that global flag needs to be set.

if (!_regEx.global)
   { _regEx = new RegExp(_regEx.source, 'g' + (_regEx.ignoreCase ? 'i' : '')); }

This code first checks to see if the global flag is already set. If so, we're good shape; no need to make any alterations. If not, we'll need to set it. Problem is, the .global property of any regular expression object is read-only, so we must construct a new RegExp using the .source of the original _regEx and manually specify the global flag (by passing in a 'g'). Additionally, we need to make sure we maintain any request in the original regular expression to ignore case, which is accomplished with: (_regEx.ignoreCase ? 'i' : '').

The rest of the logic is pretty straight-forward. We loop through the given string, building, character by character, the strings that will make up the individual string elements in the array to be returned. At each iteration through the loop, we'll test (using .match(..)) to see if the string we've built so far, contains any of the delimiters specified by the passed in _regEx. If so, we need to push that string into the array, but we need to strip the delimiter out of the string before we do (hence the code: arr.push(str.replace(m[0], ''));).

We also need to push the delimiter itself into the array and then reset the str variable back to an empty string.

It should be safe to access m[0] (and not bother with other indices). Since we're testing the match on each iteration, we can expect to receive, at most, one match returned in the m array (even if that match is more than one character).

Final thoughts:

It's worth pointing out that compared to the native .split(..), my implementation is slow! So, whenever you don't need to capture regular expression groupings, stick with the native function. Of course, for browsers that support the feature natively, we'll be using the native .split(..) under the hood anyway, but regardless... if you know you won't need groupings, don't bother with .xSplit(..).

Comments welcome.

]]> http://blog.stchur.com/2007/03/28/split-broken-in-ie/feed/ 5