Slime Update Archive - February 2003
The truly observant will have noticed a new link in the menu bar: the email form. That’s right, folks, now you can avoid the hassle of
mailto links and contact me directly through a form! There’s no real advantage to this. The main reason it’s there is so that I
have something to link to when I encourage you to respond to my posts. So, uh, what do you think?
I couldn’t find a reason to update my page, so I decided the only thing I could do was redesign the whole thing. Now I can update it to tell you that I redesigned. See?
The general consensus seems to be that the old design was better. That’s OK, I like this one. If you prefer the old one, take a look at the new “Style Sheets” section in the menu bar; you can change it to the old style (”cleanwhite”) and it will remember your preference in the future if you have cookies enabled.
Oh, yeah, that’s the cool thing about this: despite the drastic change in appearance, the HTML has hardly changed at all, and does not change when you change the active style sheet. Bow to the power of CSS.
Let me know what you think.
Spent all day yesterday writing a program in C for a class this morning, in which I learned some assembly language. Spent the next two hours studying for an exam which I just took. Will spend the next two hours doing another homework assignment for my next class, which will last two hours, followed by working on a homework assignment due in 24 hours for my last class of the week.
After which I will play Warcraft 3 for the entire weekend.
- If you create a checkbox form element with the DOM in Internet Explorer for Windows, and set its
checkedproperty to true, and then add it to the page with the
appendChildmethod 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
checkedproperty, 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
optionsarray, 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
<label>elements created with the DOM in Internet Explorer for Windows don’t behave correctly when clicked on.
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*
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.
<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
This is hundreds of times better than resorting to the
handle the link they clicked on. In addition, if someone tries to follow the link by right-clicking and selecting “Open Link
If you don’t have a clue what to do with it, look for the “Load Preset” dropdown menu, select one from the list, click “Load,” and then click “Render” at the bottom of the page.
An issue has been fixed that was casing the “Load Preset” dropdown menu to be invisible in Internet Explorer 5.x. Sorry about that. If you use IE 5, try using it again - this time, you should be able to load the presets.