Standartize the core part of XAML platform.

[kekekeks]

I'm one of the developers of Avalonia UI framework and decided to describe my vision of what XAML standard should be, based on knowledge of WPF/UWP, Xamarin.Forms, AvaloniaUI and eto.Forms.

I see a lot of discussions here about adding more controls to XAML standard, but a lot of the people here seem to be ignorant of some fundamental differences between XAML platforms that prevent you from reusing you code between them. Those differences lie at the very core of those platforms: objects, properties and bindings, the bread and butter of every MVVM application.

The foundation of XAML framework is the base class for everything that can have bindings - DependencyObject (WPF, UWP, Xamarin.Forms (BindableObject), AvaloniaUI (AvaloniaObject), eto.Forms (BindableWidget)) and description of how properties should behave - DependencyProperty (WPF, UWP, XamarinForms (BindableProperty), AvaloniaUI (AvaloniaProperty), no equialent for eto.Forms).

On top of them lies the binding system and XAML parser. Which also have completely different implementation.

What's going on there, is people independently implementing essentially the same thing but in completely incompatible way. The only thing so far that's actually shared between XAML platforms is Portable.Xaml parser that's used by eto.Forms and AvaloniaUI, and even there we had to use some adapters to make it work. Then everyone has to implement IDE support, which is another chunk of work.

The outcome of the situation is that one can't write a portable library for XAML platforms, even if it doesn't even need to interact with actual controls. You can't reuse your markup extensions, you can't reuse your helpers for bindings. MVVM frameworks like Prism, ReactiveUI or Caliburn.Micro have to implement various adapters for each UI framework. Microsoft have released an excellent XamlBehaviors library, but we had to fork and patch it to make it work with Avalonia.

If we can't even reuse simple stuff like that, there won't be a true "standard", just a bunch of controls with properties that more or less exist everywhere. You won't be able to share your XAML markup between platforms, because XAML isn't just controls, it's a glue that ties them together.

So, what XAML standard should be? I think, we need two separate standards, actually. XAML UI Controls Standard, which is basically what's described in the current draft, and XAML Platform Standard, which should consist of:

• Common property and binding standard, that requires frameworks to implement IXamlStandardDependencyObject, IXamlStandardDependencyProperty, etc, so they can be used from framework-agnostic libraries
• Common XAML parsing infrastructure. Require XAML parsers to support framework-agnostic versions of markup extensions that implement IXamlStandardMarkupExtension interface.

[Mike-E-angelo]

Thanks for your contribution, @kekekeks (not to mention your commendable and impressive efforts in Avalonia!). FWIW, we're pawing at a few of these items/concepts in #145. 👍

[tdjastrzebski]

I watch XAML Standard efforts since the very beginning and with every month I doubt more and more it is really going to fly this way getting heavier and heavier. As @kekekeks pointed out, perhaps most of the issues opened should NOT be part of Standard XAML specification at all but are rather component (feature) wish list.

So, how about completing some XAML Core Standard first? I mean, like MVP - minimum viable product?

[yariker]

Isn't the whole idea of XAML Standard is to standardize the UI definitions, namely the content of a XAML file, rather than creating a bunch of portable libraries? When you see a TextBlock in XAML, you don't actually care if it's backed by a DependencyObject, BindableWidget or whatever. When you see a {Binding}, you don't care if there is a DependencyProperty or BindableProperty behind it, and so on. You just wan't to reuse the same XAML file across different implementations.

[kekekeks]

You just wan't to reuse the same XAML file across different implementations.

The problem is that if you are writing something more complex than HelloWorld, you won't be able to do that. Because any complex XAML application uses 3rd-party or custom markup extensions and converters, so XAML markup won't be portable anyway.

[tdjastrzebski]

@krs500 Not to mention creating widgets and/or bindings in code. Without standardizing objects behind UI any implementation will not gain a practical meaning - I am afraid.

I would be perfectly happy if, instead of creating yet another specification, one of the existing implementations (WPF, UWP, Silverlight etc) is assumed a standard one. Maybe with only minor, obvious improvements. With such approach, XAML Standard 1.0 would have been released already.

That is all with the assumption that the goal of this initiative is actually to create XAML Standard. I start having doubts.

[yariker]

XAML Standard (as far as I understand) is all about finding/establishing a common denominator among the zoo of frameworks (and, in some cases, force them to support it), so that you could reuse a piece of XAML between different targets. If in your XAML file, you want to use a custom control/markup extension/converter that is not a part of XAML Standard, then you'll not able to share it -- and that's the trade off.

[tdjastrzebski]

@krs500 it does not have to be like that and it should not.
Just like in .Net Core app you can use your .Net Standard library, let's say with extension methods.
That was the vision presented at Build 2017 - I believe.
Otherwise, XAML Standard will remain just an interesting, meaningless initiative invented for pure invention.

[insinfo]

Thanks for your contribution, @kekekeks