Loose XAML, XBAP, Silverlight

Can XAML be used instead of HTML?
In recent months I have become somewhat of a XAML junkie. But also working with web applications, I like many would love to be able to use XAML instead of HTML. Is it possible? Not yet....

HTML History
I have been on the Internet long before the web existed. My first Internet access was around 1988 and from about 1991 on I had Internet from my home computer. Things were very different in the pre web and early web days. HTML 3.x was fairly basic. But for what it was, it was quite good. Then came HTML 4. Unfortunately HTML 4 has become quite a mess both of history and in my personal opinion committee. HTML 4 tried to do too much at once and while it did somethings well it just created big ugly messes in other places.

Enter XAML
Some have described XAML as what HTML would be if it could be. But to think of XAML in HTML terms you would have to first assume all backwards compatibility is off the table, and even then it might be something like HTML 9.0 in terms of capabilities. XAML is also in my opinion much better refined and does not have the ugly messes that HTML 4 does. Because of these factors many people have proposed to build websites in XAML instead of HTML. There are some obvious drawbacks as well, including the obvious one that it is Windows only (for now).

HTML Successor Requirements
For anything to supersede HTML it must do the following:

Unique URL's - Each and every page has it's own unique URL
Searchable - Be indexable and searchable by current search engines (i.e. text based)
Hyperlinks - Allow hyper linking to other documents
External resources - Allow references to resources by URL (images, video, etc)
Data posting - Allow user input and posting of data back to a server
Self sufficient pages - Each page must be self sufficient and not require other pages to display itself unless they are included resources. That is I can access Page1 with or without Page2 existing on the server, even if Page1 links to Page2 via hyperlink.
Script language - Some sort of scripting must be supported to assist with page display, user input, etc.
Cross platform - Must be supported on Windows, Macintosh, Unix, Linux, and be portable to others.
Can XAML do this?
Unfortunately no. XAML has several options:

Loose XAML - Raw XAML files containing only markup
XBAP applications - XAML applications that run in the browser and to the end user appear to have a page based interface
WPF/E - Cross platform subset of XAML
XPS - XAML Paper Specification. XPS is sort of a XAML PDF and not suitable at all for replacing HTML.
If we were able to combine features of the first three, XAML could meet the requirements. Unfortunately there seems almost to be a weird conspiracy that no one of them could do it all. Lets me examine them one by one.

Loose XAML
Loose XAML is the most obvious candidate for replacing HTML. Anyone who has played with XAML can see the obvious benefits and many people have tried to do test websites solely in loose XAML. So where does it fail?

Data posting - Loose XAML has no provision for the FORM element as in HTML. There is no way to accept a user filled in form and send the data back to the server as is commonly used in user registration, feedback pages, order forms, etc. Two way data binding could be used to do perform some of this functionality, but two way data binding requires a code file which is no available in loose XAML.
Script language - While XAML can be hosted in an HTML IFrame, the host's Javascript has no access to the XAML document or its DOM. In addition XAML can contain C# code directly in the XAML in CDATA sections. However this is supported by compiling the XAML and is only available when included in a .NET application. That is, code in CDATA sections is not supported in loose XAML. This is a major disappointment because .NET 3.0 is already required for display of loose XAML and .NET includes a C# compiler. C# in XAML is exceptionally useful and suited for even simple things as animations, basic calucations, posting to a server (item 1), and so forth. Much can be accomplished with XAML triggers, but even designers often resort to code.
Cross platform - XAML fails here, for now. But for many users on Intranets, extranets, and even the Internet Windows only is acceptable. Many sites are IE only and have been for years. That being said look at what Microsoft as done with the Office XML formats. If XAML were submitted to ECMA it would be possible for Mozilla, Mono and others to support XAML on other platforms. Even without ECMA, I expect that we will see third parties start to build XAML support.
In the end, #2 is the real show stopper. I really hope in the future versions of XAML this will be addressed. Full code with downloadable assemblies etc is not needed, although a sandbox model with cached logic assemblies would be nice. Even if code was just available for scripting purposes on the XAML page itself it would be very useful.

XBAP Applications
XBAP applications are collections of XAML pages compiled together with code and deployed into the browser. They do support forward and backward page navigation, thus to the end user it acts very much like a web site does.

Where XBAP fails:

Unique URL's - Each XBAP has its own URL. Moving between pages in the XBAP application does not change the URL in the browser and the user can only bookmark the entry point to the application. Because of security, the application cannot dynamically change the URL in the browser. Deploying one XBAP per page solves this problem, but is not practical because each XBAP must be compiled and when deployed consists of a minimum of three files.
Searchable - The XAML in XBAP's is compiled into executable code in binary format (BAML) and is not accessible to search engines.
Self sufficient pages - To access any page in an XBAP application, the whole application must be downloaded. Imagine browsing to the Microsoft website and needing to download the whole website first.
Cross platform - Requires .NET 3.0 and Vista, XP, or 2003.
WPF/E
WPF/E is a cross platform version that is a subset of XAML. One might think of WPF/E as a XAML competitor to Flash. WPF/E is cross platform, and it exposes its DOM to Javascript. It even in future builds will support a mini CLR engine for C# execution. So WPF/E appears really promising right? Well to compete against flash and beef up existing HTML it sure does. But to replace HTML, it does not and here is why:

Unique URL's - WPF/E must be hosted in an HTML page. So it sneaks by on this requirement, but HTML is still in the picture here.
Data posting - Again through interaction with HTML. Although potentially something might be done using Javascript to go directly from WPF/E to the server.
Self sufficient pages - Same problem as Unique URL's, all WPF/E content is contained in an HTML host.
So WPF/E squeaks by right? Sure it has to be hosted in an HTML container but that could could be minimized and fairly generic. But there are two additional areas that WPF/E fails in and one is a show stopper:

WPF/E is not released - It is in CTP/Beta. It is however scheduled for release mid 2007.
Lack of user input controls - WPF/E's subset of XAML does not include user input controls. WPF/E has support for animitions, vector graphics, images, video, etc. If you want to have say a listbox or an textbox, you have to use HTML. But if you need a text box in your WPF/E part, you need to construct it from primitives and code.
What I would like to see
In a way it is frustrating to be so close yet so far. It really is just that last inch that is missing. XBAP is a great implementation for applications, but it was not designed to replace pages and thus will continue to be a poor candidate for such. It is a tough call between WPF/E and loose XAML for pages.  WPF/E is cross platform, but loose XAML is fully featured.

I would like to see loose XAML with:

Ability to post data to a server. Maybe something similar to XForms, or even basic abilities similar to HTTP post in HTML where fields are bound to output and posted to an HTTP URL. It would of course be even better if such could be bound also to a webservice method input. XAML can already bind to webservice output.
Ability to have C# code in CDATA sections for purpose of scripting tasks in the UI and augmenting where XAML triggers and animations cannot suffice.
Simple calculations and expressions inline XAML - Currently you can use binding for example to bind the height of an image to a slider controls value. But what if you need the height to be the value times 2? In some cases you can use a transform to make this effect such as this one, but in many cases transforms cannot be used. Simple calculations and expressions would go a long way to both simplifying some existing XAML, but also enabling new features that currently require code.
With these basic additions, XAML would start to become prevalent in Windows environments as a replacement for HTML. Going one step further though it would be nice to have the ability to use code behind instead of only in CDATA sections and ability to reference other assemblies. The code would execute in the same sandbox model as XBAP and assemblies could be cached. The difference is that whole applications would not need to be compiled on the server, the XAML would remain in text format, and pages would be self sufficient. Finally, pages would be downloaded one at a time on demand instead of as part of a larger application.

Can XAML be hacked now to work?
We've done it for years with HTML, but a key factor there was scripting support. There are a variety of approaches such as mixing HTML + XAML, or XBAP + XAML, as well as other variations. But all have their limitations and none properly meet all of the goals outlined.