John Gossman, architect of the WPF team (desktop and subset taht supplies UI framework for Silverlight), discusses a few of the pain points developers and designers are facing today with WPF to Silverlight portability. From his post:

The above example is a bit of a special case, and I don’t feel bad about it at all.  A much greater struggle that hits a very large number of users is how we do Control templating.  All of the APIs we use in Silverlight’s Beta1 control templating model exist in desktop WPF, and yet the templates are completely different.  By subsetting the APIs we ended up changing not just the best practices, but the essential model. 

Let me be clear.  If you write your own custom control in Silverlight, using the Silverlight model, you can create a template for it and take your custom control and its template and run them on desktop WPF.  The problem is, we do not provide Triggers in Silverlight and many of the properties (IsMouseOver, IsPressed) that Triggers depend on to work.  There are technical reasons Triggers were hard to add in Silverlight 2 (though we will add them in the future), but even greater was the test and development cost of adding all the additional properties necessary to make them work.  So, we decided to make the controls have to “trigger” the state changes themselves in code.  All this code works on desktop WPF.  But existing controls, written for the desktop, don’t contain the code to “trigger” the state changes, so the control templates don’t do anything when applied (they create their children, but don’t react to events).

The more I consider this … the less I care about portability specifically between WPF and Silverlight. It’s unlikely that I’ll ever be able to use or need to use code exactly as it was written for a desktop WPF application (yes, there will be elements that are worth copying — but I believe that a full installed application should work differently from an enhanced web page with Silverlight). If I’m running a WPF app — I’m running a thick, rich, installed application (or click-once). If I’m writing something for Silverlight, I need to write code which lives within the confines of the browser. Although similar, they’re still quite different on many levels.

That being said, I would like the models to be the same — if only because I’ve really become fond of many of the WPF features and techniques for building a user interface: triggers, triggers, and triggers. I can absolutely live without 3D and even without a full .NET framework. But triggers really help separate the UI from the code. I’ve done some investigation and I can’t see how I could create a reasonable approximation of Triggers without a lot of work — and even then it wouldn’t be compatible with WPF XAML. John said “when we add triggers…” …, so it gives me a bit of hope (albeit with no time tables…).