Google Doctype

May 15th, 2008

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.

Tags: html, css, google, documentation, javascript, library

35 Comments on 'Google Doctype'

Starting with Mozilla

January 2nd, 2007

Today I start work at a new position with the Mozilla Corporation. This has been a long time coming (been interviewing with them for about 1.5 months now) and I'm terribly excited about where this is going to lead. I'm going to be working in Developer Relations; this involves interacting with everyone from Firefox core developers, to extension developers, to general web developers.

In general, the purpose of the position is to make the job of developers easier. This involves listening to what they need and figuring out how to get it done. In actuality, this will include writing tools (such as extensions or JavaScript libraries), writing documentation, and generally evangelizing the Mozilla platform.

There's a lot of things that excite me about the Mozilla Corporation itself, in addition to their platform.

• They're a very agile open source project. Virtually unencumbered by corporate tie-ins (unlike Red Hat or MySQL, for example), they get to work directly with the end users.
• They're still (comparatively) young. They only have about 70-80 employees, but about 80 million users. There's room in there for some explosive growth.
• They're the darling of the web development community. They have the opportunity to promote tons of standards, while forging the way for creating some new ones of their own.
• They have a ton of really cool technology that's just begging for some more attention. XULRunner is tons of fun - and has fantastic potential. The internal SQLite implementation is begging for some more attention. Much of the XPCOM functionality (Sockets, File I/O) is fantastically useful, just cloaked in confusion and terminology.
• They actively support web developers; they support popular tools such as the Web Developer Toolbar and Firebug, provide documentation on common web technologies (JavaScript, CSS, HTML) - and they're looking to increase and improve this. Any company whose marketing technique is to improve web development, and win over users, is awesome in my book.
• They're all about JavaScript. They created it, they're implementing it, they're building the next version. They're looking to build all sorts of tools to help JavaScript developers and to make JavaScript-intense sites faster. This is definitely something that I want to be a part of.
• They want to better facilitate, and support, development with JavaScript libraries. Looking for ways in which the browser (or the tools in the browser) can help to solve common problems. This is very cool and a great step forward. Having significant experience with JavaScript libraries, I'm going to be helping to push this process along.

I'm going to be sorting out exactly what I'll be up to in the upcoming weeks, but for now I'm content just reading through cool stuff like Mozilla's SQLite and DOMStorage implementations. A large part of my position is going to be reading through and trying cool stuff (like, say, XULRunner) and writing tutorials/blog posts about what I find. This, alone, is pretty cool - but being able to hack on, and promote, some of the most influential code in the industry really just seals the deal.

In all, I'm quite excited by this new position and am looking forward to my prospects in 2007.

Tags: javascript, programming, documentation, mozilla, browsers, job

21 Comments on 'Starting with Mozilla'