There’s been a lot of interest in yesterday’s release of Google Doctype. The primary focus of the release is on documentation (specifically “documenting the Open Web”) however there’s also two extra, hidden, additions: A Google-released JavaScript library and an Open Web test suite. Let’s break down the parts of this release.

Documentation

On the main Google Doctype site they provide a link to Browse Google Doctype which takes you to a JavaScript-laden site through which you can read the various articles that they provide. If, instead, you’d prefer to read something a little more static (and sanely linkable, bookmarkable) you can just go straight for the Google Doctype Wiki instead.

The documentation falls into 2 realms:

DOM and CSS

These are sort of API references to all the DOM and CSS properties. However, browsing through, they don’t seem to be terribly useful. At best, these references are programmatically generated (seeded with initial values). It’s not completely clear what its setting out to achieve but my guess is something like “if we put all the information in a wiki, maybe people will come and fill it out,” which seems a little awkward (especially since it’s already been done before).

The primary original content provided by this reference is related to the ‘browser compatibility’ section of each item. For example, examine the background-postition CSS property page. There’s a whole bunch of information being tested for – and a whole lot of ‘N’s in the columns – in fact there’s even a couple rows that contain nothing but ‘N’s. This says to me a couple things:

When every browser fails a test then you’re probably testing the wrong thing.

The fact that the actual return values aren’t shown makes this extra frustrating (every browser fails background-position: left – but what do they fail with? what are they returning, instead?).

There doesn’t seem to be any attempt to test for compliance. Overwhelmingly the test values appear to be “the value that goes in should be the value that comes out” – which is rarely the case. Granted, it’s much easier to write tests of this nature (just generate them programmatically) but the end result doesn’t really help anyone.

How-To Guides

The final portion of the documentation centers around a number of articles relating to JavaScript/DOM programming.

A number of these articles are quite good (such as the Web Security section and a couple of the other articles). However, the rest of the articles are quite… confusing. They appear to be documentation for methods of a Google JavaScript library, however they’re presented as Copy-and-Paste examples that developers can use. I think most developers will be quite disappointed when they find out that it’s not possible.

On the article pages the Google JavaScript library is never mentioned, nor linked to. You can eventually find it if you go to source, browse the SVN (to the right directory), and download the individual files of the library.

I think I can safely say that this is the first time that documentation for a JavaScript library has been released before the library itself.

Google JavaScript Library

The second portion of the Google Doctype release was the public unveiling of the (for lack of a better name) “Google JavaScript Library.” It, currently, only existing in Google SVN. There doesn’t appear to be an API reference, either – beyond the various articles provided in the above How-Tos.

Digging through the code there appears to be a huge depth of coverage for some… rather obscure JavaScript topics. If anything has been shown during the last couple years of JavaScript library development (in that the functionality that users have been asking for, and using) is that DOM traversing, DOM manipulation, Events, Ajax, and Animations are fundamental. While the Google JavaScript library does provide some DOM manipulation and Events they completely ignore all other aspects of JavaScript development. Instead they delve off into the land of object traversal, string manipulation, math helpers, and data structures.

If I had to pick a library that this one was closest to I’d have to say MochiKit. I wasn’t very surprised then to find out that the Google JavaScript library’s DOM helpers were heavily inspired by MochiKit.

No offense to MochiKit or the Google JavaScript library but if past history is any indicator – developers are not clamoring for another MochiKit.

Open Web Tests

The final portion of this release is related to the programmatically-generated Open Web API reference. This is a full suite of tests that cover HTML elements, JavaScript/DOM methods, and CSS properties.

Thankfully raw dumps of the results are provided for each browser so we can use this as an opportunity to see what tests are being performed (and how the results compare).

Taking a look at the JavaScript/DOM results for Firefox 3 we see a lot of ‘existence’ tests. The vast majority of the tests appear to be checking to see if particular methods, or properties, exist. Scroll through we see some puzzling error messages:

3. document/document-attachEvent-typeof-test.html:testTypeOf failed

"[DocumentAttacheventMethod] typeOf(document.attachEvent) != 'undefined'"

Expected not to be <undefined> (String)

Firefox 3 is failing this test because it doesn’t have Internet Explorer’s proprietary attachEvent method? If you continue through the results you’ll see similar indicators all throughout. If you were to open Internet Explorer’s results you would see a number of fails for Netscape-specific methods/properties.

Opening up the HTML Firefox 3 results we see a similar situation. In this case the HTML tests appear to focus on the availability of attribute expandos on DOM elements. For example, here’s one failing test from Firefox 3:

293. attributes/ilayer-above-reflection-test.html:testReflection failed

"[IlayerAboveAttribute] ilayer.above reflects <ilayer above="foo">"

Expected <foo> (String) but was <undefined>

The ilayer element was a Netscape-specific HTML extension. Testing for its DOM compliance (and, by extension, its existence) seems quite futile.

If I had to guess as to how these tests were generated I’d say “open up a browser, spider every DOM property (or HTML attribute), and turn those into existence tests.”

This raises an important point: This suite is not built for any sort of standards compliance – at all – it’s simply designed to check for compatibility between browsers. Looking at this suite as a compatibility suite we can start to see some use – but it’s still terribly limited (only checking for existence is hardly a good-enough indicator of a browser’s proper support of a property or method).

If there’s one over-arching theme to the Google Doctype release it’s been “whatever we can generate automatically, or release with the least amount of fuss, let’s do that, no matter how simple it may be.” I’m definitely looking forward to when a full release comes along, but this doesn’t appear to be it.