It also affected the Microsoft Virtual Earth MapControl, so if you use the VE MapControl for a mashup, your Firefox 3 users are going to be affected by this issue.

The issue? It has to do with a mouse event's .pageX and .pageY properties. The values of those properties are supposed to report the "page" position of the mouse cursor, relative to the upper-left corner of the HTML page. You can think of it as the absolute (x,y) of the mouse cursor.

The nice thing about .pageX/Y is that serves as an easy way to get the mouse position, regardless of how much (or even if) the browser window is scrolled.

Contrast .pageX/Y with .clientX/Y: the latter reports (x,y) coordinates relative to the upper-left corner of the browser window, so these values will be affected by browser scroll position.

Anyway, at this point, you're probably thinking that I'm going to tell you that Firefox 3 reports the wrong values for .pageX/Y, and that that's the bug. It's not that simple though (again, I admit this is a somewhat obscure bug).

Most of the time, Firefox 3 reports the right values for .pageX/Y, but there is one case in which it doesn't.

Manually Dispatching Events in Javascript

A while back, I wrote a post about Re-routing events in Javascript. In it, I explain how to create an event and initialize it with myEvt.initMouseEvents(..) (which takes a boat-load of parameters).

Of all those parameters sent into .initMouseEvents(..), 4 are of particular interest: .screenX, .screenY, .clientX, and .clientY.

Notice that .pageX and .pageY are not in the list. You don't get the ability to pass in .pageX/Y when manually creating/dispatching an event in Javascipt. Presumably, the values for these properties are computed based on .clientX/Y and the browser's scroll position.

So for example, if you initialize a MouseEvent with .clientX = 200 and .clientY = 300, and if the browser is scrolled 50 x 75, then your event's .pageX and .pageY values will be 250 and 375 respectively.

Oops! I mean, that's what the values should be.

The Bug

Firefox 2 actually gets it right, but Firefox 3 doesn't.

When you're manually dispatching a MouseEvent in Firefox 3, the .pageX/Y property values will always be equal to the .clientX/Y values, regardless of browser scroll position.

As I previously mentioned, this affects the VE MapControl, so it's easy to see the issue in action. Just use Firefox 3 and point your browser to http://maps.live.com. Now make your browser window small enough to cause scroll bars to appear. Scroll the browser window by some amount (doesn't matter how much) and try panning the map. You should see the map "jump" during the initial pan. The amount it "jumps" is going to be equal to the amount by which the browser window is scrolled.

The Fix

Microsoft has a work-around for this issue that is going to be released with the next version of Virtual Earth, but if you're a mashup dev using the VE MapControl, I've got a solution that you can use right now, and it goes like this:

Just include the preceding code snippet anywhere in your HTML page. The code is pretty straight-forward and just relies on the fact that Firefox (and others) have the ability to define getters through the use of .__defineGetter__(..).

The .pageX/Y properties are read only, but it turns out that the browser will let you redefine these getters, thereby overriding their return logic. Since the .clientX/Y properties appear to always report the correct value, all we have to do redefine the .pageX/Y getters to use a combination of .clientX/Y + .pageX/YOffset.

In other words, we've redefined .pageX/Y to always return the position of the event (in our case, the mouse cursor since we're dealing with MouseEvents), relative to the upper-left corner of the browser window + the scrolled position of the browser -- what it should have been all along!

This code doesn't hurt IE, as it won't execute in that browser, and it doesn't hurt Firefox 2 or other browsers that understand the code either, because the logic we've defined for the getters is going to be essentially the same as what the browser would have done natively anyway.

I'd like to file a bug to Mozilla on this issue, but I haven't a clue as to how one goes about doing that. If anyone knows (or wants to do it for me), feel free to speak up!

Enjoy the fix!

Comments welcome.

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!

Besides the new theme (on Windows) being a little bland, FF3 does not disappoint!

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.

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.

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.

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.

Such is the case with two non-standard (but rather convenient) events that IE exposes: mouseenter and mouseleave.

The mouseenter and mouseleave events are similar to the more familiar mouseover/mouseout events, but with one important difference:

The mouseenter and mouseleave events don't bubble.

Now you might think then, that duplicating this effect is just a matter of stopping event propagation in non-IE browsers, but it's actually more complicated than that.

Read on to learn more.

To help illustrate more clearly what mouseenter/mouseleave allow you to do, consider the following:

In the preceding example, the function, myFn(), will execute each time you move the mouse cursor into #theList, but it won't execute when you move the mouse cursor in or out of the child list items that belong to #theList (something that it would do had we used the mouseover/mouseout events instead).

As I mentioned previously, the major different between mouseenter/mouseleave events and mouseover/mouseout events is that the former don't bubble. And this is really what makes the events useful. In our example, the child list items of #theList still receive the mouseenter/mouseleave events (even if you aren't listening for them) but the events won't bubble up to their parent <ul> element.

Of course you could achieve this same effect in non-IE browsers by stopping event propagation, but not by stopping it on the #theList (which is the element to which you'd be wiring up the mouseover/mouseout events).

No, you'd have to utilize .addEventListener(..) for each child element of #theList, hooking up functions to the mouseover/mouseout events that would take care of stopping the events from propagating (in this case bubbling) up to the parent element, and that would be a royal pain (not to mention that you might want the mouseover/mouseout events to bubble up for some (unrelated) reason).

A better approach would be to write a cross-browser addEvent(..) function that knows how to treat 'mouseenter' and 'mouseleave' as valid events.

Here's the code to make it happen, with the explanation to follow.

Several things to notice here:

First, if the browser supports .addEventListener(..) we need to do a little extra work to support mouseenter/mouseleave.

But (and I can't stress this enough), this concept is absolutely flawed! We're assuming that if the browser supports .addEventListener(..) then it must not support mouseenter/mouseleave.

While this happens to be true at present (to the best of my knowledge) it's unwise to assume that this will always be the case. The problem is, there is no (highly reliable) way to determine whether or not a browser supports a particular event (at least not that I know of). I'm okay with this approach for now, only because we're writing the code in such a way, that even if a browser did support mouseenter/mouseleave, our custom implementation of it shouldn't cause any major problems.

Second, you'll notice that when we wire up the event handler, we don't directly use the _fn variable that the user passed in. Instead we use it indirectly by proxying it through the mouseEnter(..) function.

Third, note that we call the same mouseEnter(..) function regardless of whether we're dealing withing with mouseenter or mouseleave. Remember though, that mouseenter/mouseleave are just "psuedo" events (if you will). The actually events we're wiring up are mouseover and mouseout which, in our function, map to mouseenter and mouseleave respectively. This allows us to use one function to handle both events.

Fourth, the mouseEnter(..) function returns a function. I talked about this a while back in post about closures, so I won't go into a lot of detail here, but I did feel that it was wort pointing out in case you hadn't noticed.

The mouseEnter(..) function:

The mouseEnter(..) is where half the magic happens (the other half being in the isAChildOf(..) function (which I'll get to shortly). The .mouseEnter(..) function basically just "intercepts" mouseover or mouseout events and "decides" whether or not to dispatch them (by invoking _fn through the use of the .call(..) function).

It does this by obtaining a reference to the related target. In the case of mouseover, the related target would be the element being moused from, and in the case of mouseout, the related target would be the element being moused to.

Once we know the related target, all we need to do before calling the actual function is make sure of two things:

1. That the related target is not child of the element to which we wired up the event (that would be the this element).
2. That the related target is not, itself, the element to which we wired up the event

Number two in the above list is easy. We accomplish by just checking: if (this === relTarget). Number one is slightly more difficult, so for that one, we call on the help of another function: isAChildOf(..).

The isAChildOf(..) function:

As its name imples, isAChildOf(..) tells you if one element is a child element of another. Simply pass in the (suspected) parent element as the first parameter, and the (possible) child element as the second parameter, and the function will return true or false accordingly.

The isAChildOf(..) function is pretty simple. It works by repeatedly setting the _child variable to its .parentNode, thus cycling it up the chain. Eventually, the _child will be either "false-like" (probably null) or it will be equal to the _parent. In either case, we break out of the while loop.

Once out of the while loop, we return (_child === _parent). This works because any element that was originally a child of the _parent element, would eventually be the parent element (as it gets cycled up the chain). Otherwise, it must not have been a child in the first place. Cool!

So if the related target itself, is either the element to which the event was wired up, or if the related target is a child of the of the element to which the event was wired up, we don't want to dispatch the event. Programmatically, we simply return (prematurely) if either one of these conditions turns out to be true. Otherwise, we can go ahead and call the desired function, and we should end up with a very nice mouseenter/mouseleave simulation.

Final thoughts:

There are a few important things to point out before I close with this entry:

First, the addEvent(..) function we wrote here would be a lot better if we merged it with the xb.addEventListener(..) function that was described in the blog entry Fixing IE's .attachEvent(..) Failures. For the sake of brevity though, I chose not to do that here.

Second, our simulation of mouseenter/mouseleave does fall short with regards to the event object's .type property. Since what we're really using under the hood is mouseover/mouseout, any request for _evt.type is going to return either 'mouseover' or 'mouseout', but never 'mouseenter' or 'mouseleave'

Finally, there is one problem I haven't yet mentioned with our implementation here, and unfortunately, it's a doozy!

Since the _fn passed into addEvent(..) is not called directly, but rather, proxy'd through the MouseEnter(..) function, we're unable to remove any event listener that's been wired up as 'mouseenter' or 'mouseleave'... ever!

And boy does that suck! This is a result of the fact that MouseEnter(..) returns an anonymous function, and, as discussed in a previous post, you can't detach anonymous functions.

It's worth noting that this is not a browser-specific problem. All browsers will handle this the same way, even IE (had we been using the closure technique for that browser).

I do have a work around, and it's eerily similar to the event hash concept used in the xb.addEventListener(..) function for the IE branch of code. I'm not thrilled with the solution, and I'm convinced there is a cleaner way. So my intention is to hold off until I figure out what that is.

In the meantime, if anyone out there has an elegant solution that would allow us to detach the functions wired up with 'mouseenter' or 'mouseleave', please feel free to send your comments. I'd be really interested to see how others might attack this problem.

Live demo:

To see a live demo, visit this page.

Comments appreciated!

In my last entry, I discussed how one might achieve something similar to the CSS style rule: "word-wrap: break-word;" in Mozilla-based browsers.

The technique I used to accomplish this centered around using a Mozilla binding to automatically insert an invisible unicode hyphen between the characters of a string contained within any element whose class was set to "wordwrap." With this invisible character in place, Mozilla will happily wrap a long string whenever the element's content overflows its container.

There was a catch with my approach though. I wanted to be able to modify, not only any inner text of a "wordwrap" element, but I also needed the logic of my binding to leave in tact, any HTML that may have existed inside the given element.

The logic I ended up using was to insert the unicode character between each and every character in the element's .innerHTML (including any HTML tags). Obviously though, this would "mangle" the HTML tags thereby making them useless. So, I then added a bit more logic which utilized regular expressions plus a callback function in a .replace(..) call to "unmangle" the HTML I screwed up in the first place.

This worked, but as alert reader, Rich Birkby, kindly pointed out, there is an easier way. A way that, as it turns out, is quite simple to implement and doesn't require "mangling" any of the HTML tags within the "wordwrap" element.

Read on to learn more.

This superior technique (IMO) that Rich informed me of was the TreeWalker. A TreeWalker is a an object that you can create in Mozilla-based browsers that allows you to navigate the document tree.

The document.createTreeWalker(..) function takes 4 parameters which allow you to specify some specifics about exactly how the walker should "do its walking" (if you will). Each parameter is explained in more detail below:

1. rootNode: The node in the document that is to serve as the root node for this tree walker.
2. whatToShow: An integer constant that specifies one of several built in filters for selecting nodes to be included in the tree. Listed below are the acceptable values for this parameter:
   • NodeFilter.SHOW_ALL
   • NodeFilter.SHOW_CDATA_SECTION
   • NodeFilter.SHOW_DOCUMENT
   • NodeFilter.SHOW_DOCUMENT_TYPE
   • NodeFilter.SHOW_ENTITY
   • NodeFilter.SHOW_NOTATION
   • NodeFilter.SHOW_TEXT
   • NodeFilter.SHOW_ATTRIBUTE
   • NodeFilter.SHOW_COMMENT
   • NodeFilter.SHOW_DOCUMENT_FRAGMENT
   • NodeFilter.SHOW_ELEMENT
   • NodeFilter.SHOW_ENTITY_REFERENCE
   • NodeFilter.SHOW_PROCESSING_INSTRUCTION
3. filterFunction: This parameter can be a reference to a filter function. Its purpose is to allow you to filter nodes even further than what the whatToShow parameter can provide. If you have no need for this parameter, simply pass in null. However, if you specify a function, it must accept a single node and return an integer value based on one of the following constants:
   • NodeFilter.FILTER_ACCEPT
   • NodeFilter.FILTER_REJECT
   • NodeFilter.FILTER_SKIP
4. entityRefExpansion: A boolean value that determines whether or not the content of the entity reference nodes should be treated as hierarchial nodes. In most cases, this value will probably be false.

Updating the original code to use the TreeWalker:

For our purposes (emulating the word-wrap CSS property) we won't need to get very fancy with the TreeWalker at all. All we really need to do is traverse the tree of the element that's been bound by our Mozilla Binding. We'll make use of the SHOW_TEXT filter to ensure that we visit only text nodes (and not bother with any HTML elements). This will allow us to insert the unicode hyphen between the characters of text nodes, while leaving in tact all other HTML inside the bound element.

The code would look something like this:

var walker = document.createTreeWalker(_elem, NodeFilter.SHOW_TEXT, null, false);

while (walker.nextNode())
{
   var node = walker.currentNode;
   node.nodeValue = node.nodeValue.split('').join(String.fromCharCode('8203'));
}
 

The above code is really a tremendous simplification from what I had originally written (thanks Rich!). This technique allows us to walk only the text nodes of the bound element (skipping over any HTML tags). That way, we can insert the unicode symbol only amongst the characters of raw text and not have to worry about mangling (and subsequently, unmangling) any HTML tags.

The "Gotcha:"

While the TreeWalker technique greatly simplifies the word-wrap binding code, there is still a caveat that you should be aware of if you plan to use this binding -- or a similar one you've written yourself -- in one of your projects (and this goes for the original version too).

Inserting the unicode symbol between every character in a string is not necessarily ideal. Take a perfectly normal string like "How are you today?" This string already has spaces, and so it will naturally wrap where the browser sees those "soft" spaces. Inserting the unicode hyphen into that aforementioned string doesn't do anything particularly useful, and in fact, it might even be considered harmful.

It's quite possible that you would end up breaking the word "today" onto two pieces: "tod" and "ay" -- clearly not the desired effect. What can be done about this? Well... one option is careful and thoughtful use of the word-wrap binding. Use it only for long unbroken strings of text (like a long URL for instance). Another option might be to modify the code to abort the word wrap if a space is found within the string (far from a perfect approach though).

Another idea I experimented with (but decided against blogging about because of its complexity) was measuring each "word" in the bound element. If any given word were greater in width than the bound element's container, then that word would get unicode hyphens inserted into it. All "short" words were left alone.

This technique did actually work, but it involved recursively adding invisible, cloned elements wrapped in <span> tags to the DOM on the fly in order to properly measure the text. Also, it did not account for a scenario where text should wrap because of a floated element, and this (IMO) is one of the more desirable way to utilize word-wrap. Still, I think the concept has potential, and I may decide to revisit it at some point in the future.

For now though, we have something that gets us close, is relatively simple to implement, and brain-dead easy to use.

If you'd like, you can see a working demo of the updated word-wrap code.

If you're feeling extra adventurous, you can take a look at my word-wrap experiment (take 3) where I try to measure text elements and only insert unicode hyphens where necessary (use this version at your own risk!)

That'll do it for this entry. Special thanks to Rich Birkby for enlightening me about the TreeWalker. Be sure to check our Rich's ASPAdvice blog: http://aspadvice.com/blogs/rbirkby and his Microsoft Downloads RSS Feed.

Comments welcome.

Be sure to check out the follow-up to this post: Word-wrap for Mozilla (take 2). It features a much simplified way of accomplishing the same thing, based on the comments from RichB.

IE has one nice CSS feature that a lot of other browsers lack, which is the ability to use CSS to wrap long words. It's easy to use. Something like this will do the trick:

Firefox lacks this feature, but it does offer some snazzy features of its own. One in particular is XBL.

In this blog entry, I'm going to demonstrate how to use Mozilla Bindings to (sort of) emulate CSS word-wrap. Since the ability to wrap a long series of unbroken characters is part of the CSS3 specification, I do expect to see this in future versions of Firefox. Until then, this is the best I've got.

An outside-the-box solution

For a long time, I didn't think there was really anything you could do about Firefox's lack of support for word-wrap. I figured the best you could do was set your containing element to hide overflowing data (which might be okay, but most likely not).

Just recently though, a co-worker of mine found a web page that explained how you could insert an invisible unicode character (&#8203;) at various points in a string to solve the Firefox word-wrap problem. Since Firefox views this unicode symbol as a valid character upon which to "break" a string (if necessary) it servers as a convenient to way get Firefox to wrap long strings of characters (the symbol remains completely invisible to the end user).

My co-worker first showed me a function he wrote which took a string parameter, inserted this unicode symbol every 5 characters, and then returned the modified string.

This is a good first start, but I wanted something more. I wanted a solution that didn't require me to execute a Javascript function, and I wanted a solution that could handle HTML intersperced throughout the string.

It turns out, that creating a solution that doesn't require executing a Javascript function isn't the hard part at all! In Firefox, this can be accomplished quite easily with XBL.

How does one utilize XBL? Glad you asked!

From the Mozilla Developer page:

Extensible Binding Language is a XML-based markup language to implement reusable components (bindings) that can be bound to elements in other documents. The element with a binding specified, called the bound element, acquires the new behavior specified by the binding. Bindings can be bound to elements using Cascading Style Sheets (CSS) or DOM. One element can be be bound to several bindings at once.

Setting up the binding is pretty easy, so let's tackle that part first:

With the CSS in place, "binding" to the DOM element is trivial: simply set the element's class property to "wordwrap".

With the CSS and HTML taken care of, all that's left to do is write the XBL file. An XBL file is really nothing more than an XML with a specific structure so that Mozilla knows how to process it as a binding. In fact, if you prefer, you can name the file with an .xml extension (like I did), instead of an .xbl extension.

At its most basic, an XBL file takes the following form:

The binding id attribute:

The root element of the file is <bindings>. Within the root element, you'll have one or more <binding> elements, each with its own unique id. Since an XBL file can have more than one binding definition, the id instructs the browser as to which binding we're interested in. Remember, back when we specified the url for the -moz-binding property, we specified the binding id by appending to it, a "#" symbol followed by the binding id (in this case "wordwrap"). So the full url ended up being: "./wordwrap.xml#wordwrap".

The applyauthorstyles attribute:

The "applyauthorstyles" attribute determines whether or not to allow styles from the document on the bound element (other than the -moz-binding). The default value is false, but you're free to change this if you want (or need) to.

The <implementation> and <constructor>

Every binding has an <implementation> element and, within it, a <constructor> element. This is where most of your ECMAScript code will go (in our case, this is where all of the ECMAScript code will go).

With a very basic explanation of an XBL file's structure out of the way, we can now go ahead and write the implementation of our binding.

It's important to note that all of the ECMAScript you write needs to go inside a CDATA block (this an XML file after all). Other than that though, you don't have too many restrictions. In fact, one nice thing about writing a binding, is that you have a great deal of flexibility. Pretty much all of the ECMAScript you're used to writing is going to work inside the XBL file. And to sweeten the deal even more, you've got some nice extras that aren't available in your normal, day-to-day ECMAScript (we'll look at one of them shortly).

Referencing the bound element:

Perhaps the most important thing you need to know (before you can do anything productive in your binding) is how access the bound element. In other words, how do you access the element to which the class (in our case "wordwrap") was applied? Fortunately, it turns out to be brain-dead easy. You simply using the this keyword; that's it!

Once you have a reference to the bound element, you can do most (if not all) of the things you'd normally do with a DOM element. You could, for instance, wire up logic such that a particular function execute whenever the bound element is moused over, as in:

If you put the preceding code inside the <constructor> element of the binding definition, then any time a user moused over the <p> (#myParagraph), he would see an alert saying "The text of this element will eventually be wrapped!"

Making the text wrap:

At this point, it should be fairly clear what the plan of action is:

1. Access the bound element's text.
2. Insert the special unicode symbol between the characters of the string.
3. Update the bound element's text with the newly modified text.

From the instructions above, I've made it sounds pretty simple. Unfortunately, it's a bit more complicated than I let on. I (conveniently) failed to mention that if the bound element's text contains HTML, we need to take extra care not to insert the special unicode symbol into any of the HTML tags (or else we'll end up disrupting the author's markup).

The word wrap code

The code to make this happen isn't long, so rather than try to explain it up front, I'll first show the full code, and then provide an explanation afterwards:

Explanation:

The first thing we do is stuff the bound element (this) in a variable, elem. This is of course, totally optional, but it helps me (my brain is small and remembering what this represents eludes me quickly and frequently).

Next, we add an event listener to the bound element that "listens" for the 'overflow' event (whenever text overflows its containing element). You're probably aware the in typical Javascript, there is no such 'overflow' event. This, along with its counterpart, 'underflow' are just two the many "extras" that you get when writing Javascript in XBL.

The remainder of the code will all take place within the context of the anonymous function that executes on 'overflow'.

Next, we create a regular expression that matches any "mangled" HTML tag (more on this in a bit).

The next three steps are all quite straight-forward. We store the bound element's innerHTML in a variable called, txt. We then call .split('') on that text and store it in the variable, chars. Passing an empty string into the .split(..) function will yield an array of characters representing the string that was split. In other words, each character in the string is now an element in the array chars. Finally, we put all of those characters back together by calling chars.join('&#8203'); and stuffing the result in newTxt. This inserts that special unicode symbol between each character in the array as it joins them back together.

The tricky part:

If you were paying attention, then at this point, you'd realize that any HTML that existed inside of the bound element, just got totally mangled with that last .join(..). statement. Think about it: if the bound element's innerHTML were something like this:

Then after executing the .join(..) statement, the variable, newTxt would now be equal to:

Besides perhaps giving you a head-ache, the above HTML snippet should make you realize that the insertion of that special unicode symbol between every character in the string has a really detrimental effect on the <span> tag.

The solution:

It turns out, that "unmangling" the HTML tags isn't too too hard (just takes some fancy regular expression work). The regular expression, exp will match any HTML tag that has had the special unicode symbol inserted into it. We can utilize this regular expression to match all occurrences of "mangled" HTML tags and (with some help from the .replace(..) function) replace them with "unmangled" versions of the tag.

In order to do this though, we need to make of use a callback function when we invoke the .replace(..) function. When you pass a function reference as the second parameter into a .replace(..) call (as in: myString.replace(regex, myFn)) Javascript will automatically pass the matched string into the callback function for you!

This is an extremely powerful concept. We can now take all "mangled" HTML tag matches and send them through the reconstructTag(..) function. The reconstructTag(..) function simply returns a copy of the string sent into it, but with all occurrences of that special unicode symbol stripped out (thus returning our "mangled" HTML tags to proper form).

With all of these concepts working together, we end up with a string that looks perfectly unaltered to the end user, but which wraps nicely when it would otherwise overflow its container.

See for yourself on my demo page: Word Wrap Binding Demo.

And, to see a slightly more complex example, take a look at my implementation of an ellipsis for Mozilla using XBL: Mozilla Ellipsis.

Final thoughts:

Mozilla Bindings offer tremendous power to the developer. You can do virtually anything with them; the sky is the limit really. In this blog post, we just looked at one example: how to make long, unbroken strings wrap when they would otherwise overflow their container. But we also saw how you can take this further (see the ellipsis demo link above).

Important Warning / Disclaimer!

It should be noted that I have absolutely no idea what kind of effect inserting the special unicode symbol (needed to make this technique work) might have on accessibility. It's an important question. Is that character going to be read aloud by screen readers (what in the world would it say)? Will search engines see it and have no idea what your text represents, thereby hurting your search engine ranking? My fear is that the effect of inserting this character into your string might not be good. But of course, without any real testing, I can't say for sure.

My recommendation would be to use this concept with caution and only when absolutely necessary. A little common sense will go along way towards ensuring you're not bloating your page will a lot of "fancy-just-for-the-heck-of-it" code.

So there ya go! Word wrap in Mozilla. Happy Binding!