A Tale of Two Browsers ...or Kids, Don't Try This at Home

December 18, 1998

Glenn Davis

A Tale of Two Browsers
...or Kids, Don't Try This at Home

Glenn is the CTO of Project Cool, Inc., and co-founder of the Web Standards Project, a grass roots effort to persuade browser vendors that standards support is in everyone's best interest. In this, his first article for XML.com, he takes a look at XML support in early versions of the leading browsers.

Recently it was my pleasure/frustration to take a look at the XML and DOM support offered by the developer previews of the two main Web browsers. I'm interested in XML from a designer's perspective. I'm excited about XML and the future it promises so it was time for me to start tinkering around with it in the browsers that claim to support it. I tinker with new technologies when they become available and I've been champing at the bit to start tinkering with XML in a Web browser.

I come from an old school of learning such that I feel the best way to learn how something works is to tear it apart and then put it back together again, hopefully better than before. This is the approach I used with Netscape's Gecko preview and Microsoft's Internet Explorer 5 beta 2. Naturally, the first thing I needed was some source code. Mozilla.org provided this in the form of a demo bookstore page. The original files for this can be found at: http://www.mozilla.org/newlayout/demo/xml/xmlbooks.zip

Playing with an organization's demo files can be quite enlightening. This demo produced a page that could be the search results from Amazon.com complete with book cover graphics and some stylish CSS layout. It also includes JavaScript code that allows you to sort the results on the display based on one of three fields.

Viewing the source code for the books.xml file revealed that the parser wasn't doing the job it should. It was allowing illegal constructs such as <BookSet></bookset> and not requiring attributes to be in quotes. I have since learned that this is a result of the fact that James Clark's widely-praised Expat XML processor has not been wired into Mozilla yet; so we should see this problem resolved in future builds.

What this meant was that I had to do a bit of editing before books.xml could be viewed in IE5b2. I've got to commend Microsoft at this point. Their XML parser is strict and doesn't allow for sloppy coding. I like that in my parsers. Gecko currently allows very sloppy coding. I'm sure, though, that this will change with their incorporation of the expat XML parser into the codebase.

Another thing I removed from the file that didn't affect Gecko was a <!DOCTYPE BookSet> declaration; IE takes its being there as a signal to validate (impossible in this case since there's no DTD) - while this is not very helpful behavior, it's not actually illegal. Removing it had no effect on Gecko's use of the page.

After repairing the code so that it was well-formed XML I was able to load it into IE5b2 ... mostly. I say mostly because now it becomes evident that there is a problem with the JavaScript. I pull the code into my editor and find a Gecko bug workaround documented in the code. After repairing the code I load it again and voila, everything appears to work ... mostly.

CSS rears its head in IE as a problem this time. The ever-haunting float/clear properties in CSS that IE has never properly supported mangle the display. I can live with that if the rest of the page works as it should. I click the button that toggles the display styles and it works. Both IE and Gecko can switch xml stylesheets in midstream using a documented JavaScript call to the DOM. But the real test comes when I press one of the sort buttons. Gecko sorts the fields on the fly and the page quickly rearranges right in front of my eyes. I click the button in IE5b2. Nothing. I click again. Nothing.

Perhaps what I find most annoying in the nothing is the sheer nothingness of it. No JavaScript error message, no crashing of the browser, just nothing.

I'll admit that I'm not an expert on the DOM. I'm also not an expert JavaScript coder, but everything I see in the JavaScipt looks like it's making perfectly valid calls to the DOM to do nothing more complicated that removing and inserting child nodes. IE isn't reporting errors so it must think it's doing it correctly. Perhaps it's nothing more than a display bug. Maybe I shouldn't worry. Maybe it will be fixed for the final release. Maybe...

Maybe what worries me is that when I go to Microsoft's site to view their DOM examples I find them wrapped up with proprietary Microsoft extensions like outerHTML and using Microsoft's data binding in conjunction with the DOM. Microsoft also isn't committing to 100% support of the standards.

Maybe what worries me about full and correct support for the DOM standard from Microsoft can be summarized in this quote by Chris Lovett of Microsoft from a November 16th posting in the microsoft.public.xml forum:

Despite the fact that the W3C DOM standard specified that this would be illegal, we feel this is an important scenario to enable so we have two solutions in IE5B2

Scary, isn't it?

But hey, maybe I'm worrying for nothing. Surely someone will point out the error of my coding and we can publish an addendum to this article. After all, I'm no authority and I am playing with developer previews. I'd certainly relish being told I'm wrong in this case and with developer previews anything is possible. Both browsers have a long way to go before final release.

When push comes to shove what I really want is a web in which we write once and view many. That's the promise of standards support and XML. Shouldn't that be what everyone is working toward?