A few days ago, Google released their Closure Compiler project for optimizing JavaScript. Here’s what they write about the Closure Compiler:

The Closure Compiler is a tool for making JavaScript download and run faster. It is a true compiler for JavaScript. Instead of compiling from a source language to machine code, it compiles from JavaScript to better JavaScript. It parses your JavaScript, analyzes it, removes dead code and rewrites and minimizes what's left.

The interesting part of the Closure Compiler is that it not only removes whitespace, it also rewrites your JavaScript code to make it smaller and optimizes the code for better performance. My tests show that it can reduce JavaScript files by about 60% - and that’s before HTTP compression! Considering how much JavaScript a modern website uses, this is no less than amazing and highly useful.

The Closure Compiler comes in two flavors – a Java based command line tool and a RESTful API. I’ve been playing around with the API and it works great and very fast.

The code

The C# class I’ve written takes a JavaScript file and passes it through the API and then returns the compressed JavaScript as a string. The class contains one public and one private method and is only 47 lines of code including 16 lines of comments.

public string Compress(string file)

{

  string source = File.ReadAllText(file);

  XmlDocument xml = CallApi(source);

  return xml.SelectSingleNode("//compiledCode").InnerText;

}

 

private static XmlDocument CallApi(string source)

{

  using (WebClient client = new WebClient())

  {

    client.Headers.Add("content-type", "application/x-www-form-urlencoded");

    string data = string.Format(PostData, HttpUtility.UrlEncode(source));

    string result = client.UploadString(ApiEndpoint, data);

 

    XmlDocument doc = new XmlDocument();

    doc.LoadXml(result);

    return doc;

  }

}

How to use it

You can use the class to do various cool things. You can write a MSBuild or NAnt script that automatically compresses your JavaScript files as part of a continuous integration process or, as I prefer, write a HTTP handler to do the same but at runtime. Remember to output cache the compressed result. Here's an example of using the class from ASP.NET:

GoogleClosure gc = new GoogleClosure();

string script = gc.Compress(Server.MapPath("~/script.js"));

Remember that the class doesn't do any exception handling, so you might want to stick that in yourself.

Download

GoogleClosure.zip (905,00 bytes)

Recently I had to use iframes on a website conforming to XHTML 1.0 Strict. As you might know, the XHTML 1.0 Strict doctype doesn’t allow the use of iframes. The XHTML 1.0 Transitional doctype on the other hand, does allow you to use iframes, but I don’t like to use that doctype. The reason is, as the name implies, that it’s a doctype meant for make the transition from HTML into XHTML – a sort of a temporary solution.

When building new websites I like to use a strict doctype because it doesn’t allow for many of the style and behavioral tags that is much better placed in stylesheets and JavaScript.

What’s needed is a doctype that conforms to XHTML 1.0 Strict which also allows for iframes.

A solution

What I came up with was very simple, but may be considered a hack by some. Basically, I took the doctype declaration (DTD) of XHTML 1.0 Strict and added support for iframes. I found how iframes was supported in the transitional DTD and copied it to the Strict DTD. It allows for some attributes like width and height that the Strict DTD doesn’t, so I removed those and then added support for the allowtransparency attribute.

So to make iframes work on your own invalid XHTML 1.0 Strict page, just replace the doctype at the top of your pages with this new one:

<!DOCTYPE html SYSTEM "http://madskristensen.net/custom/xhtml1-iframe.dtd">

I suggest you download and host the DTD on your own server instead of using mine in case I forget to pay my hosting fee.

Check out the demo of XHTML 1.0 Strict with Iframe

A hack?

Some might say it’s a hack because by using this DTD the page is no longer XHTML 1.0 Strict. That is correct. It is now something new and different, but completely identical to XHTML 1.0 Strict with support for iframes. So it’s XHTML 1.0 Strict with Iframe.

XHTML have build in support for custom DTDs and thus this is completely supported and valid XHTML. If you don’t like using other doctypes than the few main ones created by the W3C then I have to ask why? What does it give you, your users or the quality of the page that this new one doesn’t?

In my book, it comes down to using a doctype that is based on known standards (XHTML 1.0 Strict in this case) so it still make sense to other devs when they read the markup. It’s also important that the DTD is strict (yep, this DTD is still strict), but most of all it’s important that the markup conforms correctly to the DTD so the entire page is valid. Remember, when using custom DTDs your page is still valid XHTML.

Note

I tried using XHTML 1.1 modules to build the DTD, but it never worked out for me. I got to the point where the iframe tag was valid, but not allowed in any other tags including body. I couldn’t seem to find a way to get full support for it. If you know how, please let me know.