Microsoft IE 5.0 Preview

A couple of days before the big beta drop, I got a walk-through of the IE 5.0 beta. Some parts of this are much more cooked than others; Microsoft was up-front about this fact, and I'll try to be clear about what is ready for prime time and what isn't.

Here's a summary of what seems like the big news:

XML+CSS support is starting to show up at the tag, but not at the document, level; but there is a strong commitment to get this right by release time.
There is also a strong commitment to do fully conformant XML per the 1.0 recommendation; there are places in the beta where this is still shaky, and Microsoft plans to find and fix them.
They've done a lot of work on the performance and robustness of the XML code, which was (understandably) a bit on the experimental side in the IE 4 timeframe.
They have a general mechanism for embedding XML in HTML.
They have a partially-XML-based facility called "scriptlets" which moves scripts out of the page.
They have added a kludgy but incredibly clever new attribute to the HTML <TABLE> element which should speed rendering up by a couple of orders of magnitude and bring progressive display back to the Web.
They have added "behaviors" to CSS; this allows a stylesheet directive to be implemented by a code module somewhere.
They intend to go on porting IE to other non-Windows environments, but have nothing to say yet on the schedule for that.
There are some other miscellaneous HTML extensions.
There is an intent to submit all these extensions to the W3C process. (As of the writing of this overview, no such submission was visible at the W3C).

The Browser as an Application Platform

The big strategic change is not all that XML-related. Microsoft sees that the world wants to deliver applications through the browser. They see it, and I quote, as being "as big as the Win32 platform." Which is pretty big.

To this end, they are building all sorts of developer-oriented hooks into IE5; the "scriptlet" stuff is one example, but there is a lot of work on more mundane things such as exposing drag-and-drop and replicating/persisting server state to support some degree of off-line work in multi-tier applications.

XML + CSS

If you do the right things, you can make IE5 display XML tags using CSS directives. At the moment, for this to work, the whole thing has to be in an HTML document; which is to say, they haven't got the code for the top-level text/xml and application/xml media types working. But they say they will, and since Netscape is charging off madly in the same direction, there's no obvious reason to disbelieve them. In any case, this is far from finished work, and it would be wise not to obsess about any details in the way this part is working at the moment.

General XML Support

The C++ processor in IE5 has been brought up (they think) to conformance with the XML 1.0 recommendation; conformance failures should be regarded as bugs. Furthermore, it will become an (optionally) validating processor. The Java parser, I gather, is a little behind, and there was no crisp statement as to whether and when that would be brought up to scratch. This may be a source of difficulties, since at the moment the Java version of MSXML will accept many things that a conformant parser will reject.

Microsoft emphasizes that they have put an immense amount of work into performance and robustness of the XML software; one of the driving factors is that they see a big role for XML in server-side applications, where everything is always stressed to the max and needs to run for days at a time. <UnkindComment>I guess this means that some future release of NT will actually be able to run for days at a time.</UnkindComment>

XML in HTML

IE5 embeds chunks of XML in HTML using the <XML> tag, which is an HTML, not an XML, tag. This is an obvious necessity, and we need to hold Microsoft's, Netscape's, and the W3C's feet to the fire to make sure it works the same across browsers.

Scriptlets

Scriptlets allow you to store your JavaScript code outside of the page; this will obviously increase the maintainability of Web sites and in principle seems a good thing. However, there is a downside; one of the nice things about JavaScript has been that unlike Java, since it's in the page, it starts running as soon as the page downloads. There's no free lunch, even on the Web.

From the XML point of view, the interesting thing about scriptlets is that they have a nice self-identifying little XML header, which seems like an obviously good idea. Yet another thing that Microsoft should submit to the W3C, sooner rather than later.

Here's a scriptlet header example, taken from one of the Microsoft IE5 pages, but with the gross XML errors removed, on the theory that they mean it when they say they're moving toward standards-conformance:

<scriptlet>
<implements type="automation">
<method name="mymethod"/>
<property name="myproperty"/>
</implements>
<implements type="behavior" default="true">
<event name="onMyEvent"/>
</implements>
<script>
...
</script>
</scriptlet>

Sprucing up Tables

Back in the old, old days, when you hit a Web site, the browser would start to render the page as it was loaded from the server. But starting in 1995, everyone started using tables to get cool formatting effects on their Web pages. While this worked well (I've done it myself, lots), tables have the problem that you can't really render them until you've read the whole thing. Thus, when you go to a site like C|Net's News.com, on a slow line, you'll wind up waiting for a long time before you see any of the page at all.

As a clever sidestep, IE5 defines an attribute you can put on a table saying the width is fixed; thus, once the first row of the table has been rendered, the browser can display as it reads. The visible effect of this is not subtle, and I think adding something like this is a no-brainer for anyone who wants to write HTML rendering code. Once again, submit soonest, please.

IE5 tables have another new attribute that causes borders to collapse and un-collapse; this is much easier to show off than to explain. It may or may not catch on.

CSS and Behaviors

There is a new CSS directive, so you can say:

.mask { behavior: url('mask.sct'); }

This would cause any element with the attribute CLASS="mask" to get the formatting behavior produced by the script found at the URL "mask.sct". Some of the effects you can produce with this technique are genuinely clever and useful; but this is potentially a major interoperability problem and I don't see the world charging to pick up on it.

Here's an example that combines the behavior with the "scriptlet" technique described above:

<head>
<TITLE>UL Extensible Tag</TITLE>
<STYLE>
.LIST{behavior:url(ul.sct);}
</STYLE>
</head>

<body>
<p>This is an example
  of an expanding/collapsing list
  using DHTML Behaviors

<ul class="LIST" style="cursor: hand;"
  title="Click to toggle the extag">
  This is an unordered list
  which has an xtag attached to the ul.
<li> Item 1
<li> Item 2
<li> Item 3
<li> Item 4
</ul>

</BODY>

ul.sct:

<scriptlet id="ul">
<implements id="Behavior" type="Behavior" default="true"/>

<script language="jscript">

attachEvent("onclick", event_onclick);

function event_onclick()
{
   var i;
   var style;

   if (event.srcElement != element)
      return;
      
   for (i = 0; i &lt; children.length; i++)
   {
       style = children[i].style;
       if (style.display == "none")
       {
           style.display = "";
       }
       else
       {
           style.display = "none";
       }
   } 
}

</script>
</scriptlet>

Other HTML Odds and Ends

There are any number of other little additions:

The XML-Data data typing mechanism has been wired into the IE5 code.
There is an <HTMLAREA> tag which (from the brief look at it I got) seems to do transclusion into frames, only without frames and without XLink. I'd have to say the jury is waaaaaay out on this one.
They've built in some geometric constraints on page layouts that designers will welcome; these remind somewhat of the old Motif "Form Widget". I am not erudite enough on CSS-2 to know to what extent this work duplicates or conforms to that.

IE5 seems to be a step in several useful directions. The XML support in particular seems to be moving in the right direction; it is everyone's responsibility to keep pressure, not just on Microsoft, but on all technology makers, to make sure this keeps happening.

As for all the other browser bells and whistles, their future depends in small part on the W3C process, and in large part to how the browser market share battle plays out.