Dashing All the Way... Not

In programming, nothing ever just happens. There aren't any gremlins or magical incantations that cause code to work. Programming is about logic and good sound reasoning. If your code doesn't work, there's a really good explanation. The challenge is finding that explanation.

As a web developer, you sometimes see really weird problems like the one I saw today.

In HTML, how do you add a comment?

You'd do this --

<!-- This is a comment -->

and you'd be right of course, but what if you did this --

<!-- This is a comment -- at least I think it is! -->

Is that a comment? Well, sort of. In the HTML 4.0 specification, "--" or two hyphens is considered the comment close delimiter whereas ">" is considered to be the markup declaration close delimiter.

Here's the explanation directly from the spec --

White space is not permitted between the markup declaration open delimiter(""). A common error is to include a string of hyphens ("---") within a comment. Authors should avoid putting two or more adjacent hyphens inside comments.

Information that appears between comments has no special meaning (e.g., character references are not interpreted as such).

Note that comments are markup.

So, what actually happens when you use the hypens in the middle of a comment? Here's an example --



If you're using Firefox, you'd see this --

The comments are visible. On any other browser, IE, Safari or Opera, you'd see a normal page --

So, using hyphens in an HTML comment breaks pages on Firefox. Keep that in mind the next time you put in a comment.

Note that in our example, we're specifying a HTML 4.01 DTD. We're using a "strict" DTD, but the problem would still occur if you'd specify a "transitional" or "frameset" DTD.

If you don't specify the HTML 4.01 DTD, you won't see this problem in Firefox.

Additional information and discussion is found on Ben Buchanan's the 200ok weblog.

Have fun!

On-demand JavaScript :: IE6/7 and Firefox 2.x

Last year, there was a lot of talk about on-demand JavaScripting. A good bit is found on Michael Mahemoff's Ajax Patterns Wiki. If you've never heard of it, you can read Michael's primer here.

Basically, on-demand JavaScripting helps you lazy load objects. When you need it, load it. It's simple.



You can run it here.

When you click on the "Load JavaScript" button, we're dynamically loading a JavaScript library by creating a script tag and then setting the src.

Then, the library loads and all the JavaScript is implicitly evaluated ( no eval is called ). You'll see an alert message appear saying that you've successfully loaded the JavaScript.

Close it and then the "Call method from new load" button is enabled. Click it and you'll see another alert message showing you the current page's HTML.

The whole exercise is to demonstrate that --

• You can load JavaScript dynamically by creating a script tag and then setting src
• You don't need to "eval" it

In fact, you can use the technique to "hack around" cross-domain issues and avoid using a proxy altogether. You can load JavaScript from any domain.

Though we can have lively debates on whether that's a good or bad thing, we're more interested in how the JavaScript was loaded.

From all the on-demand JavaScript examples that I've seen, they involve loading an external library, but what if we don't have an external library?

What if we just want to modify the body of the script tag to include new JavaScript? We might be loading the JavaScript from an iframe or some other external source and then slap it between script tags.

As it turns out, we can load JavaScript this way too, but we'll have to do it a specific way or it won't work in IE6 or IE7 ( I didn't try it for earlier versions of IE ) and like using "src", you don't need to explicitly evaluate the JavaScript.

Naturally, you might think that this works ( especially, since there's a general agreement that using innerHTML is the best and fastest way to dynamically update HTML ) --



Here's the example.

Try it in Firefox 2.x and it'll work. Then, try it in IE. We'll get the fabulously terse error message, "Unknown runtime error."

So, we try something along the same lines, but slightly different. Instead of updating with innerHTML, we'll create a text node using the string of JavaScript and then append that node as a child of the script element.



Here's the example.

IE chokes again, but this time with a bit more detail, "Unexpected call to method or property access". Sigh. It's beginning to look like one of those "many hours to solve" IE problems.

Fortunately, after a few more efforts, there's a solution. We'll use the "text" property found in the script node. Apparently, this is a Microsoft extension to the W3C DOM which works in Firefox 2.x. The best reference that I could find was here.



Here's the example that works in IE6/7 and Firefox 2.x.

We're done!

By the way, it's stuff like this that make using a JavaScript toolkit like Bindows worthwhile.

Have fun!