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:yui, dojo, draganddrop, javascript, dhtml

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:javascript, firefox, spellcheck

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:innerhtml, dhtml, ajax

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:yui, dom, events, oncontentready

Positioning lists (ul and ol in HTML-speak) can generally be a huge pain: Mozilla FireFox and Internet Explorer (7, 6, 5 …) both treat lists and list items different: they have different padding, different margins, basically entirely different rendering, and, to top it all off, the list-item-image or list-item-type receive different treatment.

Here’s my "best of all possible solutions" to getting the li portions of your lists to play nicely together. Basically, using a n Internet Explorer conditional comment, give your list items list-style-position:inside and give whatever’s inside your list some padding or text-indent. This won’t get your lists to work the same cross-browser. However, it will let you remove a lot of the extra margin and padding that IE crowds into your list items, making them a little easier to work with. This goes especially true if you’re trying to squeeze them into a tight position.

technorati tags:css, ul, ol, lists, li, html

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:dojo, dhtml, javascript, tree, widget

This IE6 browser bug shows up if you’re trying to get PNG transparency to show up in Internet Explorer 6 and below using Microsoft’s alpha image filter. What’s the deal? Well, if you’re using that filter on a background-image, then you won’t be able to click on anything appearing above that background-image. Have a form as a child whose parent is using the filter for its background? You won’t be able to click on any of the form elements. At all. The solution? Don’t use a PNG and that filter. It’s not particularly desirable – in fact, it can really mess with your design – but it’s better to leave the filter right out, unless there’s no need to click, highlight, or otherwise interact with an element on the screen.

technorati tags:browser, bug, ie6, microsoft, image, alpha, filter

Been looking for an IE7 CSS hack? Been looking for an Opera hack? Odds are, you can find something around here. This is one of the most comprehensive CSS hack sites I’ve seen. By far, the best part is how granular this site gets: just about every browser you’re going to find is covered.

My thoughts on cascading style sheets hacks? Well, since you’ll be using them to correct Internet Explorer’s bad behavior, you should use what Internet Explorer gives you: conditional comments. Use conditional comments to keep IE fixes in a separate CSS file. That’s what I like to do when I have the time: it keeps the "good" code separate from the "bad." Plus, if Microsoft releases any fixes, you need only to adjust the conditional comment; since Microsoft’s conditional comments allow tests against browser version, you’ll be a lot safer with conditional comments. Plus, it keeps your regular stylesheets clean.

If conditional comments aren’t your thing (perhaps because they’re not traditional markup, although they do validate), you can try minimized attribute selectors. Why? Because minimized attribute selectors let you separate IE and Firefox/Opera/Safari CSS selectors into separate blocks. Create an IE block, then "fix" that code in a minimized attribute selector on the line below. This clearly separates IE corrections from compliant code. Unfortunately, these types of selectors aren’t XHTML compliant and are basically out if you’re writing XHTML.

This leads to my final choice, the one I’d probably recommend if conditional comments are out of the picture: exploiting IE’s failure to support media selectors on @import rules. This works almost the same way as conditional comments do, but instead of placing IE code in a separate file, you place compliant code in a separate file, which you then import to correct your IE CSS. Instead of keeping "good" code in your main stylesheet, you use the hack to correct the bad code.

I strongly recommend conditional comments: they’re the cleanest way to render CSS across browsers, and they are flexible enough to allow you to avoid using hacks in your code. If browser compatibility changes, just update the condition. Plus, there’s no nasty hacks that may be corrected in future browser releases hanging around in your stylesheets. But, if the best option isn’t your option, it’s nice to know there are other ways to make your pages render correctly cross-browser.

technorati tags:css, ie7, browser, hack, stylesheets, cascading, conditional, comments, css, hacks

Here’s a quick little tip to keep in mind when working with JavaScript: you can quickly convert a number (int, decimal, etc.) to a string by doing this

var i = 1;
var newString = i + "";

Edit on 11/21/06, 12:21PM Eastern. As pointed out in the comments below, my "excellent" example is totally bogus and leads to invalid (X)HTML. (It does, however, work in browsers, while it shouldn’t.) If you need a numeric ID, do what I do in the real world, not in my examples: preface it with a unique identifier. (Talking about baseball cards? How about using "bbc_NUMBER"?). In my own defense, this was the only thing I could think of to illustrate my point at the time. Bad example follows. ARGH!.

Now, you’re thinking: wow, why would you explain something so stupidly simple? Because even though it’s simple, it’s a useful and powerful technique. How? What if you’re working with numeric IDs on the backend that are printed dynamically into your code on the front end? Eventually, you’ll wind up with something like <element id="1" />. You’ll have a string ID and need to send an int back. Or, you’ll be iterating through a for loop, and you’ll need to do something with that iterator (access an element in the DOM, say).

Let’s say you have a function that looks like this bound to element’s onclick:

function myFunction(anID){
  // hide clicked-on element
  document.getElementById(?????).style.display = "none";

  for(var i = 0; i<4; i++){
  document.getElementById(?????).style.color = "red";
  }
  // send an AJAX request back with this ID
  sendAjax(anID);

  //Yellow fade to show done
  yellowFade();
}

Is anID an int? Convert it to a string in your document.getElementById() call like so:

document.getElementById(anId+"").style.display = "none".

What about that for block? Fill that in like so:

document.getElementById(i+"").style.color = "red";

>Your ints are now strings.

technorati tags:javacript, dom, dhtml

Ajaxian is running a series of recaps from their Ajax Experiene: Boston conference. Among the early highlights so far: Animation & Data Visualization in Javascript, which introduces us to JSViz, a JavaScript-based visualization engine. I’ve only tinkered around with the demo, but it looks killer.

technorati tags:jsviz, javascript, data, visualization, dhtml

Blogged with Flock