search

microsoft / microsoft-ui-xaml

Windows UI Library: the latest Windows 10 native controls and Fluent styles for your applications
MIT License
6.34k stars 677 forks source link

Proposal: Add support for 'XmlnsDefinitionAttribute' #1347

Open dotMorten opened 5 years ago

dotMorten commented 5 years ago

Proposal: Add support for 'XmlnsDefinitionAttribute'

Summary

XmlnsDefinitionAttribute is an absolutely great attribute for Control Library developers. It allows the developers of that control library to greatly simplify the xaml by reducing the number of XMLNS declarations they need.

Rationale

When using 3rd party control libraries and classes, it can be tedious to register a bunch of different xml namespaces. This was solved in WPF using the XmlnsDefinitionAttribute at the assembly level. The only way around this is for the control vendor to throw every single class that might be used in XAML (not just controls but other types too), in the same namespace, creating a very ugly unwieldy API to code against. If you use a 3rd party control library or you're a control library vendor, you should vote for this. It'll save you a lot of typing, looking for controls and types etc.

WPF and Xamarin.Forms already support this, but it is missing from UWP.

This is already one of the highest voted* XAML issues on UserVoice with several key 3rd party library vendors chiming in as well: https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/9523650-add-support-for-xmlnsdefinitionattribute

stevenbrix commented 4 years ago

Thanks for filing this @dotMorten, I definitely agree this is something we should support. There are a handful of other nice features that are in WPF/Xamarin.Forms that we also don't have in UWP, which I'd love to see brought over as well.

One thing that I've been investigating and trying to gauge whether there is interest, is around making a single XAML toolchain that works for all XAML platforms (a la C#). This would help ensure we design the XAML language and tooling in a way where this doesn't happen again. There are current implementations that I believe we can build off, so we won't be completely starting from scratch.

Do you think something like this adds value, and if so, are you ok with this feature (or similar ones) not making it to WinUI until then?

dotMorten commented 4 years ago

Am I ok waiting until then? Well I've waited for years (initially requested this when Windows 8 xaml shipped). What's the timeline you're thinking? It would be awesome to have this with WinUI3 to come together with this clean xaml break.

stevenbrix commented 4 years ago

Am I ok waiting until then? Well I've waited for years (initially requested this when Windows 8 xaml

🤦‍♂️

What's the timeline you're thinking?

Timeline I'm thinking is November 2020 by .NET 5. One of the key things I'm trying to light up is better Xaml Island syntax then what we have today, and allow for natively embedding WinUI markup in WPF markup (with support for things like x:Bind) rather than having to specify the type name like we have today.

If early on it starts to look like it would be pushed out until .NET 6 time frame, then we could probably look at adding features like this to the existing tooling. I don't imagine it would take that long, and the only thing tying this to .NET releases, is Xaml Island integration. Meaning, this is something we could ship WinUI support for between .NET 5 and .NET 6.

dotMorten commented 4 years ago

I didn't expect anything until then, so that's fine by me

dansiegel commented 4 years ago

I should add besides just control libraries, this would also be very welcome for frameworks. This is something that we've been wanting to add for Prism.Uno.