It's still very much in development and the source is a bit sloppy, but it currently weighs in at only 2.5k compressed and gzipped and (in Firefox3) either outperforms or is on par with all other major Javascript libraries out there*.

It's definitely not ready for production use, but when it is, it will become the new CSS querying engine for Gimme and will also be available as a stand-alone library, which will be extensible (so you can add your own rules) and which will also be guaranteed to play nicely with other libraries by not adding to the prototype of any native objects and only introducing one single global variable (fetch).

For anyone interested, the current (i.e. sloppy) source is available on CodePlex: fetch.js.

As I said, it's not ready for prime time and the code is sloppy (and probably buggy). Consider yourself warned.

* Fetch was not compared with libraries that use XPath or querySelectorAll, because it uses neither, but rather is a pure Javascript implementation. Upon release, it will take advantage of querySelectorAll where appropriate, but will not use XPath.

Won't be long now IE6...

Anyway, since the current beta release of Gimme is "Caspian" I figured I'd do a post today in honor of Gimme and the movie (ok, it helps that I also have something worth writing about too).

So anyway, on to what this post is really about: enhancing Gimme.

Not too long ago, Shaun Inman wrote about his proposal for CSS Qualified Selectors.

It's a good idea; I've actually had the same idea and thought briefly about making it part of Gimme's core CSS selector engine. Only, in my model, I have the left-hand-side and the right-hand-side of the < symbol switched. It feels more natural to me that way, because in most CSS selector rules, you can simply look to the far right of the selector rule and know what type of "thing" you're going to be selecting.

Thus, I feel that this:

feels more natural than this:

But this is just details; the idea is the same either way.

So anyway, after Shaun published his idea, John Resig chimed in and mentioned that jQuery supports this already via pseudo :has(..).

Well that's pretty cool, but since Gimme is my library, naturally, I feel compelled to make sure it stacks up against the competition, so I thought to myself: "self, can Gimme do this?" to which a mental reply came back "No, remember? You decided no to implement it."

And I would have just left it at that, because after all, I decided not to implement it for a reason (and I figured that's where I would leave it).

But then, today, my officemate surprised me by asking "Hey, I have a question about Gimme. I'm working with a page where I need to select a <table> element that has an <h1>. Can Gimme do this?"

Well crap! What are the odds that this would come up again so quickly?

Not being one to disappoint, I said "You know what? I decided not to implement it, but I did put significant effort into making Gimme's selector engine extensible. I bet we can write an extension really easily."

So a few minutes later, we came up with this little gem:

Which means you can now use Gimme to do something like:

Unlike what John did, I didn't bother to map this back to the < symbol. I thought about it, and you could do it easily enough, but the more I think about it, the more I like how :has(..) reads.

It's not likely that I'll make something like this part of the core Gimme library unless it start popping up everywhere. It comes up occasionally, but not enough to warrant making it part of the core (at least, not enough in my personal experiences so far anyway).

So there ya go! Think of this as edition 1 of "Gimme can do that too" with (hopefully) many more editions to come.

Comments welcome.

See the archives where my design is listed, or view my design, Coffee Break, directly.

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!

Read on to learn more.

I'm going to call my function getElementsByClassName(..). In order to write this function, we'll need to leverage another, native ECMAScript function: .getElementsByTagName(..). I trust everyone is already familiar with how that function works. If not, there are plenty of resources on the web that can help you — I'm not going to get into that here.

The getElementsByClassName(..) function will take three parameters:

1. _className: (required) A regular expression (or a string) used to match the desired class name(s).
2. _startElem: (optional) The element at which you wish to begin the search; default = 'document'.
3. _filterTag: (optional) The tag name you wish to limit searches to; default = '*'.

The decision to use a regular expression instead of just a simple string might not be obvious; let me explain.

Since DOM elements can have multiple classes specified (simply separate them by a space), a direct string-to-.className comparison would not be very flexible. Suppose, for example, I want to retrieve all elements that have the className: 'animal' and 'dog'. You might think would be as simple as passing in the string 'animal dog', but that may not work. The element's .className property could very well be 'animal poodle dog', in which case that string comparison would fail, but the element does indeed have the classes 'animal' and 'dog'.

Clearly we need something more robust. Enter regular expressions!

If our getElementsByClassName(..) takes a regular expression, we now have a great deal more flexibility. We can query all elements that have classes 'animal' and 'dog' but not 'poodle' (something that would be darn near impossible with a straight string comparison).

Still, we don't want to force the average person to have to write a regular expression just to use this function, so we'll also allow plain old strings to be passed in, and when that happens, we'll simply generate a stock regex that works for 99% of cases.

The second parameter, _startElem, is to increase efficiency. There is a good chance that you don't want to query the entire document for elements with a particular class name, but that you want to confine your query to some parent element. This optional parameter allows you to do that. If this parameter is not specified, it will default to the entire document.

The third parameter, _filterTag, is also to improve efficiency. You may only be interested in querying a elements of a specific tag name. It would be silly then to query all elements if you're only interested in say, <span> elements. If this parameter is not specified, it will default to all elements ('*').

Now that we have the basic design for this function, we can go ahead and write it.

Here is the full code for getElementsByClassName(..) with the explanation of any tricky code to follow.

Most of this function is pretty self-explanatory, but two things require explanation.

The above code ensures default values for _startElem and _filterTag. It does this by leveraging the fact that, in ECMAScript, all variables are variant type, and that ECMAScript uses short-circuit evaluation.

It boils down to this: when assigning a variable using logical OR ( || ), the variable's value will be equal to the value of the first variable that evaluates to true in an if conditional. Since this is going to be the subject of a future blog entry, I'm not going to go into any additional details here. All you need to know for now, is that if either _startElem or _filterTag is unspecified, each will receive its proper default value.

The other piece of code that requires some explanation is:

The really tricky part about this is that it's not obvious why we need to do it.

The problem is, IE (less than 6) supports .getElementsByTagName(..), but it doesn't support passing in the universal selector to that function (the value '*'). Since all modern versions of IE support .getElementsByTagName(..), but they don't all support the universal selector, we have something of a problems here.

We can use [DOMElement].all in place of .getElementsByTagName('*'), for IE, but the fact that .all exists doesn't necessarily tell us we're in IE (Opera supports .all too).

Fortunately, .all is sufficient for what we're trying to do, so it doesn't really matter if we're using IE5, IE6, IE7, or Opera (or even some other browser that supports .all that I don't even know about).

So, if the browser supports .all we'll use that. Otherwise, we'll use the W3C standard's .getElementsByTagName('*') instead.

With all of that sorted out, our tags variable should now be an array, appropriately populated with DOM elements that the rest of the code will filter based on class name.

Everything else in the function (including the filtering loop) should be fairly easy to understand. The only thing left to do now is show a few samples of how to utilize it properly.

I don't think this requires much explanation. It's basically just some samples of .getElementsByClassName(..) in action.

One thing you'll note is that I didn't bother to use any regular expressions here. I simply pass in strings and let our function use its stock regex for me. I could have however, passed in a more complex regular expression if I really wanted to.

If you're not too familiar with regular expressions, that's okay, but if you are, then that extra knowledge may go a long way towards helping you get the most out of the .getElementsByClasName(..) function.

Well that wraps up this entry. It was long I know, but it's a super-useful function and a great addition to any ECMAScript library.

Comments welcome.

If you need a quick refresher… javascript doesn't allow you to access arbitrary style properties of a DOM element via .style unless you've previously set that property using javascript OR if you've defined the style using an inline style attribute of the DOM element.

This is where CSS Computed Style can really come in handy. By retrieving an element's computed style, you can retrieve style properties just as they were when you defined them in your CSS file (regardless of whether or not you've ever set them in javascript).

But there's a gotcha (isn't there always). If you remember, IE doesn't really support computed style. Instead, IE offers .currentStyle which, while similar, is most definitely NOT the same thing.

Perhaps the most inconvenient shortcoming of .currentStyle is the fact that it fails to normalize all units to pixels, as the W3C recommends.

In this blog entry, I'm going to explain how to write a function that will convert these non-pixel values to pixels for you.

Read on to learn more.

Writing a convertToPixels(..) function is actually rather tricky. When I first set out to do this, I failed to account for the fact that many of the units we deal with in modern CSS are relative units. For example, em, ex, or % are all units that have no meaning without context.

As you'll see shortly, this has serious implications for the technique I'm going to use for this function.

The basic concept:

The basic concept for this function is fairly simple. We'll pass in a string to our function, something like '5em' or '12pt'. We'll then create an invisible <div> element, set either its height or its border, add it to the page, and then measure it using .offsetHeight to get a pixel value.

The full code for the function is below, with an explanation to follow:

The first thing you should notice about this function is that we first test whether or not the string that was passed into the function is already in pixels units (i.e. it ends with 'px'). If it does, we'll simply return that value right back (no sense "converting" what doesn't need conversion.

Next, we create a <div> div element and set a number of style properties:

• .style.visibility to 'hidden' so that this element never shows up on the page.
• .style.position to 'absolute' so that the element won't shift other elements around on the page.
• .style.lineHeight to '0' because IE will add mysterious white-space to our element that will throw off our measurement if we don't.

The next part is a little tricky. If the units we're trying to convert have been specified as a percentage, then we need to set the height of our invisible <div>, and adjust the _context element to be .parentNode of the _elem that was passed in (% generally always means "percent of the parent element"). However, if the units are anything else, then it's best to leave our element's height as 0, and set it's top border only.

Why? Well, trying to set the border of an element as a percentage isn't going to work. You might think then, that we should just use the height technique all the time (I thought that at first). The problem with this however, is that IE seems to think the a non-specified border is 'medium'. Trying to set the height of an element to 'medium' isn't going to be very useful.

The long and short of it is this: A border can be almost anything (px, em, ex, pt, a keyword, like 'medium' or 'large') but it can't be a percentage, so if we're dealing with a percentage, it's best to set the height and leave the border alone.

Now, if the unit is not a percentage, then we'll use the border technique. This means setting the element's top border to the specified value and explicitly setting the bottom border to 0 (we're not interested in the right or left borders so we can safely ignore them). We also need to remember to set the border style to 'solid' or else this technique won't work as expected.

We're almost ready to measure our invisible element, but there's one thing we must do first.

If the units we're trying to convert are relative units, then the equivalent pixel value depends upon context. In other words, '10%' when specified on an element that is 200px would be 20px. But that same '10%' when specified on an element that is 500px would be 50px. If we want the right value, we need to consider this context.

That is why convertToPixels(..) takes an optional second parameter, _context. If this parameter is not specified, we'll default to the <body> element, but if it is specified, we'll use it.

The preceding line of code ensures that the _context variable won't be null (and thus wreak havoc on our function).

Finally, we append the element to the _context element, measure its .offsetHeight, remove it from _context and then return the value we just measured.

Why add the + 'px' to the value you ask? Well, the major goal here is to make the cross-browser getComputedStyle(..) function we wrote to act more like a W3C style function when used in IE. Since W3C browsers would return the value with 'px' tacked on to the end, we'll go ahead and do this manually in our function so that we remain consistent.

Now that our convertToPixels(..) function is complete, it would be good if we modified getComputedStyle(..) to take advantage of it.

We'll do that in Part 2.

The above code snippet will grab a reference to the element on the page whose id is myDiv, and modify that element's .left css property to '10em' and its .backgroundColor css property to '#369'. Nothing earth-shattering here.

Conversely, javascript programmers are often dismayed that the following may or may not work:

Notice that I said may or may not work. In what cases will it work and it what cases won't it work? Glad you asked (because the answer is easy). Read on to learn more.

Trying to retrieve the a css style property via javascript will only work when that style property has previously been set via javascript OR when that style property was defined inline by using the style attribute in (X)HTML. Now this doesn't do you much good if you haven't first set said css property in javascript (and I certianly hope no one is using inline css styles), and you still want to retrieve it via javascript.

Enter Computed Style.

What is computed style exactly? Well, according to IE, nothing at all. IE (not surprisingly) doesn't support the W3C DOM standard for retrieving an element's computed style. IE instead uses a proprietary .currentStyle property. Once you're familiar with both implementations though, writing a cross-browser solution isn't too difficult.

This function isn't too hard to think about. We start by checking for the existence of IE's proprietary .currentStyle property. This violates my normal rule of always trying for W3C properties first, but since the namespace chain for .currentStyle is shorter, it requires less type checking (document.defaultView would fail in IE as would document.default.getComputedStyle).

Once we've determined what browser capabilities we're dealing with, we go head and assign the proper value to the variable, computedStyle. At the end of the function we simply return computedStyle[_style].

Being able to retrieve a css style property value as it was initially set in a stylesheet is a useful thing indeed. A basic understanding of computed style and the cross-browser function we developed in this blog entry should go a long way towards solving the some of the problems that were discussed at the beginning of this entry.

Also, if you're interested in finding the height or the width of an item (including borders and padding), you're better served with myElem.offsetHeight and myElem.offsetWidth. Those properties will return an integer representing the height or width of the the element (in pixels), and it's best to stick with those properties (as opposed to using the computed style) if you need height and/or width.

As a final note, it's important to realize that retrieving the .top and .left style properties of some element on the page, using our cross-browser getComputedStyle(..) function is not the same as computing an element's absolute position on the page. The former is simply returning a value that was previously set on said style property, while the latter is actually calculating an element's position (sometimes via recursion, sometimes simply by looping). If you're wondering how to calculate an element's position on the page, well… that's another blog entry

But feel free to send comments about this blog entry!