Avalon/XAML First Look

April 14, 2005 10AM PST

Familar with Microsoft’s new XAML? I wasn’t, until recently.

During the first day of the recent FITC conference, Karsten Januszewski (a Microsoft tech evangelist) gave a talk on the forthcoming Avalon. The relevance to the audience was that advanced media and UI features made possible by Avalon will eventually require creators, many of whom Microsoft hoped to reach here. Developers, developers, developers…

My familiarity with the technology up to that point was limited; I had basically thought of it as Quartz (OS X’s advanced screen rendering system) for Windows. I’m still not convinced the technology itself is much more than that, actually. Avalon composites many different types of media — text, images, video, and vector shapes. I’m somewhat unclear how detailed the native 3D rendering support is. There was a demo of multiple video sources being mapped to rotating spheres, so there’s at least a few basic shapes and textures. My confusion is partially the result of the ‘special guests’ pulled on stage — a software company that created a 3D -> Flash convertor, which it had adapted for Avalon. Given Flash’s lack of native 3D object support, hence the need for this tool, I’m left wondering what that means for Avalon’s 3D support.

Quartz vs. Avalon

Without getting too carried away with the specifics though, what seems to be the main difference between Quartz and Avalon is the openness and flexibility. Avalon goes hand-in-hand with XAML, Microsoft’s upcoming eXtensible Application Markup Language, which is XML in name if not in spirit. The upshot of which is that controlling the display is as simple as editing a human-readable text file. (Although the Microsoft rep was quick to point out that by no means will this be the only way to do it as current and upcoming design tools adapt to generate XAML automatically.)

That everything in Avalon runs on text files is actually pretty slick. I’ll give Microsoft substantial credit for that, it’s going to ensure a lot of adoption. Put anything in text and it’s pretty much an open format to some degree. But there are two things that detract from what otherwise might have been full points.

The Code

The code itself looks like (well-formed) tag soup from 1997. Whereas the web has seen a shift from presentational markup (in the form of tables, embedded attributes like bgcolor, and the dreaded font tag) to structural markup with a separated presentation layer (CSS), XAML is purely a presentational language. I couldn’t see evidence of attention toward semantics, and all the presentational attributes are embedded right in the markup. Januszewski referenced ‘a CSS-like syntax’, but there’s nothing CSS-like about it. It’s ugly presentational HTML all over again. A sample snippet:

   <?xml version="1.0"?>
       Width="500" Height="500" Background="White">
         <LinearGradientBrush def:Name="RedGrad" 
           StartPoint="0,0" EndPoint="1,1">
                  <GradientStop Color="#FFFFFF" 
                   Offset="0" />
                  <GradientStop Color="#FF0000" 
                   Offset="0.5" />
                  <GradientStop Color="#000000" 
                   Offset="1" />
              RectangleLeft="0" RectangleTop="0"
              RectangleWidth="500" RectangleHeight="5000"
          <SimpleText Margin="5" FontSize="14">
            An h3, this is not.

It appears to me this is single-purpose code, rather than the layered approached of HTML/CSS/DOM. Can it degrade? How much thinking has Microsoft done about accessibility? What will this code do on a PocketPC or PalmOS cell phone?

Maybe this code makes sense from a desktop computer application development context, but it does not work in today’s web development context. The separation of structure and presentation is now a no-brainer, so I’m left wondering why it has been completely ignored here. It’s like the past few years of undoing the markup sins of the late 90’s haven’t happened. Or, they haven’t happened at Microsoft. (Other divisions [MSN] seem to get it, to be fair.)

XAML on the Web

Which brings us to the second problem — XAML on the web. Yes, XAML is designed to run inside a browser. It appears a special XAML plug-in or player or something equivalent is necessary, as it was demonstrated running inside of a stock version of IE6 under Windows XP. But Microsoft ‘loves the browser’ according to Januszewski, and wants it to be painless to select a link on a web page and open a XAML app as a result. Longhorn will presumably feature tight integration of the two.

The past couple of years of IE security problems have raised a lot of awareness about browser lock-in, and the problems that tying your application into a specific browser/operating system can later cause. Like ActiveX, in-browser XAML/Avalon appears to be a method of continuing that trend. Something tells me we won’t be seeing an Avalon player for Linux any time soon.

I’d be a whole lot more comfortable with XAML if it were strictly meant as a Windows OS rendering language. Proprietary markup on a proprietary platform is nothing to get worked up over. But the obvious web cross-over leads me to hope we’re not going to see a whole new generation of browser/OS-specific web apps. I wonder if Microsoft might be hoping for something different.

If anyone who understands XAML better than I would like to come in and tell me how backwards I have it, I’d love to hear from you, comments are open. I’d rather my first look is all wrong and my worries unfounded (even though I’d like to think I understood the presentation properly).