Now that the JavaScript Raytracer has been released, I am free to discuss a few things that I learned while creating it:

• If you create a checkbox form element with the DOM in Internet Explorer for Windows, and set its checked property to true, and then add it to the page with the appendChild method of some other element, it will not be checked.
• If you create a radio button form element with the DOM in Internet Explorer for Windows, not only will it ignore the same checked property, it will not be checkable at all. This means that when the user clicks on it, it will remain unchecked, no matter what. Great for confusing your users!
• If you create a select form element (a drop down menu) with the DOM in Internet Explorer 5.x for Windows, and attempt to add options to it with its options array, before it has been added to the page, the browser may crash. This isn’t a problem in Internet Explorer 6.
• Multiple nested <fieldset> elements display very slowly in Internet Explorer for Windows when their contents are changed via the DOM or innerHTML.
• <label> elements created with the DOM in Internet Explorer for Windows don’t behave correctly when clicked on.
• Raytracing with JavaScript is frickin’ slow.

Mozilla appears to render images faster than Internet Explorer, and consumes slightly less memory. I used it for all of the 320x240 renders that are displayed on the help page.

I was happy to find that Opera 7 handled the raytracer almost flawlessly. It has some minor bugs with the interface, but nothing that gets in the way of using it. The only significant problem it had was that the “pixel size” couldn’t be changed, because it doesn’t support document.styleSheets. Not a biggie, when you compare it to Opera 6. *shudder*

It’s possible that I’ll create a version 2.1 sometime in the distant future. This would contain mainly interface enhancements. I created a great JavaScript object that controls the interface, and I’d like it to have the potential to be used elsewhere, so this is what I will work on. It needs a lot of little changes. Among the enhancements would be a new way of saving workspaces that doesn’t grow so quickly. (The final version of the flower’s workspace took almost 50 KB of disk space.)

However, before that, I’ll be working on writing a raytracer in C++: Slimeray. (Clever name, eh?) I plan for this to be similar to POV-Ray, and use a scripting language nearly (though not entirely) identical to POV-Ray’s SDL (Scene Description Language). It certainly won’t support all of POV-Ray’s features, but it should have some advantages over POV-Ray. For instance, I plan for it to have much better animation support, without having to re-parse the entire scene file for every frame. Other desired features include fast parsing times when macros, include files, and while loops are used, and little things like blurred reflection, motion blur, and improved textures.

That’s a while off, however. All I’ve written is some of the parsing functions. The basic raytracing algorithms can be mostly copied from the JavaScript Raytracer, but lots of enhancements will be necessary to speed it up (including an efficient bounding hierarchy).

Zeldman today did a very smart thing with his JavaScript style switcher. He noticed that Mozilla based browsers have a bug that causes them to treat the following incorrectly:

<a href="somewhere.html" onclick="doSomething(); return false;">clickie</a>

When such a link is clicked on, browsers should run the doSomething function, and then, upon seeing return false, do nothing else. Zeldman noticed that Mozilla and Netscape ignored the return false, and incorrectly followed the link to somewhere.html. His solution? Make the hyperlink link to a page that explains the browser bug.

This is hundreds of times better than resorting to the href="JavaScript:doSomething();" alternative. Why? Because it works in any browser that supports HTML correctly, even if that browser doesn’t understand JavaScript. If the browser doesn’t run scripts, it will simply link the user to the page which explains to them that their browser can’t handle the link they clicked on. In addition, if someone tries to follow the link by right-clicking and selecting “Open Link in New Window,” they won’t get a JavaScript error. That is how JavaScript is meant to be used: it complements HTML, it shouldn’t replace it.