In a few newsgroup posts on our forums, I’ve seen some confusion about what WPF/E CTP enables and what it doesn’t.  This is probably a result of the snappy codename we’ve chosen, but I’ll attempt to add some clarity.  WPF/E is a subset of WPF, but the subset was chosen in a careful way to enable web scenarios that are not possible with HTML alone.

 

On the team, the way we think of WPF/E is this: WPF/E is a browser plug-in that augments the set of functionality provided by HTML to provide media, animation and vector graphics with the same programming model that the HTML DOM exposes.  This CTP of WPF/E is not a UI technology that replaces HTML, it augments the capabilities.

 

HTML elements can be created, accessed and modified using javascript running on a web page.  WPF/E elements can be created, accessed and modified using javascript running on a web page.  HTML is easy to search since it is sent to the user as plain text.  WPF/E is also sent to the user as plain text.  HTML samples and tricks are shared organically because the page source can be easily viewed.  WPF/E allows for the same thing. 

 

HTML provides flow text layout, text input, tabular and flow layout panels, and a simple set of UI controls.  WPF/E provides media playback, vector graphic drawing and animation support.  The two sets of capabilities compliment one another.

 

This is not to say other parts of WPF will not be incorporated into WPF/E in future CTPs and versions of the product, because we are definitely planning on growing our WPF subset and the overlap with HTML features.  Very important things like text input, layout, resources, data binding and of course, CLR integration are all WPF features that our team is scoping for integration with WFP/E.  I’m just trying to frame the approach we’ve taken with the initial CTP of WPF/E.  Extend the browser and give users the most consistent development model we can.