What about simply .ui?

Could this distinction be helpful for non-island cases as well, or would it be more confusing?

Or if this is primarily to help distinguish between e.g. WPF and WinUI Xaml in the same solution then what about a convention like .winui.xaml or .island.xaml? That would probably make it easier to use existing tools.

Would this be for XAML Islands scenarios or everywhere? For every other scenario I don't see what would be the value of this, beyond creating confusion and forcing people to migrate (and probably break backwards compatibility for a lot of tooling like older versions of VS). A convention like "whatever.winui.xaml" would probably be less destructive, but I still only see it being useful in the scope of an Island, not everywhere else.

Changing the tittle given I don't want to scope down the discussion to just XAML Islands.

I say keep using .xaml. The scope (and the name) of WinUi might change to include other platforms beside windows (Maybe through UnoPlatform?). What happens if the name of the project changed?

I lean more towards NO. Microsoft has been doing too many renames for products and services sometimes to the detriment of the product/service or their users (opinion). This is yet another rename.

Would this be for XAML Islands scenarios or everywhere? For every other scenario I don't see what would be the value of this, beyond creating confusion and forcing people to migrate (and probably break backwards compatibility for a lot of tooling like older versions of VS). A convention like "whatever.winui.xaml" would probably be less destructive, but I still only see it being useful in the scope of an Island, not everywhere else.

Everywhere

I think XAML should stay .xaml but if something new were to show up either to replace or be useful alongside traditional XAML, then a .winui extension could be useful for that. #804 :)

This request totally confuses me … I had to read this issue twice to comprehend what was going on... This will REALLY fragment the xaml ecosystem more than the different dialects ever did..

Lost for words right now...

@liquidboy well that's at least one clear piece of feedback in favor of not making this change :) Thanks for lending your voice.

I like the idea from @jesbis, perhaps we could add a *.islands.xaml that helps to more easily distinguish the difference between XAML files that are running in an Islands context vs. not.

Curious: would it be better to have .islands.xaml that only applies to XAML files in an Island, or just to use .winui.xaml as an overall extension everywhere? I'm not sure which one I like better of those two ideas.

My vote is for ".islands.xaml" or similar to be the recommended (but not strictly enforced) pattern in islands, and everywhere else .xaml files are still .xaml files. That way we avoid unnecessarily impacting people that do not use islands.

My biggest concern comes from all of the tooling. I have no problem with the different extension, but this means that every tool that relies on the .xaml file extension will need to update (I am thinking of things like R#, XamlStyler, etc). The tooling support around xaml already feels like it is struggling, and this looks like it would likely make it worse.

My $0.02

Perhaps the issue title should be changed to something like:
Should XAML files included for Xaml Islands, have a different file extension with WinUI 3 projects?

I'm strongly in favor of keeping .xaml in there. Maybe you go .ui.xaml or .xaml.ui but the technology is strong and it keeps help available. On the other side, unfortunately xaml has some stigma around it after wpf performance pitfalls, silverlight, and windows phone, so a cleaner filename could help turn the corner. I still love xaml, but we don't need more confusion on technology names unless it's clearly thought out.

I think it's a good idea to have it simply as .ui since if winui ever becomes cross platform (like many windows stuff has), it will be more suited.

This means that it will be future proof.

Code files will have a .ui.cs extension which is self explanatory and easy to read.

.winui.xaml

So that means we'll have .winui.xaml.cs files? yikes..

Use json format. It is 2020.

JSON is harsh and not very friendly to work with.

Use json format. It is 2020.

JSON format is for computers to read, not for humans. It's hard to read and doesn't look nice.

I think the .winui will make the beginner give up. Because we will think we should learn a new language. And now we have WinForms and WPF and UWP and SL and ASP and ASP.NET Core. We should spend more and more time to learn it but not inherit. I do not think we should always make the new technology.

Sorry, I and many of my friends do not like to learn new things. If we do not expect to be the minority, that we should make the technology can be inherited and can be reused and compatible.

In my opinion, a more elegant solution to "which XAML is which" would be to depend on the default xmlns namespace, as suggest by @grokys in this comment: https://github.com/AvaloniaUI/AvaloniaVS/issues/95#issuecomment-541078633

We didn't do this with UWP, but perhaps we can change it for WinUI.

In my opinion, a more elegant solution to "which XAML is which" would be to depend on the default xmlns namespace, as suggest by @grokys in this comment: AvaloniaUI/AvaloniaVS#95 (comment)

We didn't do this with UWP, but perhaps we can change it for WinUI.

You could introduce the equivalent of a Doctype, as with HTML?

You could introduce the equivalent of a Doctype, as with HTML?

Perhaps, but we shouldn't have to. The default namespace should be what sets each different platform apart (they do in code-behind after all)

The tooling support around xaml already feels like it is struggling, and this looks like it would likely make it worse.

@keboo this hits home for me real hard, and is something I'm pushing hard for us to fix and do right.
The fact that we are in a world where we can't tell them apart (for the islands scenario) is a product of how the tooling has evolved over the years. Everything is completely separate, and it's nearly impossible to rationalize differences between the different dialects. I want to change this, and start making XAML parsing and compilation something that can be easily shared across all XAML dialects, where in this example, WinUI and WPF are using the same fundamental engine. The tooling should be plugin-able as declared by the default namespace and can be customized where needed. In my opinion, we shouldn't need anything more than that to make this scenario work properly. Although it's a huge endeavor, to me it's the right thing for us all to do.

@stevenbrix The platform would currently understand when XAML is being used within an Island situation, but what I read into the ask of this issue, is a way for the developer to tell and understand how the .xaml file will be consumed within a WinUI 3.0 project.

As for XAML tooling in general, it needs a total re-do of the design time experience IMO. Expression Blend was the last time XAML design and development felt top tier.

Because of the nature of XAML, it is both a written form, and a visual form. Visual XAML design has taken a backseat to bring Intellisense to a good quality. If there could be a robust, performant, and easy to both prototype and polish XAML design experience - that could reinvigorate the community.

A plugin approach, which does not require a lot of work for control or toolkit vendors to do, whilst still giving a good design time, tool pallette, element property experience - could be very helpful. As XAML moves into other non-traditional form factors, the design workflow needs to be considered. Two Pane views (Neo and Duo), non-window hosted XAML surfaces, Shell integrations, mixed framework projects (xaml islands, GDI and WinUI mixes), Hololens Spatial 3D, Rotating Surface Hubs, etc.

But maybe declarative markup is no longer the ideal way to handle it. Or maybe there should be more separation between XAML content, and XAML styling? As with HTML and CSS?

WinUI feels like a good opportunity to not only carry over things as they are, but also to plan for the next decades to come.

No. I don't see the point. It doesn't solve anything.
If anything, it creates issues with editors that already know the xaml extension.
I work with wpf, uwp and forms xaml every single day and I've never been confused due to the extension.

Isn't the whole point of Xaml that it's easier for tooling? Can't tooling figure this out without relying on the ancient idea of file extensions?

I mean generally, if nothing is changing in the UI framework, i.e. It's still XAML, don't do it.

If it was a completely new UI framework, then I'd not see a problem.

I also don't know why you'd want to differentiate XAML components for islands either with the proposed islands.xaml. Would it do anything different in tooling or is it just for readability in a solution?

My first thought is that I absolutely don't like this idea. But maybe I don't see the real problems it can solve, and maybe I don't get the point.

If there's a file with xaml in it, I want it to be a .xaml file. In the past, it never came to my mind that I want to have a UWP .xaml file to be named differently from a WPF .xaml file.

The next thing is that a framework name in a file-extension doesn't seem to be a good idea, as framework names might change, and XAML is 4ever XAML.

So, my opinion is: Definitely stay with .xaml.

But what are the options with a .xaml file extension?
Another .islands.xaml file extension? That would mean that the file extension is used not only to describe the format, but also the contents of a file. Mhm... But the advantage of this one is that you can make it optional for a developer. If they want to use it, they can call their files .islands.xaml and the tooling will pick that up with different icons etc.

Another default-namespace is also a valid option. But that would mean for the tooling that it has to look into every .xaml file to find out what kind of file it is. And it would also mean that the XAML dialects are again diverged a bit because of another root namespace.

But now a completely different thought:

If I got it right, all these changes are only really helpful for the XAML Island case where you mix platforms in the same solution, right? Because if you just use WinUI, you know every XAML file uses WinUI. I'm not sure if XAML Islands will be a main scenario for WinUI or not. In the past when WPF was introduced, we had also WPF and WinForms interop, and to be honest, I've rarely seen developers using WPF controls in their WinForms applications. Instead, they continued to use WinForms in WInForms and they started new projects with WPF instead of WinForms. And maybe the same could be true for WinUI 3, and I think it will be the case. XAML Islands is a great way to modernize, but in my experience, developers will only do it if they definitely need a control from WinUI in their WPF/WinForms app. If not, they continue on the old stack and they start new apps on the new stack. Note that this doesn't have to be the truth, it's just my experience. :-)

That means we're talking about changing a file name for a scenario that might not be the main scenario for the platform. And I guess that's why I think it's not worth it. What if a WPF/UWP/Silverlight/Windows Phone developer creates a new WinUI 3 project? They will think

Why the heck did they change the .xaml file extension to ...?

Please don't remove the .xaml file extension.

Please don't go changing extensions!

Many years ago we started using the .paml extension in Avalonia but in the end went back to .xaml because of the problems it caused: there is already tooling in IDEs to handle XAML (no matter how janky, at least it's something!).

If we're going to expect every XAML dialect to have their own file extension then every project that wants to use XAML is going to have to write 100% of the tooling from scratch - even things like the tooling for renaming files is going to need to be rewritten each time to also rename codebehind classes etc.

As @stevenbrix mentioned above, there is a perfectly good way to tell which dialect of XAML a file is using which is the default namespace at the top of the file. As a first step, make the tooling respect this.

Then open up the XAML language service, provide an API for interacting with a designer and everyone can benefit ;)

Pretty please ;)

One more reason not to: UWP already struggle with adoption issues. Renaming it sells it as yet another technology, rather than "it's more or less the same thing as wpf".
There are already bigger issues with WinUI 3.0 breaking changes that's significantly going to hurt the existing uwp ecosystem. Don't add yet another thing that's different.
It's still xaml, just hitting different API sets, just like c# is still c# even I use it for different UI framework. Code and the APIs I can use change, but it's still the same language.

I vote no, I see no benefits, just added confusion.

One more reason not to: UWP already struggle with adoption issues. Renaming it sells it as yet another technology, rather than "it's more or less the same thing as wpf".
There are already bigger issues with WinUI 3.0 breaking changes that's significantly going to hurt the existing uwp ecosystem. Don't add yet another thing that's different.
It's still xaml, just hitting different API sets, just like c# is still c# even I use it for different UI framework. Code and the APIs I can use change, but it's still the same language.

@dotMorten Ha, I had the same thought with C#. If we call the .xaml files .winui, we should call the .cs files .wincode to make it consistent. :-)

Maybe I'm still missing something, but to me it causes more confusion and I don't see the real benefits of it.

My 2 cents, stick with _.xaml_, please.
Please unite things rather than diverging them.

What if you want to share small XAML snippets between WPF and WinUI? I’m guessing there must be SOME overlap, no? It would make shared projects less useful... or is there really a huge difference? If it is mostly the same similar XAML then keep the same extension. If the format is MOSTLY different than transitional XAML then it might be somewhat more acceptable to change the extension. The real question then is how close is the format to the original?

XAML is also used in Xamarin which targets not only Windows but iOS, Android, macOS...

Replacing .xaml by .winui will create a situation where Xamarin will keep .xaml for XAML files (why one would use .winui for iOS or Android ?) and Windows targets like UWP/WPF... will move to .winui for XAML files.

TL;DR one file format/convention two names (.winui for Windows, .xaml for Xamarin), to me it's confusing.

Extension should be .xaml as syntax of content it's xaml, another extension would only create confusion.
I vote for something like .winui.xaml

stay with ".xaml" , Its powerful

I have to say, Microsoft has an issue of pathological naming!

And this one really tops them all.

No

If you need to have UWP XAML and WPF XAML within the same project file, use a new Custom Tool instead.

This way, the tool will detect if the XAML file is using UWP XAML or WPF XAML and sends them to the correct compiler via msbuild targets.

Even better way is to standardize XAML language, so that we can develop a common compiler, binary format and framework lib.

That's how I would do it!

Since you are asking, no don't do it.

If tooling can't read the file to see the difference, then WORSE CASE should be a non-required convention of ".winui.xaml" or the like. Again the key being NOT-REQUIRED . Just xaml extension files should work fine but maybe missing some enhanced tooling.

While I understand the idea behind this, I think is a bad solution.
First, WinUI is the framework commercial name, not the file format. What if someone decides version 4 need to change the name to UniversalUI or something else? You would end with a framework name different from the file extension, different from the file format. It could be a nightmare.

Second, it could breaks compatibility with existing tools and documentation. Future devs could not have clear that WinUI files are internally xaml so they would not find xaml documents as relevant ones.

Third, it would fragment more the UI languages used in Microsoft products. I really thing we need to go more to a standard in Xaml, so the product is not so important. C# is the same for Xamarin, Net Core, Windows 10 or WPF, why XAML need to be different?

Let people arrange their projects and organize the code so it is not confusing for them.

Use json format. It is 2020.

@rickydatta Even in 2020 the web uses HTML instead of JSON to define user interfaces. There are many reasons why markup languages like HTML and XAML are great to define UIs. JSON is great for several things, but imo not for defining UIs. When you use JSON for a UI and you try to build features like data binding, static resource references etc., you'll see it gets quite unreadable. But it's offtopic here, so let's leave it. If you want JSON, please create a new issue and let's see how the community reacts to it. :-)

I really tried to avoid commenting here as most of this has already been said, but I've given in. Sorry. I'm weak.

Don't do this. Just don't.

If you want to make a change, there needs to be a clear set of benefits that outweigh the negatives.

What are the potential benefits?

• It would avoid possible confusion for people who have some .xaml files that entirely contain WinUI controls and some .xaml files that don't.
• Help enable tooling to determine how to work with the potentially different content of .xaml files.

That's it.
I've reread this entire thread three times, and I can't see any other potential benefits listed here.

What are the potential down-sides?

• It would introduce confusion.
  -- "What is this new extension?" "What do I need to open it?" "How is it different to ...?" "Why did they change it?"
  -- What extension do you use for a file that only contains some WinUI controls, when mixing existing UWP XAML and WinUI3 elements? Or does this very suggestion imply that this capability will be going away? (See, just by making the suggestion to change a file extension, you're already introducing more confusion and FUD. If things like file extensions may still change, perhaps I should wait on looking at WinUI, in any capacity, until it's more stable. Several people have told me to investigate Flutter. Perhaps a better future for me lies there.)
  -- My understanding of one of the selling points of Xaml Islands in existing WPF apps was that it meant the ability to reuse existing skills and knowledge in working with XAML. This change suggests it's not just XAML, so it's another thing that must be learned, and so is another potential barrier to adoption.)

• It's unnecessary.
  -- If people want to break up files within a solution they can already do this in multiple ways: different projects; different directories; prefixes or suffixes on file names; using multiple/sub-extensions; or nesting files within the VS Solution explorer. It's not clear how a new extension or forcing everyone to use multiple/sub extensions is better than any of these options.
  -- [Default] Namespaces within the file already tell tooling what dialect of XAML is in use and what should be possible with it. (There may be some otherwise undocumented issue in this area which means this isn't possible, but if that's the case, then more information is needed on why changing the file extension is the best solution for that problem.)

• It ignores history.
  -- I've previously worked with solutions that contained projects targeting WPF, Silverlight, and Windows Phone. They all used different XAML dialects but I never once got confused about which was in use or what I could do within a file. I've worked with solutions that contain XAML for UWP and Xamarin.Forms but not experienced the confusion predicted in the assumption behind this issue. I've also spoken to many other developers with similar solutions, and I've never heard anyone else say that using different extensions would help them.
  -- Of all the criticisms that I've heard about there being different dialects of XAML, confusion based on file naming has never been one of them.
  -- Developers generally don't like it when you tell them how they should name and structure files and projects without very good reason. It can be much better to document guidance and recommended/suggested practices for scenarios such as working with projects that contain files with similar contents.
  -- One big reason that the wider use of multiple extensions on a file has never taken off is that File Explorer (or anything that lists the contents of the file system--including OS provided pickers and dialog) can bring more confusion when they (are configured to--which is the default) hide known file extensions. This can make MyClass.winui.xaml look like MyClass.winui which then leads to questions and confusion about what the file is, where it came from, why it's being shown, etc.
  -- Adding multiple/sub extensions increases file length and so increases the chances of running into MAXPATH related issues. Maybe one day this won't be an issue, but we're not there yet. I'd hate to see developers forced to give their files (and classes, as the two are typically kept in sync) less descriptive names because the tooling now needed an extra six characters for the extension(s).

• It creates more work for tooling developers. (Both within and external to Microsoft.)
  -- More case to handle.
  -- More scenarios to document and test.
  -- Less time spent on bug fixes and new features. With current XAML tooling perceived as being lacking behind other technologies and slow to create custom tooling for, why do anything that makes building new tooling slower?

• It risks setting a very bad precedent.
  -- If this happened, why would it not then be appropriate to replace all current .xaml files with .wpf, .uwp, .xamarinforms, etc.? Or .xaml2006, .xaml20009, .xaml-uwp5 if the underlying namespace, rather than where they're used is the key issue? There would be a minimal potential benefit (as in this case), but it would be seen by many as the way that Microsoft suggests naming files. (I wouldn't be surprised if someone didn't make such proposals just on seeing the discussion here.)
  -- I'm not aware of (but happy to be corrected about) any MS provided tooling handling files differently based on sub-extensions but doing this would likely force Visual Studio (and others?, including Windows Shell?) into needing to be able to handle these scenarios. Then, once the capability is there I can imagine the temptation to introduce a wide range of complex but otherwise unnecessary naming suggestions being proposed and introduced being too much for some developers, leading to confusion for the rest of us.

In summary, the proposal would bring confusion and more work for a theoretical benefit in limited circumstances. If you did this, I'd give up on Windows development.

Thanks to everyone for lending your voice. We heard you! We collected enough feedback, so we can firmly say that changing the .xaml extension is a non-go.

It is not our intent to fragment the ecosystem or break 3rd party tools (and there are a lot). We agree that XAML is the language, and WinUI 3 is a UI Framework that uses XAML. For all these reasons, and other ones, make sense to continue using the xaml extension.

Our team still have to do some homework and evaluate other alternatives that we should consult with the community later. For instance:

1. Do nothing. XAML Islands dev experience will be as it: XAML files in a different project (perhaps this is not a big deal). WInUI 3 will use the same namespace, and it doesn't matter because it will be the only XAML language used on the project.

2. Use namespaces to differentiate between UIs based on XAML. Today, WPF XAML and UWP XAML use the same namespaces, perhaps WinUI 3should use a different namespace like Xamarin Forms is doing ( "http://xamarin.com/schemas/2014/forms"), so the compilers, tools, and designers can differentiate files. On the flip side, this will create dialects, although this is happing today. In theory, this will facilitate devs to copy and paste XAML examples from docs/blogs, although unfortunately, there are a lot of samples that don't include namespaces.

3. Do something, but just for Islands. No need to differentiate at all the UI frameworks. We can use conventions. For instance, in the future, a WPF app with XAML Island can contain XAML files in a specific folder (islands folder?). This is similar to the UWP localization (Strings/en-US/Resources.resw).

Thank you again for your feedback. I will open new discussions when we mature more ideas.

Including a snippit or doctype style line for an island file, should be enough for the tooling.

If like the .ui.xaml idea because it is a good compromise. It is still a valid XAML extension, and can also help select the correct editor and icons. It is also more efficient than opening and parsing dozens/hundreds of XAML files just to find a type.

@marb2000 WinUI 3 is a UI Framework that uses XAML

Should be: WinUI 3 is a UI Framework that can use XAML. Since it doesn't require the use of XAML and doesn't need a dependency on the XAML language.

We agree that XAML is the language

That's good, and a lot of namespaces that are called XAML need to be renamed in WinUI: anything that doesn't have to do with the XAML language.

The de-emphasis of UWP has been painful to witness. Now, when you do a search on channel 9 for UWP content, you get Xamarin content. It's such an obvious ploy. Please stop trying to morph UWP into something else! Re-invest, double down, and make it work. UWP does not need a course correction, it needs the Xamarin and Office teams to get on board. Internal Microsoft politics are killing UWP.

@Noemata Is it an official note?