I like the simplicity of that solution. In fact, I wish I thought of it a month ago when I needed it! Instead, I came up with a different, but possibly nicer, solution in the end.

My solution was to implement a simple Console object that wrapped the FireBug console object. The wrapper object checks whether FireBug exists, and if so, calls the appropriate console method. So in my client code, instead of calling console.log(...), for example, I call Console.log(...).

function Console () {
}

// To turn off all console features, set Console.enabled to false.
Console.enabled = true;

// Console.log(object[, object, ...]) - Print a message in the log. If
// FireBug is enabled, print the message in the FireBug
// console. Otherwise, do nothing.
Console.log = function () {
    if (Console.enabled && window.console && window.console.log) {
        console.log.apply(console, arguments);
    }
};

There are a couple of benefits to this. First of all, when you want to disable all logging, all you have to do is set Console.enabled to false. This is great if you make extensive use of the FireBug logging features, and don’t want to permanently remove all of the logging. Second of all, you can use this object from multiple different Javascript files, without having to write more code.

In the above code snippet I only implemented a wrapper for the console.log method; but you can wrap any or all of the console methods. Here are some more.

// Console.debug(object[, object, ...]) - Writes a message to the
// FireBug console, including a hyperlink to the line where it was
// called.
Console.debug = function () {
    if (Console.enabled && window.console && window.console.debug) {
        console.debug.apply(console, arguments);
    }
};

// Console.info(object[, object, ...]) - Writes a message to the
// console with the visual "info" icon and color coding and a
// hyperlink to the line where it was called.
Console.info = function () {
    if (Console.enabled && window.console && window.console.info) {
        console.info.apply(console, arguments);
    }
};

// Console.warn(object[, object, ...]) - Writes a message to the
// console with the visual "warning" icon and color coding and a
// hyperlink to the line where it was called.
Console.warn = function () {
    if (Console.enabled && window.console && window.console.warn) {
        console.warn.apply(console, arguments);
    }
};

// Console.error(object[, object, ...]) - Writes a message to the
// console with the visual "error" icon and color coding and a
// hyperlink to the line where it was called. If FireBug is not
// enabled, an alert box is displayed, requesting that the user enable
// FireBug to debug the problem.
Console.error = function () {
    if (Console.enabled && window.console && window.console.error) {
        console.error.apply(console, arguments);
    } else if (Console.enabled) {
        var errMsg = "";
        for (arg in arguments) {
            errMsg += arg;
        }
        alert("An error has occurred. Please enable FireBug to debug it. " + 
            errMsg);
    }
};

// Console.assert(expression[, object, ...]) - Tests that an
// expression is true. If not, it will write a message to the console
// and throw an exception.
Console.assert = function () {
    if (Console.enabled && window.console && window.console.assert) {
        console.assert.apply(console, arguments);
    } else if (Console.enabled && arguments[0] == false) {
        alert("An error has occurred. Please enable FireBug to debug it. " + 
            arguments[1]);
    }
};

// Console.dir(object) - Prints an interactive listing of all
// properties of the object. This looks identical to the view that you
// would see in the DOM tab.
Console.dir = function () {
    if (Console.enabled && window.console && window.console.dir) {
        console.dir.apply(console, arguments);
    }
};

I’ve always been of the opinion that writing standards-compliant XHTML 1.x is the best way to develop a website or a web application. By “standards-compliant”, I mean  writing XHTML code that validates using the W3C Validator.

As it turns out, however, I have never written XHTML that is completely standards compliant, since I’ve never changed the MIME type specified by the web server when sending XHTML pages to application/xhtml+xml. According to the article, unless the MIME type is specified as so, web browsers will continue to use their HTML parsers on your page, instead of their XHTML parsers. Unfortunately, Internet Explorer (even version 8 ) doesn’t even have an XHTML parser. So setting application/xhtml+xml as the MIME type causes anyone who visits an XHTML web page to be prompted to download the file in Internet Explorer.

This practically eliminates the possibility of writing XHTML code that actually utilizes the XHTML parsers of web browsers. Even WordPress uses XHTML, but with the HTML MIME type (text/html), which is not considered good practise by the author of Beware of XHTML, and indeed, most of the Web community. (See Wikipedia for more about this. There is some dissent on this opinion, which I think has value.)

The part that bothers me most about using HTML 4.01 is that it feels like a step backwards in progress. XML is a better metalanguage than SGML, the parent language of HTML. XML has many advantages, such as embedding multiple different languages in a single document. Why should we return to using an older standard? Well I found a pretty good explanation in the HTML 5 draft specification.

With all the major players in the web industry endorsing HTML 5, does XHTML have a future? Yes, according to Tim Berners-Lee. He describes why here. So I guess I shouldn’t feel so bad using HTML. Eventually we’ll make the switch, but just not yet.