Rob Relyea


April 2004 - Posts

  • Nigel's "Standard's Based Look at Xaml's Features" and my quick "CSS and Avalon's Styling compared"

    Filed under: ,

    Nigel McFarlane wrote a DevX piece “A Standards Based Look at XAML's Features”.

    I'd like to make a few informational points for readers of that article and then have a place where people can add comments/questions.  The whole topic may warrant a long post, but I don't have time right now.

    1. HTML + CSS modeled most elements as setting a few CSS attributes by default

    Most text formatting tags could be thought of providing a different set of default values for those css-attributes.


    <bold>this is also bold</bold>

    Is equivalent to:

    <span style=”font-weight:bold”>this is bold</span>

    Avalon's approach (which people can choose to use declaratively in XAML or via their favorite programming language) is very similar.


    <Bold>this is also bold</Bold>

    Is equivalent to:

    <Inline FontWeight=“bold“>this is bold</Inline>

    2. HTML + CSS allow you to define stylesheets to avoid having to set all values directly on a tag

    HTML + CSS allow you to do roughly this:
    button { color : green }
        <button>my text that will be green</button>

    Avalon allows you to similar things:
                 <Button Foreground=”green” />
        <Button>This text will be green also</Button>

    3. HTML + CSS allow you to use inheritance of values in the tree hierarchy.

    In HTML, one could set many CSS properties in a ancestor element, and elements further down the tree would get that value.  Avalon supports component authors defining some properties as inheritable and support the same thing.


    4. Avalon's Styles & Property System is different than CSS

    CSS has its own language syntax.
    Avalon's Styling system is XML based.

    Avalon's Styling system isn't feature for feature equivalent to CSS.
    In some cases, it is innovating in new spaces.  In a few cases, it can't match CSS for some scenarios.

    We're listening to customers who are building real apps & solutions to see how we need to evolve our styling strategy before we ship.


    Feel free to comment on what I wrote in this post or on any questions/comments you have from Nigel's article.

  • Avalon: solitaire & using markup and custom elements

    Filed under: ,

    I was happy to read Chris Sells' MSDN article "Another Step Down the Longhorn Road".  Chris is building solitaire using Avalon. (This article was step 2 of 3).

    This article goes into 2 of the 5 element families: Panels and Controls.  It also covers the details (and current gotchas) of how to build an application with a custom component.

    One problem he points out:

    "The problem is that the XAML gets the type information from a compiled assembly, so you'll have to add a reference to the custom control project in the containing project."

    We have been wanting to fix this issue for a long time, we hope to have this fixed soon (in time for what I expect will be our 3rd public release of LH)  We'll make it possible to put PileOfCards.xaml & PileOfCards.xaml.cs into the applications project.

    I'm looking forward to the final installment.

  • Walking the thin line with XAML

    Filed under: , ,

    Chris positions XAML vs general serialization technologies and approaches.

    XAML was designed to be a compromise markup format, that balanced the toolability and readability aspects of a markup. You can think of HTML as a markup that was squarely designed to be readable, but not very toolable. SOAP on the other hand is very toolable, but almost impossible to read. In the design of XAML we constantly walk the line between the two. XAML has support for inline code, customer parser extensions, and multiple representations of the same structure.

    This piece hightlights some of the conflicting goals that influence the decisions we make with XAML.  It'll be a while before our current evolved design (what I'm calling xaml2004) makes it out to the world in a build, but I think people will be happy with the continued focus we have on moving XAML in a generic technology direction.

    Readability and writability, I believe, is critical to the success of XAML.  Many folks will be using a visual designer, so they won't appreciate it, but I think many people will like to read/write it directly (at least occassionally).

    Perhaps we are focusing on that too much now since we are all still using an XML editor to create XAML pages.  Once designers get built and have more use, we'll see if we'll change some of our decisions.  For now, I think it is important to walk that thin line...

  • The .Net Show - filming about avalon

    Filed under: , ,

    Pablo Fernicola (Group Program Manager), David Ornstein (Lead Program Manager), Nathan Dunlap (Rockin' Designer), and I spent time yesterday with Robert Hess and the .Net Show crew.

    The .Net Show blog posted about the filming (with links to photos) etc...

    Interesting format.  Nathan showed the Login Screen demo a new demo showing using Paths for States and having those states in a ListBox.  I showed some basic xaml concepts, talked about markup and programming model and showed a bit of my Viewer application.

    Once it goes live, you'll have to post feedback...I'm new to the whole video thing.

    Thanks to Robert and crew for asking me to appear!

  • Today you can't compile xaml on the fly.

    Filed under: , ,

    A posting in the channel 9 wiki on getting stated with xaml led me to clarify how xaml pages load in IE and why you sometimes need to compile them.

    XAML Loading in IE

    Currently, if you have a xaml page and it doesn't have any code embedded (or in a code behind file) you can just double click it and it will load in IE.

    What happens when you do that.

    1) Windows Explorer realizes that .xaml files should be loaded in IE.
    2) IE loads and realizes for that mime type PresentationHost.exe should be loaded into IE as the DocObject that knows how to render xaml content.
    3) PresentationHost.exe passes the .xaml file to the xaml parser, it creates the tree of objects and it renders.

    This is the same technology that allows word documents to be loaded inside of IE.

    Sometimes Compilation is Necessary

    If you want to start adding code to a xaml file, we currently require a compile step.  There are a few ways to do this:
    1) run XamlC.exe (installed with the LHSDK)
    >xamlc foo.xaml

    2) create a Longhorn project in VS, it will create the msbuild project file for you (.csproj, .vbproj) and a few .xaml files.  You can then compile this in VS or via the command line.
    Command Line: 1) cd to the directory of the project. 2) >msbuild

    3) you could create a msbuild project file by hand and then use command line as stated in #2

    Should We Autocompile When Running in IE

    On developer machines, perhaps we should.  I'm hesitant to do it on end user machines.

    HTML + script + browser security hole is sometimes a dangerous weapon.  We need to be careful about making .xaml files themselves have autocompile behavior for this reason.

    That said, I'm not happy with the barrier to entry that we currently have...we're continuing to think about it...


    Update:  Jason Nadal has a post/comments that have some additional info:


  • Markup-oriented developers aren't at home with Strongly Typed languages

    Filed under: , ,

    A user asked:

    Is there a generic way of assigning a property a value, somewhat like you could do through XAML?


    For example, if I specify the following code:

    <Glyphs Fill=”#000000”>


    How would I create a Fill property with value “#000000” through code? Note that I don’t want to create a new Glyphs object, but simply a Fill property.



    The way that XAML works for that element is the following:


    1)       Creates a Glyphs object.

    2)       Determines the type of Fill is Brush.

    3)       Looks at the Brush type for the appropriate TypeConverter.

    4)       Uses the BrushConverter to convert to a Brush from the “#000000“ string.


    BAML details

    When you have compiled Xaml, we build a Baml file.  When storing the attribute value in the Baml file, we check to see if the Brush type support IBamlSerialize.  If so, it can store a more compact representation of the value than a string.  At runtime, while loading the Baml, we use IBamlSerialize to convert the persisted version into an object.  Some more XAML/BAML details are in my January post.


    So how do you do this in Code:

    Generally, you don’t want to use a TypeConverter if you are writing code for this.


    Here is the code to use the TypeConverter, if you wanted to do that:


    At first I had the totally generic code in here (see my first comment for it...)

    Should have shown:

    g1.Fill = BrushConverter.ConvertFromString(“Black“);  //code isn't bad, but perf isn't optimal



    This would be most efficient:

    Glyphs g1 = new Glyphs();

    g1.Fill = Brushes.Black;  //Black is a static field on Brushes that is a SolidColorBrush with a Color of black, I believe…



    Since you said you didn’t want to create a Glyphs object, you could do this:

    <Glyphs ID=”g1”>

    And in code (perhaps the Loaded event on the root element), you could then

    g1.Fill = Brushes.Black; 


    Is there a Generic way of doing this?

    No.  Sorry, not yet.

    I think this will be a common theme that we hear from “markup-oriented” developers.  We could add a method to support the ability to use a string more easily in code.  However, it would be nicer if CLR languages could provide Tool or Tool & Language support for people who think in strings, but don’t want to pay the cost for it at runtime.


    HTML is:

    • easier to figure out how to set values in code, since you just use a string.
    • more troublesome to figure out if you have the right value...since bad values are often ignored.
    • when it does error, it waits until runtime (often on your users machine.)

    What is on tap with WinFX?

    I hope we can make development with WinFX friendlier to markup-oriented developers - like me.


    Is our message:

         “strong typing is good for you“


         “ok, we can make it easy and give you the benefits of strong typing“