Dave Shea posted some thoughts on XAML yesterday. XAML is Microsoft’s proprietary user interface language. It seems to resemble SVG very much and I think it is very unfortunate Microsoft didn’t try to extend on existing languages. On the other hand, XAML can probably do much more and there is also some talk about 3D. That is looks like SVG also has another consequence. The markup that is used looks very much like the HTML you generated back in 1995 and some still generate today. A while ago I stumbled across some weblog with the fascinating title Designers Love .NET. The weblog shows little examples of the possibilities XAML (or Avalon) has.
One of the examples posted there by Nate Dunlap is a “Flippin CD Button!” Here is a very small snippet of the XAML code used:
<ParallelTimeline BeginTime="*null" ID="MouseEnterAnimation" Duration="Forever"> <SetterTimeline FillBehavior="HoldEnd" Duration="0:0:0.5" BeginTime="00:00:00" TargetID="_MainViewport3D" Path="(Viewport3D.Models).(Model3D.Transform).(Transform3DCollection.Children)[1].(RotateTransform3D.Rotation).Angle" > <DoubleAnimation From="0" To="-70" FillBehavior="HoldEnd" Duration="0:0:0.5" DecelerationRatio="1" /> </SetterTimeline> <SetterTimeline FillBehavior="HoldEnd" Duration="0:0:0.5" BeginTime="00:00:00" TargetID="_MainViewport3D" Path="(Viewport3D.Models).(Model3DGroup.Children).[7].(Model3D.Transform).(Transform3DCollection.Children)[2].(RotateTransform3D.Rotation).Angle" > <DoubleAnimation From="0" To="-100" FillBehavior="HoldEnd" Duration="0:0:0.5" DecelerationRatio="1" /> </SetterTimeline> </ParallelTimeline>
Now of course I am not some XAML expert (I never played with it actually), but I can tell you that this is some ugly code. It looks like they reinvented XPath, define behavior and looks inline and do a lot more things that you rather want to separate. (By the way, if you want to download the code yourself and get a HTTP 404 back, that is because the link is relative from the front page, not from the archived page. Indeed, it should have been a relative absolute or so, but it isn’t.)
From a marketing point of view Microsoft is probably quite brilliant or at least smart. Using this ‘private language’ they will keep binding people to Windows and Internet Explorer. Especially if they make major contracts with Ebay, Amazon and the like for online web applications based on XAML.
The thought that XAML was some reinvention of XUL that existed 1,5 years ago can probably be forgotten. The thought that Microsoft might pollute the web with it’s unsemantic XML based language (who ever said XML was semantic?) seems to be much more realistic. (Not that this thought is contradicting to the previous, but that is beside the point.)
So... how exactly are Microsoft going to get around the issue that has been holding back the ongoing usage of high level CSS? Notably the number of people who are still using IE 5, 5.5 and 6. They are just expecting everyone to suddenly upgrade to Longhorn when there are tons of people out there still running Win 98?
Oh it is to laugh. Whilst I think they might get people falling for it for intranets I think it's going to be a while before you see XAML in the wild.
They are just expecting everyone to suddenly upgrade to Longhorn when there are tons of people out there still running Win 98?
No, they aren't. They're releasing the Avalon engine for use on WinXP and Win2k3. Granted, this excludes Win9x and WinNT/Win2k users, but if a user is using such an old OS, it's not likely that they are the sort of person who's going to be using that many new applications anyway...
It looks like they reinvented XPath
The Paths are object paths, not at all related to the XAML document structure. They're writing something equivalent to "object.Property.SubProperty[index].etc" in C#. The point, though, is that you can write code, call functions, or even use funky reflection calls as your path, if you're that way inclined.
With regards seperation, you can seperate as much or as little as you like - .Net 2.0 (which is a prerequisite for using XAML) allows the use of partial classes, and XAML files are, ultimately, compiled as part of the class. As such, you could have one .xaml file describing your interface components' semantic structure, another for their behaviours, another still for the styling and layout, and so forth. These could even be split further and further, if you felt so inclined.
The thing that most people seem to be conveniently ignoring about XAML is that it's designed to replace the often cumbersome task of building UI inline in your code with something that more closely approximates to a logical layout/structure model than C#/VB.Net/MC++/whatever code.
Perhaps they could have used XUL, but do you really think they would: Micorosoft's politics would dictate they shouldn't, and XUL, frankly, can't do half the things that XAML is capable of (XAML, for example, makes provision for 3D interface rendering, video, and lots of insanely cool looking, but not necessarily useful, things). Whether or not that is a good thing, I guess, depends on your perspective.
Personally, I've got little choice but to learn XAML for my job (I work in a pure Microsoft LE company, much to my dismay at times), so I'm looking at it with high hopes. It may not be perfect, but it's better than the (Microsoft) alternatives...
All that said, I very much agree that it would be nice for Microsoft to have enforced more seperation, but at what cost?
Further, I could have sworn that XAML needs to be compiled for it to be useful, although I may be wrong about this. If that is the case, though, you'll only see XAML "polluting" the web as much as you do C++ or C# or XUL.
Steven, thanks for your comment. Much appreciated.
I too was disappointed at the inline stuff when I had my first look at XAML code about 6 months ago. It seems to me like MS makes 1 big leap forewards for Windows GUI development and 2 steps backwards in regard to current CSS and XHTML development.
What bothers me most is that this could influence my work. I often work on corporate intranets and I can see this penetrating there, forcing me to implement visual designs 1995-style.
When I first saw XAML I too started bitchin' about separation of structure and presentation and a developer collegue too told me about how presentational information could be separated. However, that separate XAML file looked like a carbon copy of the file describing it's workings/structure. As such you can forget about all the flexibility and abstraction and reuse we can put into CSS selectors. It still is inline markup, just in a separate file.
As such you can forget about all the flexibility and abstraction and reuse we can put into CSS selectors. It still is inline markup, just in a separate file.
I very much agree, but you seem to misunderstand what this is a replacement for...
Currently, to render a text box (for example) in a windows form application using C#, I have to write the following in my .cs file:
TextBox t = new TextBox(); t.Height = 22; t.Width = 150; t.Top = 8; t.Left = 8; t.Text = "My funky textbox"; t.Click += new System.EventHandler(this.t_Click);
When one considers that this code is mixed in with potentially hundreds (or maybe thousands, depending on the scale of the form) of lines of form control initialisation code, all flat and inline, with absolutely no structure, the primary purpose of XAML becomes more clear. I don't know about you, but I far prefer the following:
<TextBox Height="2.2em" Width="15em" [...] >My funky textbox</TextBox>
I take the point that yes, Microsoft could have come up with a more semantic markup structure, and used CSS or whatever for styling, with SVG for vector graphics work, but document markup isn't XAML's intention. Yes, application semantics are important for usability and so forth, but XAML is, ultimately, a more structured way of hand-coding windows forms.
Just because it looks like some dirty great hybrid of HTML/XUL/XML/SVG/CSS, it doesn't mean that using those technologies together is necessarily the optimal solution, either.
I've started meandering again, I'm afraid, but to get back to your orignal comment, the examples you've seen aren't the be-all and end-all of XAML - it's incredibly complex and supports things like reflection natively. As such, you can use the document structure and heirarchy or you can use the object heirarchy (IIRC), and you aren't ever bound to using one or the other (in fact, I believe it's fairly easy to, for example, select a bunch of objects using the document structure, then manipulate these using the object heirarcy, all in XAML).
Steven, thanks for your clarification.
I do see your point about what this replaces but I still think the critique here is valid, concidering the focus of this blog.
Nevertheless, thanks for putting it in a wider perspective. Although I know a tiny bit about it, I can imagine quite some readers here haven't really heard of XAML before.
I do see your point about what this replaces but I still think the critique here is valid, concidering the focus of this blog.
Totally. I'm not advocating that XAML is the best it could be (far from it - I completely agree that it should have far more defined seperation, and make use of extant standards, but then this is Microsoft we're talking about), I'm simply saying that, from a pragmatic point of view, one can see the trade-offs that they've made to try to move forward the state of .Net application development, and see why these were made.
Personally, I can't wait simply because, almost once an hour, my team has problems with developing concurrently in .Net (whether it be concurrency of editing, or .Net playing silly buggers, or something else entirely).
If only they'd consistently work with the standards, rather than paying lip-service at times (ASP.Net 2.0) and totally ignoring them at others (XAML, lack of XPath2 support in MSXML, and, dare I say it, IE *shudders*).
Yeah, more in general it's a pity they don't have a stronger design focus (visual/usability/standards). They do have some brilliant people working there and they can have some good ideas, or buy them, but the execution is often rather poor. Tablet pc, anyone? And don't get me started on Sharepoint, talk about 1995...
Personally, I can't wait simply because, almost once an hour, my team has problems with developing concurrently in .Net (whether it be concurrency of editing, or .Net playing silly buggers, or something else entirely).
And don't get me started on Sharepoint, talk about 1995...
As Steven's chief subordinate monkey, all I shall say is that these two quotes bear a relationship for the two of us. And that Sharepoint should burn (or at least be consigned to the "nested tables appreciation society" museum).
This discussion is interesting, it's probably taught more about XAML than anything else that I've taken a half-interest in recently.
I guess from an enlightened post-web-standards point-of-view we'd all really like to see a semantic application language for XAML. As Steve has covered, we've instead got a replacement for the current meaningless WinForms with a different meaningless way.
I can't help feeling that Microsoft have ultimately missed a trick there, especially regarding assistive technology.
A well designed, semantic web page would output rather well in a screenreader (even without a dedicated aural stylesheet). If you could only apply the same design theory to WinForms the quality of assistive tech could only get better.
Right now there are high profile laws that demand accessibility in web pages, but nothing as well known exists (to my knowledge) to demand the same from standalone applications. What if someone realises that there's nothing stopping MS or anyone else from developing forms technology with the same capabilities?
Since Microsoft haven't catered for improved assistive technology in XAML now, they'll inevitably have to throw it away and start again within the next decade. This is in contrast to X/HTML, which will continue to evolve without reinvention.
It is, like a lot of things, a missed opportunity that's quite painful to watch.
There are reasons for the W3C process. This code's definitely "ugly". Huh.
I think the most bothersome is that I am familiar with a set of technologies (like XPath), and to use XAML I would then apparantly basically have to start from scratch learning Microsoft proprietary versions of them.
But, all is not lost :). All I need is some kind of XULRunner connector to .NET/Mono and I will be happy ^_^.
~Grauw
lack of XPath2 support in MSXML
Neither XPath 2.0 nor XSLT 2.0 are standards yet, they are still in working draft and can change. They will change. I think it’s not good to adopt a specification before it is finished, unless you commit yourself to updates when new versions are released and aren’t scared by breaking things because the draft specification changed.
Just look at the XSLT implementation in MSIE 5.0 to see an example of how bad it can get, and how much working drafts can differ from the final thing. XSLT support in MSIE 6.0 is still pretty crappy by the way, e.g. in its XPath implementation div[0] will select the first div! (it should be div[1]).
p.s. Maybe Microsoft just makes up its own languages because history showed it just can’t implement specifications decently. If they make their own thing, they can just say that ‘it was designed that way’ ^_^.
~Grauw
Honestly, what is the point of this? When would we even want a button that doesn't look like one?...
I'm off to learn XUL again.
The example code in this post spills right over the side menu. Can you not use overflow? See pages on QuirksMode for examples. There, long lines of code get horizontal scrollbars.
Question: If I wanted to do the "Flippin' CD Button" using only HTML, CSS and other W3C technologies (and maybe X3D or something), how would I do that? Let's start with the following code:
<html> <head> <title>Flippin' CD Button</title> <link rel="stylesheet" type="text/css" href="3dbutton.css"> </head> <body> <button>Tastes like chicken!</button> </body> </html>
Assume you can use Working Draft technologies like XBL2, by the way. Any takers on this?