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

Ajaxian has a nice little thread on IE DOM toolbars. Originally meant as an intro for DOM Helper, it kind of evolved to incorporate a couple other toolbars. Sure, we all use the FireBug and Web Developer extensions for FireFox, but what do we use for IE?

I personally use Microsoft’s Developer Toolbar, which I was only fairly happy with, mostly due to it’s kind of unintuitive UI. (Yes, floating tooltips are easy to make in .NET applications. No, they are not good as the primary means to communicate data). The Ajaxian article finally prompted me to figure out how to modify the DOM in the IE toolbar (because, apparently, it’s always been possible if hidden). Click on (or otherwise select) an element, and use the middle pane to add and modify attributes.

I’ve been trying to use the right pane, which, to me, seems like it should work (but is apparently only meant to show your element’s current style, which is pretty valuable nonetheless). I especially like how the attribute names are a big, giant dropdown so that you can see them all. With that middle pane, IE’s toolbar is better then the Web Developer extension (more robust), yet still not as great as FireBug. Hopefully, it works in IE 7 right off the bat.

technorati tags:developer, toolbars, ajaxian