The Strange Zen Of JavaScript

Why must we still close SCRIPT elements?

2011-02-17T15:00:00.000-08:00

I was wondering why in the world we still have to terminate SCRIPT elements with </script> tags in 2011, fer Pete's sake.

i.e. why does this work:

<script src="foo.js"></script>

but this:

<script src="foo.js" />

does not?

For years I thought it was just a bad implementation from the NS4 days that nobody bothered to correct. Not so! Turns out there's a valid (if a bit irritating) reason.

The tl;dr answer is: <script /> is valid XML, but invalid HTML.

If you serve your HTML pages as text/html, a browser will likely use its HTML parser to render the page. And since <script /> is invalid HTML, the HTML parser treats it as unrecognized junk.

(In theory, if you serve your pages as text/xml or application/xhtml+xml, the browser would use its XML parser, recognize the <script /> as valid, and load/execute the associated JS. But that also presumes your documents are also perfectly-formed, valid XML and not tag soup. Can you make that claim?)

As to the question of why <script /> is invalid while <img /> is perfectly okay:

The XHTML spec (and therefore HTML5, which imports the element definitions from the XHTML DTD) defines the SCRIPT tag as containing "document text." It cannot, by definition, be "empty."

SCRIPT is often considered analogous to the IMG element -- and mistakenly so -- because they both use the "src" attribute. In reality, SCRIPT is more akin to the P (paragraph) element, which also cannot be empty (writing <p /> is invalid -- you must instead write <p></p>)

For comparison, here are the starting element definitions from the XHTML DTD:

<!ELEMENT script (#PCDATA)>

<!ELEMENT img EMPTY>

This is why <img /> is fine, while <script /> is a no-no.

HTML 5 audio player demo

2010-01-31T16:48:00.000-08:00

To teach myself a little about HTML 5 and its built-in support for rich media, I built a proof-of-concept HTML5 audio player, written entirely in HTML 5, JQuery and CSS 3. It more or less replaces all the functionality of the Flash audio player on my music site.

It took a little over two hours starting from nothing. Developed it in Safari 4.0 and works great with that browser. Haven't yet tested it in Firefox 3.5, which claims HTML 5 audio/video media support as well. (UPDATE: Firefox doesn't support the MP3 format. You're stuck with Ogg or WAV.) It "works" in Mobile Safari on my iPhone 3G, but it's not pretty: the audio element is visible and the MP3 launches a Quicktime player.

Think what you want about the iPad and Apple's non-support of Adobe Flash. If you're a web developer and not excited about creating rich media experiences with HTML, Javascript and CSS, you just might be a dried-out husk.

Feel free to hack this code. You can send screenshots (links only, please!) and bug reports to me here.

Using the "in" operator in conditionals

2009-10-28T15:30:00.000-07:00

Most of us are familiar with the for..in loop construct:

for (var i in object) {
   /* some iterative action here */
}

Less well-known is the use of "in" as an operator to test if a named property exists on an object:

>>> var x = {foo:1, bar:2, baz:'cat'};

>>> ('foo' in x)
true

>>> ('bar' in x)
true

>>> ('qux' in x)
false

This works on methods, too:

>>> ('toString' in x)
true

It's particularly neato for testing the existence of properties with values that could be interpreted as false:

>>> var x = {foo:null, bar:false, baz:0};

>>> (x.foo)
null

>>> ('foo' in x);
true

>>> (x.bar)
false

>>> ('bar' in x)
true

IE conditional comment gotcha

2009-10-09T17:49:00.000-07:00

Here's one for the books:

<!-- [if IE]>

<p>Some IE-specific stuff here</p>

<![endif] -->

This will be ignored by IE. Why?

Because IE doesn't like the whitespace between the comment delimiters and square brackets. Here's the correct way:

<!--[if IE]>

<p>Some IE-specific stuff here</p>

<![endif]-->

Note the difference:

<!-- [if IE]> (bad)
<!--[if IE]>  (good)

HTML 5

2009-05-30T11:05:00.000-07:00

The recent buzz over HTML 5 this week at Google I/O could not have come at a better time.

It reminds me of another time, back in 2005, when the economy was just starting to recover from the dotcom bust. Ajax made the scene (heavily backed by Google in the form of Suggest and Maps) and got people excited about doing cool things on the web again.

Now the economy is in the crapper again, and here comes HTML 5 (again backed by Google in the form of Chrome and Wave). Looking at some of the demos, I feel the same exhilaration I once felt when I first recognized the potential of DHTML. In many ways, HTML 5 picks up where DHTML -- or DOM scripting of whatever -- left off long ago.

I offer no analysis. It's the most excited I've been about web development in years.

Constraining elements to the browser window

2009-02-03T15:08:00.000-08:00

I recently worked on a demo that used tooltip-like "popover" menus that appeared when the mouse pointer hovered over certain page elements. The initial approach was pretty straightforward: find the offsetTop and offsetLeft of the target element, then move the menu to those coordinates.

Two challenges:

If an item was too close to the left or bottom edge of the browser window, the menu would appear partially offscreen. So I had to figure out how to constrain the menu to the visible window area.
I had to account for any additional window scrolling.

The following seemed to do the trick. Note that this is pseudo-JavaScript; I leave it to you to figure out how to actually obtain the necessary values and make the appropriate substitutions.

// element = target element that gets the menu
// menu = the menu popover DIV

var bottomEdge = element.offsetTop + menu.height - document.scrollTop;
if ( bottomEdge > window.height )  {
    menu.top = element.offsetTop - (bottomEdge - window.height);
}

var leftEdge = element.offsetLeft + menu.width - document.scrollLeft;
if ( leftEdge > window.width)  {
    menu.left = element.offsetLeft - (leftEdge - window.width);
}

Does your website disappear in IE8?

2008-11-12T08:28:00.000-08:00

Mine did.

I was recently given a pretty large redesign project, and during the planning stages I took the opportunity to add a long-missing DOCTYPE to the site. I chose a nice HTML 4.01 Transitional flavor because there was no way in hell the site was going to resemble anything close to XHTML anytime soon. At the very least, it would 1) get the site out of quirks mode, and 2) give us an eventual path to validation.

(I'm including this info to illustrate: we had a proper DOCTYPE, and knew the site would not be valid HTML going in.)

Months after the project was complete and launched, word came down that the site was missing in IE8. Not broken. MISSING. Like, "the page is blank."

No partial loading, no sudden flicker, no error message. The site simply would not render.

I was considering hard liquor as my preferred solution when one of my co-workers mentioned something he'd heard about a new META element, something about versioning. Ah, yes, that version targeting thing.

I added the following to the global website header:

<meta http-equiv="X-UA-Compatible" content="IE=7" />

...and suddenly the site worked in IE8.

This is not a "solution." I still don't know why the site vanishes in IE8. I mean, it rendered perfectly fine in IE5, IE5.5, IE6 and IE7 so OF COURSE IT MAKES TOTAL SENSE THAT IT COMPLETELY VANISHES IN IE8. Right?

No. It does not make sense. Anyway, when I do discover the root cause, I'll post it here. In the meantime, I guess I'll be asking IE8 to dumb it down to my level.

Missing form ACTIONs

2008-07-17T08:00:00.000-07:00

Say you want to disable a submit button when it's clicked, to prevent the user from submitting twice:

<form name="myform">
  <input type="submit" value="Submit" onclick="this.disabled = 'true';">        
</form>

On Windows, this works fine in IE but not in Firefox. Or so it appears. What's going on?

Oops, you forgot an ACTION attribute in your form. (It's okay, this is common if you're planning an Ajax-style app.) Without it, IE just ignores the submit click, but Firefox uses the current page as the default action. So it effectively reloads the page, resetting the button state.

The thing is, the submit button is being disabled in FF, just like in IE, but depending on how fast the page reloads, you might not even notice.

Function reference vs. function call

2008-07-16T11:30:00.000-07:00

Here's a JavaScript function definition:

function foo() {
  alert('foo!');
}

You can refer to that function like this:

foo

And here is how to call (execute) the function:

foo()

Even experienced developers new to JS tend to get these confused. For example, jQuery's getJSON method allows you to specify a function to be executed once the operation is complete. Be careful not to plug in the function call when what you really need is a function reference:

$.getJSON( "action.php", {data:'some data here'}, foo() );

This will execute the foo function instantly. Not what you want. So leave off the parens:

$.getJSON( "action.php", {data:'some data here'}, foo );

This merely passes a reference to the function. It won't execute until it's called by jQuery.

A good enough addEvent

2008-04-16T10:00:00.000-07:00

O HAI, this blog is nearly dead these days. But before it truly shuffles off into the sunset, allow me to point you to filosofo's "good enough" addEvent. Austin gets around PPK's pesky requirements by ignoring one of them (namely, having a corresponding removeEvent).

I love this solution because it mirrors much of my recent experiences with JavaScript. Honestly, I can't remember the last time I needed anything more than some variation of toggle() and I can count on one hand the number of times I've need to detach an event since 1998.

Kudos to Austin for thinking differently.

Some reader contributions to Calendar tutorial

2007-07-01T19:31:00.000-07:00

When I started SZOJ I promised myself I wouldn't abruptly shut down the blog if I lost interest; I'd just go radio silent until my interest was piqued again. That said, it's been a long while. So here are two things:

Rory Parle wrote in to point out you can use Math.ceil to determine the number of rows you'd need to safely render a calendar:

Math.ceil((monthLength + startingDay) / 7);

Michiel van der Blonk suggested a way to determine the number of days in a month:

var d = new Date(nYear, nMonth + 1, 0); // nMonth is 0 thru 11
return(d.getDate());

The mechanism here is the Date constructor will attempt to convert year, month and day values to the nearest valid date. So in the above code, nMonth is incremented to find the following month, and then a Date object is created with zero days. Since this is an invalid date, the Date object defaults to the last valid day of the previous month — which is the month we're interested in to begin with. Then getDate() returns the day (1-31) of that date — voilá, we have the number of days.

Bonus: it also seems to automatically correct for leap year. It feels like a hack but it seems to work consistently.

Thanks to Rory and Michiel for their contributions.

How to build a simple calendar with JavaScript

2007-03-19T22:34:00.000-07:00

While there are lots of JavaScript-based calendar widgets out there, there's not much in the way of explaining how they work for the JS acolyte. I recently had the opportunity of building one from memory (and best of all, for no particular reason), using none of the popular JS libraries. This is the tutorial I wish I had found five years ago.

This series of posts will cover:

how to create a simple calendar view with JavaScript
how to tie the calendar to an HTML element for rendering
how to add next/previous month controls
how to add date picker functionality

Part One: a basic calendar display

We're ready to start laying the groundwork for our calendar widget. Here are the steps we'll be taking:

define some global variables to hold common values
define the calendar object and its arguments
write a method to generate the HTML needed to render the calendar
write a method to return the HTML

The Date object

I used to fear the JavaScript Date object, but it's actually fairly simple. In short, here's what it does:

parses a given date, and provides useful information about that date
if no date is specified, the current date is used as the default

A full discussion of the Date object is beyond the scope of this tutorial. You can find documentation here. However, for the purposes of this project, it's important to understand what the Date object doesn't do:

it doesn't know the names of months or days of the week
it doesn't know how many days are in a given month
it doesn't compensate for leap year
it doesn't know the day of the week on which a given month begins

Surprisingly, the Date object isn't used in this widget as much as you'd expect. It's primarily used to determine the current date (if needed) and the starting day of the week for the specified month.

Global variables

As stated above, the Date object doesn't provide us with everything we need, so we have to compensate with a few predefined arrays of values.


// these are labels for the days of the week
cal_days_labels = ['Sun', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat'];

// these are human-readable month name labels, in order
cal_months_labels = ['January', 'February', 'March', 'April',
                     'May', 'June', 'July', 'August', 'September',
                     'October', 'November', 'December'];

// these are the days of the week for each month, in order
cal_days_in_month = [31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31];

These are intentionally defined in the global scope, as they may be shared with multiple calendar widgets. The naming convention is arbitrary; you may prefer to append them to the calendar constructor to prevent collisions with other variables. Since the Date object returns integers for month (0-11) and day (1-31), we'll be able to use those as indexes for looking up the human-readable labels, as well as the number of days in the specified month.

But wait, how do we compensate for leap year when February is hard-coded at 28 days? Don't worry, it's coming later in this tutorial.

In addition, we'll need a Date object representing the current date, as a fallback:

// this is the current date
cal_current_date = new Date();

The Calendar constructor

Our constructor is pretty basic at the moment. I've designed it to take two arguments, a month and year (both integers) which will represent the intial calendar state. If these arguments are missing or null, the global default date object will be used instead.

function Calendar(month, year) {
  this.month = (isNaN(month) || month == null) ? cal_current_date.getMonth() : month;
  this.year  = (isNaN(year) || year == null) ? cal_current_date.getFullYear() : year;
  this.html = '';
}

Right now you might be saying "hey, why the long syntax? Can't we just do a shortcut like this?"
this.month = month || cal_current_date.getMonth();
One of the pitfalls of this method is that zero can be interpreted as false, which means if we specify zero (January) for our month, this expression would use the default month instead.

We also want the option to pass null for one or both of the values. The isNaN() function returns true when passed a null value, which will produce an incorrect result. So we have to test for both conditions: the argument must either be not a number or null for the default to be used.

HTML generation

Here's where we take the date info and stitch together an HTML calendar grid view. Let's start with an empty method definition:

Calendar.prototype.generateHTML = function(){

}

Not familiar with object prototyping in JavaScript? Here's some good reading.

Now let's step through everything this method has to handle.

First day of the week

March 2007 begins on a Thursday, but the Date object doesn't know that. However, if we specifically give it the date of "March 1 2007" to parse, it can tell us that day of the week as an integer (from 0-6). So, let's feed it such a date:

var firstDay = new Date(this.year, this.month, 1);

We can now query the new Date object for the day of the week:

var startingDay = firstDay.getDay();
// returns 4 (Thursday)

So now the widget knows that March 2007 starts on the 5th day of the first week (remember, we're counting from zero like computers do).

Number of days in the month

This one's easy. Just use the numeric month value to look up the value in our days-in-month array:

var monthLength = cal_days_in_month[this.month];

Compensate for leap year

Right, how does the widget know if it's leap year or not? This stumped me until I did a Google code search and found a widely-implemented approach that uses the modulus operator:

if (this.month == 1) { // February only!
  if ((this.year % 4 == 0 && this.year % 100 != 0) || this.year % 400 == 0){
    monthLength = 29;
  }
}

Damn, I'm glad I didn't have to figure that out. Thanks, Google Code!

Constructing the HTML

We're ready to start building the HTML string for our calendar view. First, the header stuff:

var monthName = cal_months_labels[this.month];
var html = '<table class="calendar-table">';
html += '<tr><th colspan="7">';
html +=  monthName + "&nbsp;" + this.year;
html += '</th></tr>';
html += '<tr class="calendar-header">';
for (var i = 0; i <= 6; i++ ){
  html += '<td class="calendar-header-day">';
  html += cal_days_labels[i];
  html += '</td>';
}
html += '</tr><tr>';

It's pretty straightforward: we begin with a table and header containing the month and year. Then we use a for loop to iterate over our human-readable days-of-the-week array and create the first row of column headers.

There are more efficient ways of concatenating HTML, but I thought this was the most clear. And don't gimme no lip about using a TABLE vs. a bunch of floated DIVs — I may be a standardista but I'm not a masochist.

Now for the tricky part, the remaining boxes. We need to make sure that we don't start filling in boxes until we've reached the first weekday of the month, and then stop filling them in when we've reached the maximum number of days for that month.

Since we don't know how many rows we'll need, we'll just generate a safe number of rows — like ten or so — and break out of the loop once we've run out of days. Here we go:

var day = 1;
// this loop is for is weeks (rows)
for (var i = 0; i < 9; j++) {
  // this loop is for weekdays (cells)
  for (var j = 0; j <= 6; j++) { 
    html += '<td class="calendar-day">';
    if (day <= monthLength && (i > 0 || j >= startingDay)) {
      html += day;
      day++;
    }
    html += '</td>';
  }
  // stop making rows if we've run out of days
  if (day > monthLength) {
    break;
  } else {
    html += '</tr><tr>';
  }
}

html += '</tr></table>';

this.html = html;

The real brain-twister is here:

if (day <= monthLength && (i > 0 || j >= startingDay)) {

...which roughly translates to "fill the cell only if we haven't run out of days, and we're sure we're not in the first row, or this day is after the starting day for this month." Whew!

Here's the complete code for our HTML-generating method:

Calendar.prototype.generateHTML = function(){

  // get first day of month
  var firstDay = new Date(this.year, this.month, 1);
  var startingDay = firstDay.getDay();
  
  // find number of days in month
  var monthLength = cal_days_in_month[this.month];
  
  // compensate for leap year
  if (this.month == 1) { // February only!
    if((this.year % 4 == 0 && this.year % 100 != 0) || this.year % 400 == 0){
      monthLength = 29;
    }
  }
  
  // do the header
  var monthName = cal_months_labels[this.month]
  var html = '<table class="calendar-table">';
  html += '<tr><th colspan="7">';
  html +=  monthName + "&nbsp;" + this.year;
  html += '</th></tr>';
  html += '<tr class="calendar-header">';
  for(var i = 0; i <= 6; i++ ){
    html += '<td class="calendar-header-day">';
    html += cal_days_labels[i];
    html += '</td>';
  }
  html += '</tr><tr>';

  // fill in the days
  var day = 1;
  // this loop is for is weeks (rows)
  for (var i = 0; i < 9; i++) {
    // this loop is for weekdays (cells)
    for (var j = 0; j <= 6; j++) { 
      html += '<td class="calendar-day">';
      if (day <= monthLength && (i > 0 || j >= startingDay)) {
        html += day;
        day++;
      }
      html += '</td>';
    }
    // stop making rows if we've run out of days
    if (day > monthLength) {
      break;
    } else {
      html += '</tr><tr>';
    }
  }
  html += '</tr></table>';

  this.html = html;
}

Returning the HTML

By design, the generateHTML method doesn't return the finished HTML string. Instead, it stores it in a property of the calendar object. Let's write a getter method to access that string.

Calendar.prototype.getHTML = function() {
  return this.html;
}

Okay, let's see what we've got!

Using the calendar

The widget may be complex on the inside, but it's ridiculously easy to implement. Here's how to embed a calendar displaying the current month into a web page:

<script type="text/javascript">
  var cal = new Calendar();
  cal.generateHTML();
  document.write(cal.getHTML());
</script>

Now let's set it to September 2009:

<script type="text/javascript">
  var cal = new Calendar(8,2009);
  cal.generateHTML();
  document.write(cal.getHTML());
</script>

The Demo!

Here's our calendar widget in action.

That's nice, but...

We're stuck displaying only one month?

Shouldn't generateHTML and getHTML be called automatically?

And WTF is up with that lame document.write?

Yep, this simple calendar is "simple" alright. Later this week we'll look at a much slicker way to integrate the calendar into webpages and add controls to transform our humble static calendar view into a full-blown datepicker.

The Mark Of The n00b

2007-03-07T13:15:00.000-08:00

When I'm debugging or otherwise vetting someone's JavaScript work, I tend to look for evidence that indicates:

the author is new to JavaScript, and/or
the author cut-and-pasted this code

Neither of these are showstoppers, especially if the result is a neat-o web application or widget. But it does tend to drive me a little nuts sometimes.

Case in point: using "javascript:" in HREFs, a pet peeve of mine. It's not technically incorrect and it "just works" almost all modern browsers. It's just "wrong," in the same way that using <b> instead of <strong> is "wrong" and using TABLEs for layout is "wrong."

It's wrong from a craft point of view. It's the JavaScript equivalent of "eh, let's just shove the table markup into the database along with the content."

(Worse yet is "JavaScript:" (camel-cased) or something like "onclick='JavaScript:...'" I don't know of a single browser that falls over when the latter is used, but when someone sends me broken code to debug that has "JavaScript:" in the event handlers, the first thing I wonder is, "hm, what else is being overlooked here?")

Thing is, I don't expect JS newbies to know this stuff* because other than some tongue-clucking from old JS cranks like myself, there aren't any hard consequences.

And you. Do you have any favorite "mark of the newbie" things that drive you insane?

* that's why I run this blog

Return false to prevent jumping scrollbars

2007-03-07T12:43:00.000-08:00

I like what Harry Maugans is doing over at his site with his JavaScript how-tos. It's back-to-basics stuff, but judging from the number of Diggs he gets, people are interested in how this stuff works under the hood.

In his tutorial "How To Create A Collapsible DIV with JavaScript and CSS," Harry writes regarding the use of the HREF attribute in anchors that trigger JS actions:

Another common do-nothing insert to use for the href property is a pound sign (#), and while that will work, it'll also move the user’s scroll bar to the very top of your website, which can get quite annoying.

The way to get around the scrolling problem is to include a "return false;" in your event handler:

<a href="#" onmousedown="toggleDiv('mydiv'); return false;">
  Toggle Div Visibility
</a>

Again, basic stuff, easily overlooked.

(I wrote to Harry about this but I don't think he approved my comment. That's okay; it's why we have Trackback :)

How to parse HTML strings into DOM nodes without innerHTML

2007-02-26T10:47:00.000-08:00

Here's a way of parsing a string of HTML into a series of DOM nodes in Firefox and other Mozilla-similar ("mozimilar") browsers:

var range = document.createRange();
range.selectNode(document.body);
var parsedHTML = range.createContextualFragment(SomeStringOfHTML);

document.body.appendChild(parsedHTML)

The call to selectNode() is required as you have to point the empty range at something before you can use it; Firefox throws an exception without it. You can use other range positioning methods as well.

Also of note: createContextualFragment() is not part of any DOM specification AFAICT, so you should feel appropriately shameful about using it as you would innerHTML.

SCRIPT and innerHTML: a losing combination

2007-02-09T15:32:00.000-08:00

One day you may be tempted to skip all the cumbersome creation of SCRIPT elements via DOM methods and just cram stuff into the page with innerHTML. Woe unto you. This does not work:

var script = '<script type="text/javascript">alert("boo");</script>';
document.body.innerHTML = script;

In fact, this will produce an unterminated string error in IE6 and Firefox, because you still need to split up that closing </script> like in ye olde days:

var script = '<script type="text/javascript">alert("boo");</scr' + 'ipt>';
document.body.innerHTML = script;

Hooray, no error!

Except it still won't execute the script.

Fix your login system, you freakin' idiots

2007-02-08T11:22:00.000-08:00

Don't say "username" when you want "email address"

This is simple: if your app uses email addresses as usernames (ala OpenID or whatever), don't put "enter username" on the login page. That way I don't have to put a fist through the screen after "scottandrew" is rejected 99 times.

Wrong username or password? Which is it?

Did I type the wrong username? Did I misspell the password? Did I screw up both? Tell me. Don't get lazy and display "Incorrect username or password." What, do I get a prize if I guess correctly? Freakin' lazy, that's what you are.

Edit: I'm totally off-base on this one. A reader points out that specifying the incorrect field give hackers a vital clue. This is why I'm not in security; I'm all about making the user experience smoother — for hackers.

Tell me if you're going to limit login attempts, and don't hide password retrieval.

Some apps will throttle the number of login attempts to thwart malicious hackers. Generally I think this is dumb, but if you do this, be kind and let me know. Don't suddenly cut me off after three attempts.

And if you do cut me off, for the love of god, don't also lock me out of any password retrieval link. Move that link outside of whatever if-then you're using to display the login box. Please.

When possible, redirect me to where I was headed

I click "Edit Profile" in your app. My session has timed out, so you redirect me to a login to reauthenticate. Then you dump me on the "Welcome!" page. Wha?

Okay, so won't always have an HTTP_REFERRER to work with, but if I'm already working within your application and have to be redirected to a login, can't you save the original destination from the GET request or something?

Dynamic SCRIPT elements and Safari 2.0

2007-01-29T13:57:00.000-08:00

Patrick Hunlock's excellent article Howto Dynamically Insert Javascript And CSS reminded me of a caveat I ran across last summmer: early 2.0 versions of Safari have a bug that prevents dynamic SCRIPT elements from loading JavaScript content. The bug was fixed in version 2.0.2.

That's probably the edgiest of edge cases, but it had me slamming my forehead against the wall for a few days. I was forced to do version sniffing since dynamic SCRIPT insertion was the only way to perform the cross-domain Ajax operations required.

Here are two bugs I found while researching the problem last year.

IE6 SELECT value gotcha

2007-01-25T14:30:00.000-08:00

Consider the following HTML and JavaScript snippet, which attempts to grab the selected value of a SELECT element:

<select name="city" id="citySelector">
  <option>Seattle</option>
  <option selected="true">Tacoma</option>
  <option>Bellingham</option>
</select>

var s = document.getElementById("citySelector");
var v = s.options[s.selectedIndex].value;
alert(v);

In Firefox the result will be the string of selected city ("Tacoma"). IE6 however will return a blank string. Why?

Look at the HTML. None of the options have a value attribute. This is pretty common in markup where the option text is the same as the value. When used with a form POST or GET, most browsers send the option text in lieu of the missing value attribute.

But when accessing the value from JavaScript, Firefox plays fast and loose, whereas IE6 is stricter, returning nothing for the value because none was explicity given.

Here's a solution that works in both browsers:

var v = s.options[s.selectedIndex].text;

Non-attachment

2006-03-08T11:08:00.000-08:00

When Kitano Gempo, abbot of Eihei temple, was twenty-eight he studied Chinese calligraphy and poetry. He grew so skillful in these arts that his teacher praised him.

Kitano mused: "If I don't stop now, I'll be a poet, not a Zen teacher." So he never wrote another poem.

— Zen Flesh, Zen Bones

Happy birthday "Ajax"

2006-02-15T13:35:00.000-08:00

Well, almost. February 18th is the official one-year anniversary of Jesse James Garrett's essay that coined the term "Ajax" to describe what applications like Google Maps were using under the hood.

Thus rekindling interest in what some longtime web developers have pooh-poohed as old news: DHTML. But man. Books. Articles and tutorials. Conferences! Workshops! And the prime indicator that a concept has gained serious traction, haters!

Not bad for something once considered just a few short years ago to be too broken, unevenly-supported, and often downright ridiculous to be of any use.

Y! Design Pattern Library

2006-02-14T11:50:00.000-08:00

While it's awesome that Yahoo! has released a suite of JS tools, I'm actually more enamored of the Yahoo! Design Pattern Library.

The Yahoo! Design Pattern Library is an evolving set of sophisticated design guidelines for building web pages and applications. Our design patterns do not require the Yahoo! UI Library components, although using our UI Library can help you more easily implement the patterns described in these pages.

Very cool.

Safari quirk: Copying innerHTML

2006-02-14T11:36:00.000-08:00

Here's a fun one. Given the following HTML, let's attempt to copy the contents of div1 to div2, then grab a reference to the SPAN element "foo."

<div id="div1">
  <span id="foo">Foo span</span>
</div>

<div id="div2"></div>

The easy way out is to just copy innerHTML from one element to the other, then destroy the contents of the original element:

document.getElementById('div2').innerHTML = 
    document.getElementById('div1').innerHTML;
document.getElementById('div1').innerHTML = '';
alert(document.getElementById('foo'));

In most browsers, the alert dialog displays "Element SPAN" or something similar. But in Safari 1.3 and above, the dialog displays null. Why?

For a brief moment, when we copy the innerHTML, we create two SPANs with identical IDs of "foo." Even after we destroy the contents of div1 (leaving only the one SPAN), the DOM is screwed up enough to confuse Safari, which continues to return null even after the DOM is "fixed." By contrast, Firefox for OS X is far more forgiving.

The solution seems to be: duh, don't copy from element to element. Instead, hold the contents in a variable until it's safe to reinsert them into the page:

var tempHTML = document.getElementById('div1').innerHTML;
document.getElementById('div1').innerHTML = '';
document.getElementById('div2').innerHTML = tempHTML;
alert(document.getElementById('foo'));

The dialog should now display "Object SPAN" in Safari. Of course, astute JS developers would probably prefer to skip using innerHTML altogether

Automatic JavaScript documentation generation

2006-01-16T12:43:00.000-08:00

I'm looking for some recommendations for auto-generating API docs for JS libraries. There doesn't seem to be a lot of info out there on Google, so let's build a list here.

I'm interested in everything from mods to existing packages like DocBook, JavaDocs, etc. to Perl scripts you've stitched together back in 1999. Have at it!

Non-Blogger members can email me and I'll post your link.

Tip: the MS Script Debugger

2006-01-13T01:53:00.000-08:00

I'm surprised that more JavaScript developers don't know (or maybe have forgotten) about the Microsoft Script Debugger. If you're weary of IE script errors that report "Line 324: Object expected" and no filename when you have 500K of script divided over 12 files, install this beastie, then open IE and go to Tools > Internet Options > Advanced and uncheck "Disable Script Debugging (Internet Explorer)."

Restart IE and the next time you encounter a JS error, a dialog box should pop up asking you if you wish to debug it. Clicking OK will launch the debugger, taking you to the file (hallelujah!) and the line at which it occurred.

It's not specifically tailored for JS like Venkman, but it's waaaaay better than IE's native JS error reporting.

Follow-up: Safari and String.replace() caveat

2005-12-19T11:12:00.000-08:00

Following up on the Safari and String.replace() issue, it looks like this is a known bug that is fixed in the Webkit CVS tree but not yet part of any public release of Safari. So, if you're a junkie for nightly builds, you should be golden. (Your customers, on the other hand, are probably not so golden.)

MacIE's numbered days

2005-12-19T10:47:00.000-08:00

MSFT is officially pulling the plug IE5 for the Mac:

In accordance with published support lifecycle policies, Microsoft will end support for Internet Explorer for Mac on December 31st, 2005, and will provide no further security or performance updates.

Additionally, as of January 31st, 2006, Internet Explorer for the Mac will no longer be available for download from Mactopia. It is recommended that Macintosh users migrate to more recent web browsing technologies such as Apple's Safari.

So long, old buddy.

BONUS: best comment via Slashdot: "Couldn't they have just emailed both people still using IE on the Mac and saved themselves the trouble of a whole press release."

Y! JavaScript Dev Center

2005-12-16T09:36:00.000-08:00

Yahoo!'s JavaScript Developer Center looks pretty sweet.

Safari and the String.replace() method

2005-12-14T21:46:00.000-08:00

JavaScript strings have a cool method called replace() which allows you to supply a regular expression and replace the matched bits of the string with another string.

var str = "my dog has fleas";
str = str.replace(/dog/, "cat");

Output:

my cat has fleas

One of the cooler things about this is you can provide an expression as the second argument. This can be a variable:

var str = "my dog has fleas";
var str2 = "cat"
str = str.replace(/dog/, str2);

...or even a function:

function Cat() {
  return "cat";
}
str = str.replace(/dog/, Cat);

This works great in IE, and Firefox on both Windows and OS X.

But Safari? Not so much. Here's the output of that last example in Safari:

my function Cat() {return "cat";} has fleas

Ugh, what happened? It appears that when given a function in this context, Safari does not evaluate it as an expression, but instead calls the toString() method of the function, casting it into a string.

I haven't found a workaround. Have you?

Safari and DOM 2 HTML

2005-11-08T11:58:00.000-08:00

Does Safari support a HTML element hierarchy/interface, similar to Firefox's support of the DOM 2 HTML interface? It does not appear to be so. Or if it does, it doesn't expose it to scripting. True or false? Google is silent on the matter.

Links and pointers welcome.

Okay, some clarification: there's DOM 2 Core, which is the node/element interface we know and love, which allows us to express a document as a hierarchy of objects. On top of this is DOM 2 HTML which goes a step further by defining specific kinds of node/element classes to represent HTML elements. A DIV is an HTMLDivElement, an IMG is an HTMLImageElement, etc.

Each of these element node are descendants of the Mother Of All HTML Subclasses, HTMLElement.

I'm trying to determine if Safari supports DOM 2 HTML. So far, all signs point to no. In Safari, a DIV is a DIV and an IMG is an IMG. I can't really discern if the HTML elements are subclasses of some super-duper element — my guess is if there is one, it's not exposed to scripting as it is in Mozilla/Firefox. I'd love to be proven wrong.

UPDATE: according to this table, Safari 2.0.1 was 99% compliant with the DOM 2 HTML spec. So it's there. Is it scriptable? I'll have to upgrade and let you know.

Got ActiveX?

2005-10-24T13:32:00.000-07:00

To use PassAlong's digital distribution service, you must have ActiveX installed. Got Firefox? No worries, there's a plug-in just for you.

Yuck.

Kickass form assistance

2005-10-24T11:39:00.000-07:00

So have you seen Remember The Milk yet? It's a to-do list service that has some very next-gen features, including some Ajaxy stuff to speed things like form entry and validation:

Remember The Milk checks to see if the username I've selected is available as I type it and puts little checkmarks next to completed fields. I'm totally in love with this approach. How many times have you filled out a form with a kabillion fields, only to be forced to do it again because one or two fields were invalid?

"Samy" explained

2005-10-24T11:21:00.000-07:00

Here's a detailed examination of the MySpace Samy/JS.Spacehero worm, a JavaScript hack that enabled one MySpace user to automatically add himself to the "friends" lists of thousands of MySpace members and add the line "Samy is my hero" to their profiles.

Looks like the perp found a way to execute JavaScript by stuffing a "javascript:" pseudo-protocol inside a CSS background:url(...) rule, then used XMLHTTP to execute a series of POSTs. Much of the code looks pretty IE-specific in this case.

Mmmm, Ajax badness.

The Ghost of NS4

2005-09-28T11:29:00.000-07:00

There are times when you simply have to throw in the towel and do something evil. Such as, oh, make Firefox behave like Netscape 4.

A widely-used utility script was causing fatal errors in Firefox. These errors were halting the JS interpreter completely, which shut down my own code before it could even be executed. Closer examination revealed that the utility script jammed all browsers into the IE4 or NS4 category, and made extensive use of NS4-only properties like document.layers, layer.clip and layer.pageX.

Fixing the utility script to work with Firefox was not an option. The script is deployed to literally hundreds of thousands of existing websites as part of a popular WYSIWYG program. Even if I was able to provide a patch to the script, there would be no way to compel people to upgrade.

Not to mention that I'd be the one stuck maintaining and supporting a script that I didn't write.

Worse, browser detection was buried deep inside the utility script and done on the fly in several spots, all with locally-scoped variables that were impossible to overwrite.

I had to find a way to unblock these errors without touching the script.

So:

document.layers = document.getElementsByTagName("*");

Unngh! It hurts! Make it stop!

HTMLElement.prototype.pageX getter = function () { return this.offsetLeft; };
HTMLElement.prototype.pageY getter = function () { return this.offsetTop; };

Please kill me now.

I'll leave it to you to figure out how I took care of things like the getting and setting of properties like clip.left, clip.top, clip.right, etc. (hint: it involves the use of getComputedStyle, parseInt, a number of string methods and IT AIN'T PRETTY, THAT'S FOR SURE.)

Oh wait, IE6 chokes on this and tells me it's expecting a semicolon. Well, of course. IE doesn't support getter/setter. So I have to wrap this whole thing in a server-side UA sniff to ensure that it's never delivered to IE.

The ghost of NS4 continues to haunt, its icy incorporeal fingers reaching out to mess with my head.

Del.icio.us with Blogspot blogs?

2005-09-26T17:09:00.000-07:00

I thought I'd be able to use del.icio.us links in conjunction with this blog (not as a sidebar, but the handy daily automated post feature), but it's been a long while since I used the Blogger API, and there doesn't seem to be a target URI for posting that I know of. Anyone out there know how I can get this working? Or am I just hosed?

addEvent() recoding contest

2005-09-08T07:22:00.000-07:00

Peter-Paul Koch has put together a contest to recreate my addEvent() and removeEvent() utilities in a way that compensates for its inherent shortcomings:

Write your own version of addEvent() and removeEvent(), submit it by adding a comment to this page, and win JavaScript fame.

Entries will be judged by a panel consisting of Scott Andrew LePera, Dean Edwards and myself on script quality, simplicity and portability, and the clarity of your explanation.

I'll also update the original tutorial that introduced addEvent() with a link to the winning entry.

Previously: Know your (event) sources.

A treasure trove of quirks

2005-09-04T10:38:00.000-07:00

If you're not already reading Hallvord R. M. Steen's Miscoded Blog, you probably should be. Hallvord's a JavaScript QA tester for Opera Software, and uses his blog to record many of the JS and browser quirks and caveats he comes across. Some sample posts:

IE's event transparency logic
document.all offers another IE quirk
meetup.com captures events by mistake (addEvent() strikes again!)

Good stuff. Read it.

Know your (event) sources

2005-08-30T16:15:00.000-07:00

A loooong time ago I wrote this tutoral on JavaScript events, in which I included a cross-browser event handling script called addEvent.

Today, Peter-Paul Koch: addEvent Considered Harmful. And he's right, you can get into all kinds of headaches using IE's attachEvent method, as my own addEvent snippet does. Be sure to read the ensuing comment thread for some interesting alternative approaches.

Caveat implementor, my friends.

PS: I'm rather pleased that something I wrote merits a "considered harmful" treatise! I'm in good company.

Firefox document.all caveat

2005-08-26T14:05:00.000-07:00

document.all is a proprietary feature of Microsoft Internet Explorer; a JavaScript-accessible collection of all page elements and precursor to the W3C document.getElementById() method.

Firefox doesn't support document.all. Or does it?

Beware: Firefox does sport a document.all when a page is in quirks mode. In fact, you can see it with the DOM Inspector tool. It doesn't have any child elements so I suspect it's some sort of wrapper for getElementById. Try referencing it from code and you may get this friendly warning:

Warning: Non-standard document.all property was used. Use W3C standard document.getElementById() instead.

Switch to a standards-compliant page and document.all is undefined, as expected.

~~Obviously this puts code that employs quick old-school browser checking with document.all at risk — especially if your code is meant to be portable or drop-in.~~ Updated: see below.

Update: looks like support for document.all was introduced in Moz 1.7.5 back in December 2004.

Update #2 Confusion. The Mozillazine note says the document.all is "undetectable", but the way I discovered this was because FF was taking an IE code path based on the existence of document.all, exactly what shouldn't be happening. So I dunno.

Update #3 I haven't been able to reproduce the case that led me to discover Firefox's document.all implementation, so I think the bug must have been in my code. (Shocking, I know!) In any case, it does look like a test for document.all in Firefox should return false.

Google Talk

2005-08-26T00:08:00.000-07:00

Raise your hand if you were underwhelmed by Google Talk not only being Windows-only, but a desktop app. ::raises hand::

I'm sure I'm not the only one scratching my head over Google's decision to do a desktop app as opposed to a web client. It's not like it hasn't been done before — AOL's AIM Express is, as far as I can tell, a pure DHTML IM client although I can't tell for sure if it's a persistent connection or polling. Actually, I don't care; AIM Express rocks. It does the job, works in Moz, 'nuff said.

Most likely Google Talk is chained to the desktop due to it's VoIP features. Fair enough, I don't think, uh, VoIP-over-HTTP is a worthwhile endeavor right now. Maybe the IM features are just a nice-to-have thrown in on top of an app that was initially designed to make VoIP as easy as IM.

But still, kind of a strange sideways move for Google.

Here come the Ajax books

2005-08-14T20:58:00.000-07:00

It's only been six months since Jesse James Garrett neatly rechristened the combination of JavaScript, DOM and behind-the-scenes HTTP requests as "Ajax," and there are already three books available for preorder at Amazon:

I've also heard rumblings of books from O'Reilly, Sitepoint, etc.

Are you working on an Ajax book? Hit us with a comment.

Beware of false falses, or something like that

2005-08-13T18:25:00.000-07:00

This is a really, really common gotcha that trips up even expert webdevs.

When you're checking for the existence of an object or property, make sure what you're testing is not going to return an unexpected value. For example.

if (document.documentElement.scrollTop) {...}

Right away, we're in trouble. Why? Because the default value of scrollTop is zero (for a page that hasn't been scrolled yet). In JavaScript (and many other "real" programming languages), zero is the same as false. So in the above statement, the conditional in parenthesis will fail, and the code will make the wrong choice — and we haven't even tested for document.body yet.

What about this?

if (document.documentElement && document.documentElement.scrollTop) {...}

Also no good if scrollTop returns zero. Here's a better way:

if (document.documentElement) {...}

This test will return undefined if documentElement is missing, which is correct behavior. In a pseudo-Boolean check like this one, undefined is as good as false.

The dark despair of DOCTYPEs

2005-08-03T23:56:00.000-07:00

It bears repeating: the use of different DOCTYPEs can change the DOM interface in unexpected ways. It shouldn't, but it does. To wit:

document.body.scrollTop

becomes

document.documentElement.scrollTop

...depending on which DOCTYPE is used. (The former property doesn't disappear, but stops being updated, returning 0 (zero) no matter how much you scroll). This seems to be true for both IE6 and Firefox. So be sure to test for both if your web app depends on accurately measuring the scroll offset of a page. Double-especially if your app is something to be dropped into existing webpages with DOCTYPEs you cannot know in advance.

IE has a neato

document.compatMode

property that returns "BackCompat" if the DOCTYPE is allowing the page to behave like old-school IE, with the broken box model and the stuff and the thing. "CSS1Compat" indicates DOCTYPE-triggered "standards-compliance" mode. So you can have your app test for this and adjust accordingly.

IE style rule gotcha

2005-08-02T23:58:00.000-07:00

I've been busy with massive project at the day job (launching soon, hope to mention it in detail here), and soon I'll be preoccupied with a C++ course, so I don't expect to be posting with any regular frequency here for the remainder of the summer.

I will share this, though: just because you can set style properties with a string:

elm.style.fontSize = "12px";

...doesn't mean IE will accept any old string:

elm.style.fontSize = "12px !important";
/* causes 'invalid argument' error in IE */

Firefox has no problem with this. Of course.

MS rolling out Ajax toolkit

2005-06-28T09:43:00.000-07:00

Looks like Microsoft will be rolling out an Ajax-enabling toolkit called Atlas.

Microsoft's Atlas is a "Web client framework" designed to make the job of building AJAX-style applications simpler, said Charles Fitzgerald, the company's general manager for platform technologies.

"People who do (AJAX development) are rocket scientists," Fitzgerald said. "In some ways, this papers over the mess that is JavaScript development. It's easy-to-build 'spaghetti' code."

Atlas--which is a downloadable piece of JavaScript code--gives developers a more structured environment for building applications, providing time-saving services such as an object model and debugging, he said. It will work across any Web browser that supports AJAX technologies.

The "rocket science" quote is funny, 'cause one of the questions posed at the Ajax Summit I attended last month was along the lines of "is Ajax rocket science?" Answer: only if you want to build rockets.

Don't do these anymore

2005-06-24T10:11:00.000-07:00

Six JavaScript features we do not need any longer. I still see plenty of instances of "javascript:" in modern JS code. My favorite is seeing it used in an event handler, like this:

<a href="#" onclick="JavaScript:doThis();">Do This!</a>

With capitalization, even. Hello?

Spot The WTF: JavaScript edition

2005-06-23T17:07:00.000-07:00

The Daily WTF has a doozy of a JavaScript challenge: the most jaw-dropping test for alphanumeric characters, evar. Wow.

I made some science

2005-06-22T09:20:00.000-07:00

TiddlyWiki hack: exporting tiddler HTML

2005-06-16T09:05:00.000-07:00

I was trying to figure out how to export rendered HTML from a TiddlyWiki tiddler so I could paste it into an MS Word document. Since there doesn't seem to be a supported way to do this in TiddlyWiki, I found two methods that seem to work:

If you're using Firefox, just highlight the tiddler text, then right-click your selection and choose "View Selection Source." I dunno why this works, but it does.
Otherwise, I threw together the Ugliest TiddlyWiki Hack Ever!

I may be reinventing the wheel here, but whatever.

Save a backup of your TiddlyWiki file, then open it in a text editor and search for the createTiddlerToolbar function. In that function, look for the section that adds buttons to the non-editor toolbar and add the following lines to that block:

insertSpacer(theToolbar);
createTiddlyButton(
  theToolbar,
  "html",
  "show/hide HTML of this tiddler",
  onClickToolbarShowHTML
);

Now add the following function somewhere in the page, preferably near where the other button handlers live:

function onClickToolbarShowHTML(e)
{
  hideMessage();
  if(this.parentNode.id) {
    var viewer = 
      document.getElementById("viewer" + this.parentNode.id.substr(7));
    if (!viewer.isHTMLView) {
      viewer.innerHTML = viewer.innerHTML.replace(/\</g,"&lt;");
      viewer.isHTMLView = true;
    } else {
      viewer.isHTMLView = false;
      displayTiddler(
        null,this.parentNode.id.substr(7),1,null,null,false
      );
    }
  }
}

This is admittedly a gross hack: we're just grabbing the HTML of the viewer tiddler and replacing all the left angle brackets with HTML entities, then stuffing the HTML back into the tiddler. Since calling displayTiddler refreshes the tiddler content, we can use that to undo the damage without manipulating the string again.

This has been pretty useful to me, since I love the simple TiddlyWiki table markup for doing spec work, but usually have to cut and paste it into a report written in HTML or Word. Now, I just hit that "html" tiddler button, copy/paste the HTML, then toggle it back.

Proposed event sourcing in HTML 5

2005-06-11T13:53:00.000-07:00

From the Ajaxian blog, a rundown of proposed HTML 5 features from WHAT-WG. They also link to Hixie's slides, which don't work in Firefox. Feh.

There's a lot of interesting stuff that walks the line between semantic vs. presentational, etc. My favorite, though, is this the proposal for event sources:

<event-source src="/some/path" onevent="process(event)"/>

This is exciting to me because mod-pubsub comes extremely close to this implementation with their JavaScript/DOM engine, which allowed HTML elements to process and display remote server events with just a few non-standard attributes:

<div kn_topic="/some/path" kn_onmessage="process(event)"></div>

Of course we had a very freakishly large and complex JavaScript engine to handle all the Ajaxy goodness. At the time, we called it a microserver, since the idea was that the JS engine could serve events from client to server as well as to other parts of the client. A web application could comprise of several mini-applications tied together with a JS message bus — which isn't so different from desktop OS programming.

At one point it was generally agreed that the notion of a microserver wouldn't be exciting for much longer, since it seemed to make sense that this "JS message bus" would eventually be baked into the browser — if only people would see the usefulness of it! (This was in 2001; Google Suggest and Google Maps were a few years away.)

For something like WHAT-WG's event-source to work, there has to be support for such functionality in the browser. But I'm glad to see this development, and am looking forward to the time when we won't have to drag around additional JS libraries to implement event-driven web apps.

Dig!

2005-06-07T16:56:00.000-07:00

Great Athena! It's DHTML Lemmings!

Why Google Maps wins

2005-05-31T14:50:00.000-07:00

It occurs to me that the real winning feature of Google Maps is not its DHTML-goodness, its endless scrolling surfaces, its Ajax underpinnings nor its satellite photo views. Rather, the winning feature is the user types the address into a single input box. No more entering street address, city, state and zip into separate boxes. You don't even need commas, AFAICT.

It seems like such a trivial detail, but to me it's everything. Why can't every address input interface be that simple?

Summer Slump

2005-05-26T10:45:00.000-07:00

This is one of those posts to inform readers that blogging will continue to be light over the next few weeks as things get crazy with the music thing the day job is taking away what little time is left. Plus, I've got a backlog of Lost episodes to watch.

Of course, I fully expect to discover a bunch of post-worthy things the moment I click "Save" on this entry :)

In the meantime, behold the wonder that TiddlyWiki has become. It's got some of the cleanest JS code I've seen in a long time, and local load/save options? Heaven. I came up with a hack to add checkboxed list items but it's so ugly and wrong I'm too embarrassed to release it.

Secure IFRAME gotcha

2005-05-21T11:15:00.000-07:00

A simple caveat from an anonynmous JS whiz: when you create a new IFRAME element on a secure page, IE sets the default SRC to a non-secure blank page, thus popping a security alert dialog.

var el = document.createElement('iframe');

Since creating IFRAMEs in IE this way is already problematic, the solution might be to insert the IFRAME with innerHTML rather than using createElement. YMMV.

Ajax @ Amazon?

2005-05-12T12:40:00.000-07:00

Given that I was one of the lone attendees without a demo to show at the Ajax Summit earlier this week, I wish I had known about Amazon's new Diamond Search, which uses a combo of DHTML and Ajax-style backend communication to allow users to narrow search results in a purely visual way. Move the sliders back and forth and watch as some mysterious process fetches the number of search results in real time.

Full disclosure: I didn't build this and have no idea how it works under the hood. A press release went out last Wednesday and the app has been publically available for at least a week. News to me.

Ajaxed out

2005-05-11T01:01:00.000-07:00

For the past two days I've been attending an "Ajax summit" event thrown by O'Reilly and Adaptive Path. I think "summit" is an apt term to describe it, as it included a cool cross-section of individuals from various disciplines — web developers, network engineers, interaction designers and others — and many, many people who've been doing this type of work for a long, long time. I thought this was an important distinction, as the application of Ajax (however you might define it) brings new solutions to old problems while creating new problems that reach outside the scope of what is generally thought of as "webdev."

I'm way tired, so here're some frazzled notes and takeaways.

Ajax, grunge rock and convergence

I found a parallel in the thoughts of Generation X author Douglas Coupland on the hypermarketing of the twentysomethings in the early 90s:

Generation X's tiny, March 1991 printing had no publicity, and received almost no reviews. But that summer a Texan my age named Richard Linklater released the movie "Slacker"...And in Seattle, a new form of music was exploding...As the media goes, two's nothing, but three's a trend. Thus were born the most abused buzzwords of the early 90s: "generation X", "slacker", and "grunge".

Similarly, I felt three things happened to converge, coincidentally: the flattening of the browser landscape; the buzz built around Google's trial-balloon apps like Google Suggest, and the coining of the highly-buzzable term "Ajax."

Thus, Ajax is the GenX of web development: suddenly a movement and a market where before there was just a bunch of neato stuff.

What Ajax is, what Ajax isn't

No attempt was made to define "Ajax" or identify the patterns inherent in an Ajax application. No one was gonna touch that with a twenty-foot pole.

That said, I have my own thoughts on what Ajax is, and I think if we want to effectively communicate to people that Google Maps != Ajax (more on this below) it's important to recognize the larger components:

Ajax the methodology - this is the concept, the approach: fetching small pieces of data from the server, without a whole page refresh.
Ajax the technology - the libraries and toolkits: JavaScript, Flash, XML, HTML, etc. whatever enables #1 above.
Ajax the implementation - it can be as boring (and useful!) as a "smart" HTML form that validates fields as you tab between them, or as sexy as Google Maps.

Gotta keep 'em separated, because we gotta be prepared for the questions: what is Ajax? Is this something we should be doing? I think our energies are better spent on deciding whether the Ajax methodology is an appropriate approach to solving a particular problem.

For it all to work, the methodology must be a win for the business person, the technology must be a win for the IT department, and the implementation must be a win for the user. If cost > value in any of these, don't bother. "You're building a car around a bicycle." (source)

Threats

Skip Intro - we need to avoid a repeat of the "Flash is 99% Bad" debacle that took years for Macromedia to shake. If there's no win in applying an Ajax approach, don't bother.

XML Fairy Dust - for awhile in 2000, it seemed that XML was suddenly the answer to everything, a magical fairy dust that increased ROI and garnered more seat licenses. It wasn't. Neither is Ajax.

Microsoft? Nah, I don't buy this. They gave us XmlHttpRequest and I doubt they care enough to break it.

Is Flash Ajax?

No. Is it capable of enabling an Ajax-style applications? Yes. Dunno what's so hard about this question.

Browser Beefs

Flickr's Eric Costello gave a presentation that was part satisfying rant at the remaining dissimilarities between the browsers, and vented some frustration at long-standing and long-annoying problems like the Back Button Issue, DOM manipulations that aren't cached, CSS-immune FORM elements, etc. It was a high point.

Etc.

Desktop apps are trying to be more like web apps, and web apps like desktop apps. Where do they meet? (Later: who cares?)

Still need a killer app. Everyone points to Google Maps but it feels overblown. I think the real value will come from making boring stuff better, making static interfaces responsive. Anil: making web pages act the way users expect them to act, but who have been trained to expect less.

Derek Powazek: full-page request/response is to email as Ajax is to instant messaging. Smaller chunks of data, in a simplified format, traveling faster.

Saw lots of demos. Not gonna talk about 'em. Suffice to say there's some very cool stuff being built.

Jason Kottke rolled out Ajax-powered blog archives on his website while the sessions were going on. Nice, but I think Dunstan Orchard's live search is equally impressive (and Dunstan's attention to progressive enhancment is admirable).

I'm pretty sure I was the only one (out of about 40 attendees) without a laptop. About 70% of laptops were Macs. At times I felt like I had forgot my duck. At other times, I was glad I didn't have the distraction of email, IM, etc.

Probably more to report once I get some rest.

Have we won yet?

2005-05-04T15:57:00.000-07:00

A blast from the past: Why DHTML Will Win, by Steve Champeon in the now-defunct New Architect magazine, June 2002. I especially like this bit here:

DHTML, you say? Tried that, hated it. It didn't work the way you had expected in [insert your favorite browser here], right? Well, it's time to take a second look. What you may think of as DHTML has advanced greatly since the early days of Web design. Back then, Microsoft and Netscape were in a pitched battle over which Document Object Model (DOM) would rule the Web: document.all or document.layers. But that has all changed. In the end, reason and the W3C have prevailed. Even Netscape, the company that created the element, has abandoned it in favor of the standard <div>. Developers no longer have to code for two different APIs.

So why the resistance to DHTML? Perhaps it's time for a new name.

It's been three years. Has DHTML won?

Who needs XML?

2005-05-03T14:49:00.000-07:00

Been thinking about the "and XML" part of Ajax and wondering why we need XML at all.

For example, 37 Signals recently rolled out its new Backpack web-based PIM application, and I've read a few complaints about how it doesn't work in browsers like Opera and older versions of Safari, presumably (I haven't looked under Backpack's hood personally so I'm going on word of mouth here, careful!) its heavy reliance on XMLHttpRequest for client-server data transfer.

(BTW, that's not meant to be a negative comment on Backpack on my part. Backpack looks VERY cool, and I intend to play with it extensively.)

So here's my thought: what's wrong with just the "AJ" part of the Ajax equation? Seems to me that there are lots of sturdy JS libraries that can deliver and receive pseudo-asynchronous data to/from the server that don't require the overhead of an XML parser. It's relatively easy to bootstrap a JavaScript message format at the server level, so why do we insist on pushing XML back the browser?

The obvious reason is, I guess, compatibility with other apps that read XML, but that doesn't seem particularly compelling when 99% of the apps I've seen are built to be run in a JS capable-browser. Why wouldn't you optimize your data format to suit the target environment?

As far as XMLHttpRequest is concerned, as one Opera user stated, "shouldn't it just work without it?"

IE bold text + opacity problem

2005-04-29T16:43:00.000-07:00

You know how IE's alpha opacity filter ruins boldface text?

<div style="width:100%;
     filter:alpha(opacity=90);
     font-weight:bold;">
  Hello world!
</div>

If you're using IE, you can see the problem in action here:

Hello world!

I discovered this while tweaking the opacity filter function I wrote about earlier.

After much fruitless Googling and consulting with webdev experts, I couldn't find a fix. And like most solutions, I had to stumble upon it at the eleventh hour: adding a background color or image to the container element will fix the IE opacity rendering problem.

<div style="width:100%;
     filter:alpha(opacity=90);
     font-weight:bold;
     background-color:#fff">
  Hello world!
</div>

Here it is again, with the fix:

Hello world!

Hopefully the search engines will find this page and no one will have to suffer as I have ever again.

UPDATE: SZOJ reader Andre points out that this bug probably surfaced when MS introduced ClearType rendering, which probably explains why the bug goes away when "font smoothing" is disabled.

Ugliest line trunc hack EVER

2005-04-22T16:44:00.000-07:00

Warning: this hack is dumb and should not be used by anyone.

The challenge: given some text of abitrary length, figure out where to best truncate the text so that only the first two lines are displayed, regardless of the width of the containing element.

By the way, the element is inline, you have no control over its dimensions, and the spot where you truncate the text must end in an ellipsis (…) Don't ask. Q: can't we just cut it at 20 characters and call it a day? A: no, it must fully fill the two lines, do as we say or we will be cranky.

Given that the fonts used were not fixed-width, I threw out the idea of counting character widths. However, I knew that the line-height CSS rule for this element was 14 pixels, and using offsetHeight I could determine if the height of the containing element, in this case a SPAN. (Word to the wise: offsetHeight is what you want. In the absence of a specific rule, the computed CSS height property for an element seems to be either blank, undefined or "auto", none of which are particularly helpful.)

Armed with this knowledge, I set out to write the ugliest hack I could manage:

var elm = document.getElementById("DivOne");
while (parseInt(elm.offsetHeight) > 28){
    var txt = elm.innerHTML;
    txt = txt.substring(0, txt.length-2) + "&#8230;";
    elm.innerHTML = txt;
}

In a nutshell: take the text, shave off the last character, append an ellipsis HTML entity, then shove the text back into the element and measure the height. Repeat until the SPAN is finally 28px high (twice the line height == two visible lines).

Ugh. I'm lucky that the strings I was working with were no more than 30 characters long, and only 3-5 strings had to be dealt with in any given page. Excuse me while I go take a shower.

DOM 0 with XHTML caveat

2005-04-21T11:40:00.000-07:00

Here's an interesting gotcha, unearthed from Bobby van der Sluis' popular article on JavaScript good practices that's making the rounds: when you serve an XHTML document as application/xhtml+xml, the good old DOM Level 0 collections like document.images and document.forms go bye-bye, at least in Mozilla-based browsers.

I'm okay with this, but I love me some backwards-compatible DOM 0, especially when I know exactly which element I need to access via script. Luckily, it's perfectly okay to serve XHTML 1.0 as "HTML compatible" text/html. It's when you start serving XHTML 1.1 as text/html that people start yelling and pointing.

Here's the Bugzilla discussion of this behavior.

Odd and ends 4/18/2005

2005-04-18T13:13:00.000-07:00

If you sent me a message in the past month, my apologies: I forgot to turn on Gmail forwarding and just discovered a backlog of SZOJ email. I'll catch up in a few.

Speaking of Gmail, here's some reverse JS Zen: Gmail now works in nearly all browsers, including some legacy ones. Gmail falls back on a basic HTML version if it detects that the browser can't support the more advanced features. So while you might not have all the real-time widgetry, you'll never be locked out of your account when you're stuck with Netscape 4.

I've heard lots of comments from developers in years past about how users have to expect a greatly degraded experience if they're not willing or able to upgrade at the client end. Unfortunately, "degraded" often means "not even minimally supported." The Gmail developers weren't willing to settle for that, and neither should the rest of us. Design your web app for the web first. (Now, if only we can get more Flash developers to buy in to this.)

On a different tangent: earlier this week I wrote a post about what I thought about the whole "controversy" over the use of "Ajax" as a suitable term to describe DOM + JS + behind-the-scenes HTTP. I ended up scrapping it because I want this weblog to focus on practical stuff. Leave it to Matt to sum up my thoughts, nearly to the letter. So I'm going allow myself a (hopefully infrequent) opinionated post: hello, our technology just became interesting again to the world at large, and y'all want to complain about buzzwords? Who the heck cares what they end up calling it?

I hereby call a moratorium on the snarkiness, name-calling and faux outrage over something we failed to do ourselves: make DHTML popular.

Shorter JS Iron Chef!

2005-04-15T12:49:00.000-07:00

The challenge: write a JS function that takes a given hex color and returns a suitably-contrasted greyscale shade, in as few lines of JS as possible.

My first pass went like this:

function contrast(c) {
    var av = (parseInt(c.substring(1,3),16) +
              parseInt(c.substring(3,5),16) +
              parseInt(c.substring(5,7),16)) / 3;
    av = (av >= 100)? av-100:av+100;
    return "rgb(" + av +"," + av + "," + av + ")";
}

A quick overview of what's happening here. c is the 6-character hex color (sans the "#"). The first JS statement uses the substring function to break the hex color string into its three 2-character hex pairs, which are then passed to parseInt to convert them to decimal values. Then we find the average by adding them and dividing by 3.

So, FF0000 (pure red) becomes FF+00+00 becomes 255+0+0 becomes 255/3 becomes 85.

The function then looks at this average and, using 100 as its "bias" point, either adds or subtracts 100 (an arbitrary value that produced the best results for our needs). The last line returns a greyscale RGB value (perfectly valid in CSS! No need to convert back to hex!).

Now the fun: I sent this off to another webdev for review and challenged him to make it even shorter. He came back with this:

function f(c,n) {return parseInt(c.substring(n,n+2),16);}

function contrast(c) {
    var av=(f(c,1)+f(c,2)+f(c,3))/3;
    av+=100*(av>=100)?-1:1;
    return "rgb("+av+","+av+","+av+")";
}

Nice, but I pointed out that av wasn't being calculated correctly without an additional set of parenthesis. Plus, we could shave off a few characters by replacing substring with the shorter substr to the same effect. I countered with this:

function f(c,n) {return parseInt(c.substr(n,2),16);}

function x(c) {
    var av=(f(c,1)+f(c,3)+f(c,5))/3;
    av+=(av>=100)?-100:100;
    return "rgb("+av+","+av+","+av+")";
}

Of course, I hadn't thought to remove the whitespace yet :) His riposte:

function f(c,n){return parseInt(c.substr(n,2),16);}
function x(c){var a=(f(c,1)+f(c,3)+f(c,5))/3;c=100;
  a+=(a>c)?-c:c;c=",";return "rgb("+a+c+a+c+a+")";}

Bested but not broken by his ingenious re-use of local variables, I nonetheless proclaimed victory by deleting the requirement for such a JS function from the spec, reducing the necessary code to:

Don't ever let it be said I don't think outside the box!

Memory leaks explained

2005-04-12T08:06:00.000-07:00

If you're new to building complex web apps that use tons of JavaScript-powered DOM manipulation, you are hereby required to read Joel Webber's excellent article DHTML Leaks Like A Sieve, which eloquently summarizes the challenge of memory leakage in JS-heavy applications.

You may in fact wish to bookmark Joel's weblog and follow along as he unearths neato facts about Google Maps and other modern web apps.

IE6 opacity filter caveat

2005-04-08T12:11:00.000-07:00

This one was a real pain. I was lucky to guess the solution.

I was working on a very small function to set alpha transparency on elements. This is what I came up with:


var ie = (document.all) ? 1 : 0;
var p = (ie) ? "filter" : "MozOpacity";

/* n is the element node
   v is the opacity value, from 0 to 100. */

function op(n,v){
    v = (ie) ? "alpha(opacity="+v+")" : v/100;
    n.style[p] = v;
}

(Yes, I know I left Opera and Safari/KHTML out of the equation.)

This function worked great in Firefox but nothing was happening in IE6. I tried a bunch of different tweaks, none of which worked. Adding an alert(n.style.filter); at the tail end of the function returned "alpha(opacity=50)" indicating that the value was being set correctly for IE6. But the element still rendered at 100% opacity.

Finally, I threw the function out altogether and applied the filter directly to the DIV element via CSS:

<div id="myDiv" style="filter:alpha(opacity=50);">
<img src="MyImage.gif" alt="Some Image Here" 
  width="50" height="50" />
<br />
This should be transparent.
</div>

But it still didn't work! IE6 stubbornly ignored the opacity rule. Even more confusing was that moving the opacity rule to the image alone did work. But only on the image, of course.

<div id="myDiv">
<img style="filter:alpha(opacity=50);" src="MyImage.gif" 
  alt="Some Image Here" width="50" height="50" />
<br />
This should be transparent.
</div>

I really needed the opacity applied to both the text and image. I was about to give up when it occurred to me that maybe the image width and height dimensions has something to do with it. By default, a block element takes on the width of its containing element and height of its content, but maybe IE6 was ignoring this when applying the alpha filter. So I tried this:

<div id="myDiv" 
  style="filter:alpha(opacity=50);
     width:100%; height:100%;">
<img src="MyImage.gif" alt="Some Image Here" 
  width="50" height="50" />
<br />
This should be transparent.
</div>

Yes! Opacity was now being applied to both the image and the text. I removed opacity rule from the DIV and was then able to correctly set opacity via the JavaScript function.

I don't have the luxury of testing this across the different flavors of IE, but it appears that alpha opacity in IE6 requires certain elements to have a specified width and height. What's funny is that when I tried Googling for answers to my problem, I found a ton of working examples that used opacity in IE6 successfully. Looking back now, all of those examples specified a CSS width and height on the element, but didn't make any specific mention of it as a requirement for IE. Removing the width and height caused those examples to fail, too.

UPDATE: Dean Edwards points us to the MSDN documentation for this little-known behavior. IE filters only apply to elements with "layout."

Variable scoping gotchas

2005-04-06T10:50:00.000-07:00

Phil points to this great bit by Scott Issacs about JavaScript variable scoping. I've seen hardcore programmers as well as JS newbies make the same simple mistake:

function Foo() {
  bar = 1;
}

You might assume bar is private to Foo, but you'd be mistaken. Variables declared without the var operator are global by default. The correct syntax is:

function Foo() {
  var bar = 1;
}

Check out Scott's weblog for more scripty goodness.

Make your Apache HTTP errors more Ajax-friendly

2005-03-29T20:40:00.000-08:00

Applications that use remote scripting or Ajax-style communications can have problems when things go wrong at the server end. How does one detect a 404 or 500 error inside your hidden IFRAME, and how can an application be designed to handle such an error?

A client-side developer would probably suggest walking the DOM tree out to the IFRAME document and looking for the status text. But why not make it easier by having the server hand back HTTP errors to your application as JavaScript? This can be done with relative ease with Apache (I'm sure other servers can be configured similarly) with three basic steps:

Create a custom error page
Include JavaScript in the error page that interacts with the application (via the containing frame or IFRAME)
Use Apache's ErrorDocument directive to tell the server to deliver the custom error page when an error occurs

Below is a sample error page written in PHP. Apache provides the basic variables needed to determine the status; here, we just pluck them from PHP's global variables and plug them into a JavaScript block. Once loaded, the JavaScript looks for an onServerError handler in the parent window (assuming the page request is made from a frame or IFRAME) and invokes it with the HTTP status information.

<?
  /* error.php */
  /* this line ensures the client gets the HTTP status */
  header("Status:" . $REDIRECT_STATUS);
?>
<!-- include DOCTYPE of choice here -->
<html>
<head>
  <title>Error <? print $REDIRECT_STATUS; ?></title>
  <script>
    var win = (window.parent) ? window.parent : window;
    if (win.onServerError) {
      win.onServerError(
        {
          status:'<? print $REDIRECT_STATUS; ?>',
          url:   '<? print $REDIRECT_URL; ?>',
        }
      );
    }
  </script>
</head>
<body>
  <h1>Error <? print $REDIRECT_STATUS; ?></h1>
  <p>
     This page should have invoked a 
     JavaScript onServerError handler 
     if one was provided.
  </p>
</body>
</html>

We'll save this file as error.php and place it in a directory named /rs-errors/. Next, we have to tell Apache to use our error page for selected HTTP error statuses. We can do this by adding ErrorDocument directives to an .htaccess file placed inside the directory at which our remote scripting requests are targeted. For example, if you're sending requests to http://appserver.example.com/api you'll want to put these in the .htaccess file for that directory:

ErrorDocument 404 /rs-errors/error.php
ErrorDocument 500 /rs-errors/error.php

Now, if a 404 or 500 error occurs inside of /api Apache will use our error.php as the error document served to the browser.

It should be relatively simple to implement this in a JavaScript application now:

<script>
  function onServerError(e) {
    switch (e.status) {
      case '500':
        // handle a 500 error here
        break;
      case '404':
        // handle a 404 error here
        break;
    }
  }
</script>

...

<iframe src="http://appserver.example.com/api/some-bogus-request-here">
</iframe>

When the IFRAME attempts to load the bogus URI, Apache will throw a 404 error and invoke error.php. The JavaScript in the head of our error page will attempt the onServerError handler defined in the application. The application can now decide how to best communicate the error state to the user without appearing broken.

Caveat: don't forget that IE will attempt to serve up its own custom 500 page from the local machine, so it might be a good idea to pad your error page with ~~512K~~ 512 bytes (or more) of whitespace or commented text to convince IE that your error is the one to show.

If you prefer an "Ajax (The X Is For 'XML' Dammit!)" approach, you can easily write your custom error page to deliver HTTP statuses as an XML payload instead of JavaScript. I prefer JavaScript myself since I don't have to parse it, but XML might be preferred if you're sharing data across different apps on different platforms.

Reference:

Dynamic old-school IFRAMEs

2005-03-28T08:49:00.000-08:00

Three years ago I lifted the following code for dynamically creating an IFRAME from Eric Costello's ADC article, Remote Scripting With IFRAME, and I've used some variation of it for years in my own development work. I modified it a bit since its original purpose was as part of a remote scripting engine; all I wanted was the IFRAME-generation code. Check out the crazy bit where Eric "fakes up" the IFRAME for IE5.

It's a wicked piece of code for the time it was written. It's one of those techniques that you can only learn about after several hours of doing — that is, messing around in a browser trying to get stuff to work. There's just no textbook for this kind of stuff.

Dunno if it works in Safari, Konqueror or Opera, although I'd love to hear if it does or doesn't.


/*
dynamic IFRAME code
original JS by Eric Costello (glish.com) for ADC
http://developer.apple.com/internet/webcontent/iframe.html
*/

var iframe, iframeDocument;
var iframeID = "MyHiddenIFrame";

if (document.createElement) {   
  try {
   
    var tempIFrame = document.createElement('iframe');
    tempIFrame.setAttribute('id',iframeID);
    tempIFrame.style.border = '0px';
    tempIFrame.style.width = '0px';
    tempIFrame.style.height = '0px';
    iframe = document.body.appendChild(tempIFrame);
      
    if (document.frames) {
      
      /* IE5 Mac only allows access to the document
      of the IFrame through frames collection */
        
      iframe = document.frames[iframeID];
    }
      
  } catch (ex) {
    
    /* This part is CRAZY! -- scottandrew */

    /* IE5 PC does not allow dynamic creation and 
    manipulation of an iframe object. Instead, we'll fake
    it up by creating our own objects. */
      
    var iframeHTML = '\<iframe id="' + iframeID + '"';
    iframeHTML += ' style="border:0px; width:0px; height:0px;';
    iframeHTML += '"><\/iframe>';
    document.body.innerHTML += iframeHTML;
    iframe = new Object();
    iframe.document = new Object();
    iframe.document.location = new Object();
    iframe.document.location.iframe = 
      document.getElementById(iframeID);
    iframe.document.location.replace = 
      function(location) {
        this.iframe.src = location;
      }
  }
  
  if (iframe.contentDocument) { // For NS6
    iframeDocument = iframe.contentDocument; 
  } else if (iframe.contentWindow) { // For IE5.5 and IE6
    iframeDocument = iframe.contentWindow.document;
  } else if (iframe.document) { // For IE5
    iframeDocument = iframe.document;
  } else { // damn!
    alert("Error: could not find IFRAME document");
  }
}

Cool rounded corners with CSS and Javascript

2005-03-26T14:13:00.000-08:00

Rounded corners in web design are neat, but usually require a handful of semantically meaningless positioned elements to achieve. Alessandro Fulciniti simply inserts those elements with some unobtrusive JavaScript. Check out the JS code and take a look at his custom getElementsBySelector() function, too.

A global event...in Firefox?

2005-03-22T16:03:00.000-08:00

This is kind of nice:

function someHandler(a,x,y){
    alert(a.type);
}

<a href="#"
   onclick="someHandler(event,'x','y'); return false;">
   Do it</a>

Apparently, Firefox does support a global event object when passed as a parameter to an event handler, so the above code works in both Firefox and IE on Windows. You can't call window.event inside the function though, else Firefox will complain.

I've been doing the check for e for so long (see the previous post), like, waaaaay back in my DynAPI v1.0 days, that I hadn't noticed this technique was available.

Really basic event confusion

2005-03-21T00:54:00.000-08:00

This is another no-brainer, but I still see this all the time:

function someEventHandler(e) {
    alert(e.type);
}

Works in Firefox and other Moz browsers. IE pops an error. Why? Because in IE browsers, the event (e) object is a property of the window, not a local argument passed to the handler. So e is undefined, in IE's view. To get around this, try:

function someEventHandler(e) {
    if (!e) e = window.event;
    alert(e.type);
}

The amusing thing about having to post this is I hear this question a lot from developers who are used to coding only for Firefox. How times change, eh?

Cross-domain security woes

2005-03-18T19:20:00.000-08:00

You're developing an Ajax-based application. You have an application server at example.com which serves up all your JavaScript, HTML and CSS, and a data server at xml.example.com which delivers all the XML data to the application via a hidden IFRAME.

You know that cross-domain security will prevent any JavaScript from accessing the data in the IFRAME. so, you configure the data server to set the security domain of the IFRAME to "example.com" — the common suffix between the two domains — with a small piece of JavaScript:

<script type="text/javascript">
  document.domain="example.com";
</script>

Having done this, you test your application and get a "permission denied" error. What happened?

Depending on your browser, it may not be enough to only set the security domain of the IFRAME. You must set all of the frames and windows to the same domain, too. This is true even if the domain name you're trying to set already matches the domain of the server that's currently serving the page. For example, if you have two frames with pages served from example.com and you use JavaScript to set the security domain of one frame to "example.com" the frames will be unable to communicate.

Older browsers might let you get away with this.

About this site

2005-03-18T17:54:00.000-08:00

The Strange Zen Of JavaScript is an offshoot of and successor to Delimiter, a weblog about web application design focused on JavaScript, CSS, Flash and other client-side technologies. Unlike Delimiter, this weblog will try to keep the focus on JavaScript quirks, caveats odd hacks, curiosities and collected wisdom, and only delve into topics like CSS where they intersect. I'm also going to try and refrain from commenting on every cool JS-based app released unless there's a useful technique or exploit to be learned from reverse-engineering.

I got the idea for SZOJ while perusing the Delimiter archives and rediscovering a series of numbered posts dealing with strange little JS gotchas I'd uncovered. I decided to consolidate these posts in a new weblog, and I'll probably end up plundering some old content from my formerly-all-scripting site scottandrew.com and seeing how it's held up.

Some of these posts might contain stuff that advanced developers will find forehead-slappingly obvious, but everyone starts somewhere. My hope is that web app developers who run into trouble might Google this site and find an answer, or at least something interesting.

Feel free to send me any JS weirdness you discover, and I'll be happy to post it. Be sure to include a name and a URL so I can credit you. Here's the address.

XMLHTTP and readyState

2005-03-18T17:05:00.000-08:00

Given how the world of web design is currently enamored with Ajax — a.k.a. Asynchronous JavaScript + XML, a.k.a. remote scripting with XML messages, a.k.a. a technology that back in 2000 was considered way too rawk star and subversive until Google started playing with it recently — I thought I'd unearth this oldie-but-goodie from 2002. Enjoy.

Microsoft's XMLHTTP object is an ActiveX component that lets you perform HTTP requests. The object has four different states that it cycles through when performing a request. One of those states is called "interactive" and is decribed as such (from the MSDN documentation):

(3) INTERACTIVE
Some data has been received. You can call responseBody and responseText to get the current partial results.

...meaning that at that point you should be able to examine the contents of the response so far. Let's try this, shall we?

var xmlHTTP = new ActiveXObject("Microsoft.XMLHTTP");
xmlHTTP.onreadystatechange = handleStateChange;

function handleStateChange()
{        
    if (xmlHTTP.readyState == 3)
    {
        alert(xmlHTTP.responseText);
    }
}

xmlHTTP.open("POST","/some/uri",true);
xmlHTTP.send();

Execution of this code produces an error in the handler:

The data necessary to complete this operation is not yet available.

...which troubles me greatly. Waiting until readyState is 4 (complete) works perfectly, but there's an added complication: the URI /some/uri establishes a persistent connection, which means that unless the connection is terminated by the script or the server, readyState will always be 3 (interactive). According to the docs, I should be able grab the incomplete response from the server at this time, but apparently not. Possible reasons:

the MSDN documentation is a big fat lie incorrect
the XMLHTTP object has a huge buffer to fill before it will make the response available
the object needs to see some sort of delimiter, like a null byte, as a signal to make the response text available
I'm horribly misunderstanding the whole thing

UPDATE 3/4/2004: many. many people have written me to ask if I have found a workaround since I first posted this. I'm sorry to say that I have not.

Inline script documentation with comment hacking

2005-03-18T16:47:00.000-08:00

I'm still in love with Tantek's extremely clever way to include HTML documentation for JavaScript code inside the same document using comment hacks.

The particular (and peculiar) sequence of SGML comments  and C-style comments /* */ allow the document to be parsed as either HTML or JavaScript depending on the way it's imported into the document. Load the script with a SCRIPT element and it's interpreted as JavaScript, but load the script directly into the browser and it's displayed as glorious, technicolor HTML. One caveat: you must leave off the .js file extension so that IE will interpret the file as text/html when you drop it into a browser.

Table rows...revealed!

2004-07-22T14:23:00.000-07:00

By setting the CSS rule display:none on a TR element, you can collapse and hide whole rows of table data from the user. This is a popular technique for managing the visual display of tabular data in a web application.

However, there's a small challenge that arises when we attempt to make the TR visible. The intuitive thing to try is to set the CSS display property to block. IE is perfectly happy with this, but Firefox 0.8 mangles the final rendering, as this screenshot shows:

The proper CSS rule should be display:table-row. Firefox like this a lot better and expands the TR without the mangling. But IE for Windows will throw an error, because — unlike its MacIE cousin — it doesn't support table-row.

What to do? Aside from waiting for IE to support table-row or for Firefox to support block in place of it, the simple solution is to set the CSS display property to an empty string. Both Firefox and IE should fall back on their respective default values.

Try this example:

<script type="text/javascript">
function applyDisplay(value)
{
 document.getElementById("foo").style.display = value;
}
</script>

<table border="1">
<tr><td>R1 C1</td><td>R1 C2</td><td>R1 C3</td></tr>
<tr><td>R2 C1</td><td>R2 C2</td><td>R2 C3</td></tr>
<tr id="foo"><td>R3 C1</td><td>R3 C2</td><td>R3 C3</td></tr>
</table>

<p>
<a href="#" 
   onclick="applyDisplay('none'); return false;">
   Apply "display:none" to Row 3
</a><br>
<a href="#" 
   onclick="applyDisplay('block'); return false;">
   Apply "display:block" to Row 3
</a> (error in IE)<br>
<a href="#" 
   onclick="applyDisplay('table-row'); return false;">
   Apply "display:table-row" to Row 3
</a> (mangled display in Firefox)<br>
<a href="#" 
   onclick="applyDisplay(''); return false;">
   Apply "display:" to Row 3
</a> (should work in both)
</p>

What's in a NAME?

2004-07-21T14:21:00.000-07:00

The little-used getElementsByName() method is part of the DOM Level 1 specification and is supported by both Internet Explorer and Mozilla/Firefox. getElementsByName() is part of the HTML application of the DOM, meaning it is specific to HTML documents, and explains why you won't find it in the DOM Core spec, which applies to any XML-like document.

Given a string as an argument, getElementsByName() retrieves all elements that have a NAME attribute that matches that string. Or does it?

<div name="foo">DIV one</div>
<div name="foo">DIV two</div>
<div name="foo">DIV three</div>

<script type="text/javascript">
var divs = document.getElementsByName("foo");
alert(divs.length);
</script>

Moz/Firefox will report a length of 3. MSIE will report a length of zero. Huh?

According to the HTML 4.01 spec, the only elements that support NAME attributes are BUTTON, TEXTAREA, APPLET, SELECT, FORM, FRAME, IFRAME, IMG, A, INPUT, OBJECT, MAP, PARAM and META. So to place a NAME inside a DIV is actually invalid HTML.

Moz/Firefox doesn't have a problem with this and will happily return all three DIV elements. But MSIE treats it the invalid NAME attribute as an expando attribute and excludes those elements. From the MSDN documentation:

"Elements that support both the NAME and the ID attribute are included in the collection returned by the getElementsByName method, but not elements with a NAME expando."

It seems that MSIE's implementation of getElementsByName() is actually more compliant with the W3C standard than Moz/Firefox's. Just not nearly as useful.

Form values and innerHTML

2004-07-20T14:20:00.000-07:00

Alan Taylor has discovered another intriguing JS quirk: changing form values in Internet Explorer actually changes the underlying HTML structure, so that the value returned by innerHTML is altered. See Alan's example here.

Script-killer comments

2004-07-16T14:16:00.000-07:00

This one seems like a no-brainer, but it had several of our best JS experts stumped for a good while, until we saw what was right in front of us all along.

A script for preloading images was failing. The source was similar to this (imagine 20 or more lines of unbroken script):

<script type="text/javascript">
<!-- preload_images ("header1.gif", "header2.gif", "logo.gif");
//-->
</script>

Notice how the first line of script is preceded by an HTML comment delimiter. This prevented the preload_images function from running, as the JS interpreter just skipped over the entire line. For the want of a linebreak, the script was hosed.

This seems to be common when JS is generated from some backend process. The above JavaScript was generated from a server-side application written in C++.

Window args and errors

2004-07-15T14:13:00.000-07:00

What's wrong with this picture?

window.open("example.html","Example Window",
"scrollbars=no");

Moz/Firefox will pop open a new window, but IE6 will throw an "Invalid Argument" error. Why?

The second argument to window.open is the name of the window. In IE6, this cannot contain any spaces or special characters. Some people mistakenly think this argument is for the title of the window. So they put in something human-readable (like "Example Window"), thus the error.

Array length headaches

2004-07-14T14:11:00.000-07:00

A co-worker of mine stumbled across this little gem:

var foo = ['a', 'b', 'c', 'd',];
document.write(foo.length);

Moz/Firefox will print 4. IE6 will print 5. Why?

Look again at the array. See the extra comma on the right? IE6 interprets this as an additional element with an undefined value. Moz/Firefox ignores it.