Archive for the 'javascript' Category

Are you using this?

Monday, June 11th, 2007

As a Aptana fan, it’s time to tout one of its features. (Prerequisite: download the app. It’s a really good IDE that becomes a must-have app if you’re doing anything with RIA or Rails, as they’ve merged RadRails into their larger project.)

In the Aptana perspective of the IDE, click the little yellow triangle with an exclamation point in it, right under the top menu bar on your screen. See a bunch of little yellow triangle icons and bars appear around the document you’re working on? Those are warnings; they show you things your should fix to improve your code and knock out minor bugs (missing semicolons in your JavaScript, missing alt attributes on your images, etc.). Improve your code! Click the yellow triangle!

Working with YUI’s Drag and Drop Utility

Monday, June 4th, 2007

Just for the heck of it, I’ve been messing around with YUI’s Drag and Drop utility. In the past, over on Phondoo, I’d used Dojo’s Drag and Drop implementation, so it took a little bit of work to get used to the YUI way of doing things.

The essential difference in the two is that Dojo’s implementation is more widget-y (if that’s a word) while YUI’s implementation is more customizable. Dojo Drag and Drop more or less works out of the box; with the YUI version, you’ll have to write a bit more custom code to achieve the out-of-the-box Dojo effects. However, because it’s so customizable, you’ll be able to really turn it into an application with a look-and-feel that’s all your own.

Because bulleted lists improve readibility, here’s pretty much exactly what I just said, all bulleted out for scanability:

  • Dojo’s widget-ness– Without any customization, you’ll be able to do a lot more with Dojo’s Drag and Drop. Basically, Dojo’s provided a fill-in-the-blanks kind of implementation, where you create a couple objects, and bang! it all works. With YUI, you’ll need to write more code.
  • YUI is more customizable– YUI’s Drag and Drop API has a lot more exposed, especially in regards to event bubbling: you’ll be able to access more points in time during an interaction cycle with YUI.
  • YUI has a more open API– You have a lot more access with the YUI drag and drop API. Event bubbling aside, you can more easily customize (or choose not to implement) pieces of the Drag and Drop cycle, which leads to code that fits your situation better.

Which works better? Well, if you’d like to get up and running right away, Dojo’s widget-y implementation is your choice. If you’re not afraid to write some code, YUI will give you a more robust, customized solution. In all, once you’ve gotten used to (and learned to enjoy and take advantage of) YUI’s event bubbling you’ll find that these hooks can make all the difference in your application (they provide many more opportunities to have your code do something when it needs to be done). Both implementations are very nice, work very well, and, although I’d give YUI the edge, come recommended.

technorati tags:, , , ,

Working with FireFox 2.0’s Built-in Spellcheck

Tuesday, May 15th, 2007

FireFox 2.0 has a pretty nice little built in spellchecker. By default, FF 2.0 spell checks <textarea>s. It doesn’t spell check <input>s with type="text". I’m not really sure why, but that seems to be the default behavior when I was mucking around with form elements.

A quick examination of the HTML elements themselves reveals that FireFox attaches a custom attribute called "spellcheck" to our textarea. "spellcheck" accepts a boolean to determine whether or not it will actually be used. Go ahead, create a textarea with the attribute spellcheck="false". No more spell check.

Adding FireFox spellchecking works the same way. Just give an element the "spellcheck" attribute and set its value to true (or anything that evaluates to true). FireFox 2.0 now will correct the spelling of that element, provided it’s an HTML element capable of capturing input. (I tried adding it to other non-form elements, and, unfortunately, it didn’t work. A little script that flicked on spellchecking when you were developing a page would be great, but it doesn’t look possible as only input-related tags are covered.)

technorati tags:, ,

onbeforeunload - Blocks Caching?

Wednesday, April 25th, 2007

Here’s one I hadn’t seen, via Ajaxian:

  window.onbeforeunload = function () {
  // This fucntion does nothing.
  // It won't spawn a
  // confirmation dialog
  // but it will ensure that
  // the page is not cached
  // by the browser.
  }


Just having an unbeforeunload event handler — regardless of whether or not it actually does anything, regardless of whether or not you spawn a dialog box or not, even if the entire function declaration consists entirely of just { } — just defining an event handler will prevent the page from being cached — ever. As a matter of fact, even if you allow page caching, the page will be not be cached. Having an onbeforeunload event means the page will be re-built every single time it is accessed. Javascripts will re-run, server-side scripts will be re-run, the page will be built as if the user was hitting it for the very first time, even if the user got to the page just by hitting the back or forward button.

Ajaxian

technorati tags:, ,

Tables and innerHTML

Thursday, April 19th, 2007

I screwed up, and I learned: don’t try to write to a table’s innerHTML property.

# A table’s innerHTML property should never be used to modify a table, although you can use it to write an entire table or the content of a cell.# If DOM Core methods document.createElement and element.appendChild are used to create rows and cells, IE requires that they are appended to a tbody element, whereas other browsers will allow appending to a table element (the rows will be added to the last tbody element).# There are a number of other convenience methods belonging to the table interface that can be used for creating and modifying tables.

Gecko DOM Reference:Examples - MDC

Rather than risk a little slowdown with DOM methods (I was creating potentially hundreds of rows and cells), I just used a div and injected a full table into that. But, I learned my lesson.

technorati tags:, ,

When can you query the DOM?

Tuesday, April 10th, 2007

There’s also been discussion in the blogosphere about window.onload, DOMContentLoaded, and defer. In short, the window.onload event fires after all of the page’s content has been loaded: DOM, images and all. But what if you want to execute your script when just the DOM loads, without waiting for everything else?

Yahoo! (well, Dean Edwards did first with their latest YUI release.

What’s the best way to do this? Well, I’ve been handling this on a case-by-case basis.

  • Can my script wait until window.onload fires? If it can, then I’ll use that. Why? There’s no need for the extra overhead of polling when I can wait for the window.onload hook. (Now, I’ll probably use YUI’s onContentReady
  • Do I need to work with an element as soon as it’s in the DOM? I had been handling this by placing a >script< block directly after the element in my markup. It works, but it’s not as clean as YUI’s onAvailable method, which I’ve been using more and more often as I’ve gotten further into using the YUI library. In this case, polling the DOM makes sense and my markup remains a little cleaner.

Encapsulating these events with a library may not seem like the most intuitive thing to do (after all, most of the things these libraries encapsualte are one-liners or quick functions that are fairly easy to write). However, a library like YUI brings you more options than the code you write yourself, and, ultimately, those options lead to cleaner, quicker, more responsive code.

technorati tags:, , ,

Looking to Learn Object Oriented JavaScript?

Monday, April 9th, 2007

Yes, JavaScript is Object oriented. In fact, the only way you’ll move beyond very simple scripts is if you move beyond procedural JavaScript into using and building your own JavaScript objects. There’s no better way to solve many common front end programming problems than by building an object and taking advantage of its properties and methods.

Starting out with Object Oriented JavaScript can be a little daunting, though. (It’s tough to find a good spot to get started and learn some good practices). Never fear! Here’s the very article I used to learn Object Oriented JavaScript. It’s a pretty solid resource for a beginner, and will put you well on your way to learning how to think of JavaScript as something much more than a series of one-liners and functions.

technorati tags:, , ,

Equal-height, 100% height columns with CSS and JavaScript

Friday, January 5th, 2007

Yes, that title was a mouthful. But, you know the idea: you have a CSS-based two-column layout, and you want both columns to always be the exact same height. Maybe you have a narrow left navigation column with a background color (or a gradient) and a wide right content column; if you want that background color to appear for the entire height of your content column, then you’ll need this trick, otherwise, it’ll stop when it reaches the height of its container.

Here’s an example of what we’re looking to achieve in a layout I built at my day job over at TheLadders.com. In this case, the left-hand column has a solid color fading into a gradient at the bottom of our content block. Since the right column will stretch that block down, we need to force the left-column to have the same exact height as the right column. How do we go about doing that?

There are plenty of ways to do make equal height columns using crazy CSS hacks and other methods. They work well, but they’re not very clean. To make it nice and easy, we need to use JavaScript for its main purpose: controlling presentation. And, we’ll only need a few lines of code to do it.

The Set-up
Here’s some example CSS to get that two-column look:

div#container{
  width:800px;
}

div#container div#leftColumn, div#container div#rightColumn{
  float:left;
}

div#container div#leftColumn{
  background-color:#CCC;
  width:250px;
}

div#container div#rightColumn{
  margin-left:50px;
  width:500px;
}

There’s a two-column layout for you. Here’s what that would look like with some example, placeholder content.

The JavaScript
See? That right column extends far past the left column, but we can take care of that with a simple JavaScript function (I had to add a line wrap to fit everything in the page; remove it to actually use the function):

function equalColumns(){
  var l = document.getElementById('leftColumn');
  var r = document.getElementById('rightColumn');

  r.offsetHeight >= l.offsetHeight ? l.style.height =  \\ line wrap
  r.offsetHeight + "px" : r.style.height = l.offsetHeight + "px";
}

Let’s examine what this function does. First, we store references to our two columns. Then, we do the dirty work, using the ternary operator for our comparison. Let’s examine what it’s doing:

  1. offsetHeight is an element’s rendered height, the total height it takes up in the browser window.
  2. If the right column is taller than the left, we set the left column’s CSS style height property to the right column’s height, then add "px" since CSS demands a unit of measure, and offsetHeight is measure in pixels.
  3. What if the left column is taller than right right? We do the same thing: find the left columns offsetHeight in pixels, and assign that to the right column’s CSS height.

Now that we have this function, we’ll add it to window.onload or the body tag’s onload attribute. You can use the addEventListener / attachEvent combination, too. As soon as the body loads, our columns will snap to the same height.

There’s one problem with this little method: if your pages are larger in size you’ll see them finish rendering, the onload event will trigger, and you will see the columns’ height being set (the background image or gradient will jump from its orginal height to its new height). It looks choppy, like you see here.

Can we fix it? Of course! Why run that function onload when you can run it immediately after the columns load in the document?

We’ll move that onload function into a script tag, and place that script tag containing our function immediately after the close tag of our second column. This means that the script will run immediately after that second column loads in the document, and the user will never see anything choppy. The height will be set before content finishes rendering and appears in the browser. Case closed. And, you now have equal columns as seen here. (Unless you’re stuck with using onload?)

But what about that gradient?
If you’ve been looking at the gradient here, you’re probably wondering how that shows up. Well, that’s a topic for another article coming soon. :-) (It’s right here now.)

A Google search can turn up many, many equal height column sites, but, of those I looked at, here’s one of the best (and they have a script modified to take padding into account, something that I didn’t need when I wrote my version for TheLadders).

technorati tags:, , , ,

Stuck with using onload? We can smooth out the height jump by adding a few bits to our CSS and another line to our JavaScript. We’ll change our CSS to:

div#container div#leftColumn{
    width:250px;
}

    div#container div#leftColumn.bg{
        background-color:#CCC;
    }

And, we’ll add a single line to our JavaScript function (and remove that line break I had to add):

function equalColumns(){
  var l = document.getElementById('leftColumn');
  var r = document.getElementById('rightColumn');

  r.offsetHeight >= l.offsetHeight ? l.style.height \\ line wrap
  = r.offsetHeight + "px" : r.style.height = l.offsetHeight + "px";
  l.className = "bg";
}

Now, our background color is applied after the new height is set. This looks much more natural, almost as if a background image is being loaded and applied. If you’re using an image heavy site, odds are users will never notice.

Dojo and SSL

Thursday, November 16th, 2006

As reported by Kyri and Larry, two of my coworkers here at TheLadders:

Dojo has problems on IE when it’s running over SSL. When Dojo creates background IFRAMEs for things like animation and transport, it initializes those IFRAMEs without a src attribute. The fix? Add a URL (any URL will do) to the src attribute of any occurences of IFRAMEs in Dojo functions that you’re using.

technorati tags:, ,

Working with the Dojo Tree Widget

Wednesday, November 15th, 2006

I’m working with another powerful widget from Dojo: the Dojo tree widget. I’ll continue to post some "hands-on documentation" like that I did with Dojo’s FisheyeList Widget. Here’s a quick tip off that bat that’s not readily apparent.

If you want your tree to be expanded when it loads (instead of showing the top level container only), you’ll need to make use of the expandLevel property. Here’s how it looks in code:

By specificing an expandLevel of 2, we tell the widget we want the top level container expanded to expose its children on load, the behavior you’d get if you clicked the expansion icon for the top level container. 1 is the default expandLevel; it shows the parent and nothing beneath it. These levels increase (expandLevel="3", expandLevel="4") to accomodate initially expanding your Tree to whatever depth you’d like.

technorati tags:, , , ,

I'm Reading…
Search This Site
You are currently browsing the archives for the javascript category.

AddThis Feed Button

Need great hosting?

Categories