Avalon, WPF and XAML Explained in Plain English

If you were reading Windows blogs in the mid-2000s you kept bumping into a word: Avalon. It sounded like a product, but you could not buy it, and the samples people posted were written in a strange new XML dialect. This retrospective is the plain-English explainer we wish had been pinned to every one of those posts: what Avalon actually was, what XAML is and why it mattered, the handful of big ideas it introduced, and where the whole family sits today. No prior .NET knowledge required.

What "Avalon" actually was

Avalon was a codename. During development, Microsoft gives components internal names so teams can talk about work that has not been finalised or branded yet. Avalon was the codename for the graphics and user-interface framework that eventually shipped under the product name Windows Presentation Foundation, almost always abbreviated to WPF.

WPF arrived as part of the .NET Framework 3.0 wave and was closely associated with Windows Vista, the release that made the new framework broadly available on the desktop. (WPF was also made available for the preceding Windows version at the time, so it was never strictly Vista-only.) So when an old post says "Avalon", read "WPF" — they are the same technology at different points in its life. The samples in those early posts came from pre-release community previews, which is why some of their details, especially the XML namespaces, differ from what shipped. We will come back to that.

XAML: declaring a UI as markup

The other half of the story is XAML — eXtensible Application Markup Language. XAML is an XML-based language for describing objects and their properties. In WPF you use it to declare a user interface: this window contains that panel, which contains these buttons, with these colours and this text. Because it is just XML, it is human-readable, diff-friendly, and easy for design tools to generate and consume.

The key idea is separation of concerns. Traditionally, building a Windows UI meant writing procedural code that created each control and wired it together line by line. XAML lets you instead declare what the interface looks like, while the behaviour — what happens when a button is clicked, where the data comes from — lives in a separate file. In classic WPF that companion file is called the code-behind; in the pattern most teams adopted later, the logic lives in a view-model that the XAML binds to. Either way, the visual layer and the logic layer are loosely coupled, which is what lets a designer and a developer work on the same screen without stepping on each other.

A mental model, not magic

It helps to remember that XAML is not a separate runtime. Every XAML element corresponds to an object that could equally have been created in code; the markup is a convenient, declarative way to construct and configure those objects. Anything you can express in XAML you can express in code, and vice versa. XAML just makes the common case — laying out a tree of UI objects — far more readable.

The core ideas WPF introduced

WPF was not simply a new set of buttons. It rethought how Windows drew and composed user interfaces. A few ideas did most of the heavy lifting.

Vector rendering and resolution independence

Older Windows UI toolkits were fundamentally pixel-based. WPF composed its output through a modern graphics pipeline and treated the UI as vector content measured in device-independent units. In practice that meant interfaces could scale more gracefully across different screen resolutions and DPI settings, and effects like smooth scaling, rotation and transparency became first-class rather than hacks. This "resolution independence" was one of the headline pitches for the framework.

Data binding

Data binding is arguably the feature that changed how people wrote applications. Instead of manually copying values from your data into controls and back again, you declare a link — "this text box shows that property" — and the framework keeps the two in sync. Rich binding, combined with the view-model approach, is what made the well-known separation pattern practical on WPF and is a big reason the framework stayed popular for line-of-business software.

Styles and control templates

WPF separated a control's behaviour from its appearance. A button knows how to be a button — it can be focused, clicked, and shows a pressed state — but what it looks like is defined by a template you can replace wholesale. Styles let you set properties consistently across many controls; control templates let you redefine a control's entire visual tree without losing its behaviour. This is why WPF applications could be reskinned so dramatically while still behaving like ordinary Windows controls.

Layout panels

Rather than positioning every element with fixed coordinates, WPF arranges children through layout panels that follow rules — stack things in a row or column, arrange them in a grid of proportional rows and columns, wrap them, or dock them to edges. The layout system measures and arranges content dynamically, so interfaces adapt to their content and their window size instead of breaking when text gets longer or the window is resized.

Why it was a big step for Windows UI

Put those ideas together and you get the reason Avalon generated so much excitement. For the first time, a mainstream Windows UI framework let you describe an interface declaratively, restyle it completely, bind it cleanly to data, and render it as resolution-independent vector graphics — all in one coherent stack. It moved a lot of tedious, error-prone UI plumbing out of hand-written code and into a declarative, tool-friendly format. That is a large part of why XAML did not stay confined to WPF.

A look back at the original Q&A

The original zhanbos post was a two-item developer Q&A about how the early XAML parser handled keys in a resources section. The specifics are still instructive, so here they are, preserved with light modern framing. Bear in mind these snippets used the pre-release Avalon namespaces of the time; the versions that shipped with WPF use different namespace URIs, so treat the exact URLs below as historical rather than current. If you want to run something like this on WPF as it shipped, swap the default namespace to http://schemas.microsoft.com/winfx/2006/xaml/presentation and the x: namespace to http://schemas.microsoft.com/winfx/2006/xaml.

Q101 — what can be an x:Key value in a Resources section?

A resource dictionary needs a key for each entry. The original answer noted that a key can be provided as a plain string or via certain markup extensions, and it showed that trying to key an entry with the null markup extension fails to parse:

<Grid xmlns="http://schemas.microsoft.com/winfx/avalon/2005"
      xmlns:x="http://schemas.microsoft.com/winfx/xaml/2005">
  <Grid.Resources>
    <SolidColorBrush Color="LightBlue" x:Key="{x:Null}"/>
  </Grid.Resources>
</Grid>

The takeaway that still holds: a resource key has to be a usable dictionary key, so a value that resolves to "no key" is rejected by the parser.

Q102 — treating a brace expression as a literal string

In XAML, a value in curly braces is normally interpreted as a markup extension (a small inline instruction to the parser, such as a reference to a resource). But sometimes you genuinely want a string that starts with a brace. XAML provides an escape sequence for exactly this: a leading empty pair of braces, {}, tells the parser to treat everything after it as a literal string, with leading and trailing spaces trimmed. The {} must be the very first characters of the value:

<Grid xmlns="http://schemas.microsoft.com/winfx/avalon/2005"
      xmlns:x="http://schemas.microsoft.com/winfx/xaml/2005">
  <Grid.Resources>
    <SolidColorBrush Color="LightBlue" x:Key="{}{x:Null}"/>
  </Grid.Resources>
  <Button Content="Sample 102" Background="{StaticResource {}{x:Null}}"/>
</Grid>

Here {}{x:Null} is not the null extension at all — the leading {} escapes it, so the key is the literal seven-character string {x:Null}, and the button then looks that same literal string up as a static resource. The empty-brace escape is a small but genuinely durable piece of XAML syntax, and it is the kind of detail these early posts were good at capturing.

Where Avalon, WPF and XAML stand today

The happy ending is that none of this became a dead end. WPF is still supported, runs on modern .NET, and Microsoft released its source code as open source, so it continues to receive fixes and community contributions. Plenty of Windows desktop software still runs on it.

XAML outlived its original host. The same declarative approach — a tree of UI objects in markup, bound to data, styled by templates — was carried into later Microsoft UI stacks. Closely related XAML dialects are used by WinUI for modern Windows apps and by .NET MAUI for cross-platform apps that also target other operating systems. The dialects are not identical, so markup does not always move between them unchanged, but the concepts transfer almost completely. Learn XAML once and most of what you know still applies.

That is the real legacy of Avalon. The codename faded, but the ideas it introduced — declarative UI, strong data binding, retemplatable controls, resolution-independent rendering — became the default way a great deal of Windows software is built, and they continue to shape Microsoft's UI frameworks today.