Web development:

It seems as if we're slowly adding more and more languages to the web development mix. We had HTTP and HTML, then we added JavaScript for scripting and CSS for styling, and we also have XSLT for transformations, XML for data transfer, and not including MathML and SVG, oh my! One client-server protocol, one markup language, one declarative expression language, one scripting language, what is the world coming too?

(I should add, for the benefit of any Microsoft coders out there: if you don't get support MathML and SVG in IE right soon you'll end up displaying GIFS and loading klunky Adobemedia plugins when the rest of the world is dragging and dropping formulas and vectors, not to mention serving all this stuff inline that not even a plugin will help you with, no siree. - see Paul's comment below
)

Should I get worried? Well, I know all this stuff, so no. Also, it is still easy to get started. You don't have to know HTTP to know HTML, which is the substrate upon which the rest is built.

Also, I would add that we've got these things for a reason: having played around with REST XML APIs + JavaScripting XSLT + CSS + XHTML, I have to say that this is a sweet combo that makes me emit an evil laugh everytime I do something ridiculously complex in ten lines of JavaScript.

Anyway, this leads me to the conclusion that a) dumping XML on the client for transformation is not intrinsically wrong, b) JSON-RPC is nice, c) passing HTML clips via XMLHttpRequest is not an ideal situation but works.

Also, despite me not working on Gradient for ages, I still believe that the web is missing a real-time control channel and the ability for clients to communicate more-or-less directly with each other, and that XMPP is the solution to that.

What's changed is that Firefox 1.5 supports SVG now... I'm thinking of digging up the old and obsolete JiM or fiddling with Mozchat and seeing if I can wire either of them directly into the DOM.

When creating DOM-related library / utility functions in JavaScript:

Using document to do stuff like createElement is a good idea 99% of the time, and the other 1% of the time, guess what - I've loaded an XMLDocument from XMLHttpRequest. Therefore, take your operand element and use element.ownerDocument to construct stuff.

This advert was paid for by the Council for Prevention of Headaches in Web Developers.

Attention Java webapp developers: No JSP in your JavaScript.

This has been both a confession and a public service announcement.

Trust me, it's a bad idea, except maybe to rewrite the odd URL...

Before somebody else says it:

I get the sinking feeling that half a dozen bugs that I've observed will turn out to be unreproducible, and therefore my fault, and therefore yet another case of hubris on my part. Oh well, such is life.

One more annoying IE6 bug:

Assuming this CSS:

div { border: solid black 1px; }

And this HTML:

<div id="foo" style="background-color:lightgrey; border:solid red 1px">...</div>

When I evaluate $("foo").style.border=""; I expect to see a div with a light grey background and a black border. And lo, Mozilla doth fulfill my expectations, whereas the venerable IE nuketh not only the element-level style declaration, but also the entire cascade of styles applied heretofore, despite MS and IE having INVENTED Cascading Style Sheets.

Much as I sympathize with frustration at the W3C's glacial process of standards-making (in 'net years), it does seem as if people who don't pay attention to standards bodies end up producing products markably inferior to develop for than those who do.

Grr.

The only cross-platform way to add dynamically parameterized events to DOM elements:

To explain what I mean. This is static:

<div onclick="foo()">...</div>

This is dynamic, unparameterized:

div.setAttribute("onclick", "foo()"); //not in IE6

//or:

div.onclick = foo; // works everywhere

This is dynamic, parameterized (and works on Mozilla):

div.setAttribute("inclick", "foo(this, 1, 2, 3, 'bar')")

This allows you do do stuff like construct your function as you would a string. But you can't do div.onclick = foo; and pass arguments as well. So you have to do this:

div.onclick = function() { foo(this, 1, 2, 3, "bar"); };

Which basically creates an anonymous function each time it's evaluated. If you want to construct your function call as a string, do that and then use eval(). (I would also add that if you have to do that here, you have bigger problems than dynamically parameterized events.) But hey, it works.

You might wonder why I'm passing this when I could use the event target instead. First, getting the event target is non-cross platform, and second, I might want to do foo( $("id") ...), which again is more cross-platform than fireEvent or whatever.