What about the Flexbox support and implementation? Does this require some additional explanation to further discussion on that aspect of this proposal?

Who would this be for? I always thought that Flexbox value for the Web developers is clear: to help them with the layout issues of HTML (which was never designed for apps, is text oriented, causes painful positioning of vertical content etc).

Us who have had XAML (all the way back to WPF) have this covered just fine with the concept of Panels (or in Xamarin Layouts). Personally, I liked the best approach taken by WPF where the number of panels was kept to the absolute minimum. It is a bit hostile toward newcomers, because they immediately need to think about how to decompose their layout into the basic building blocks, but the onboarding is quick because there's so few containers to choose from.

Along those same lines, I'd find it redundant at best and confusing at worst to add yet another layout system to Xamarin.

I though that the "let's develop Windows (RT) applications in JavaScript!!!" fiasco has proved one thing: Web developers develop Web sites (some try to do apps too, God help us all), Desktop/Mobile developers develop applications and the two worlds do not necessarily have a lot in common (which is fine).

Personally, I think Flexbox support is a nice addition. If it works well, I would use it. If not, I can ignore it.
The question that is always in the air is how many developers could be working on bugs instead of doing new features, but that's not something I have enough insights into and, in the end, is not on topic as you said.

@DavidOrtinau you've mentioned the community wants 'stability and performance'. This features does not come under that banner so why even consider it before performance is nailed down?

The FlexBox control could be implemented by anyone in the community, it's a higher level component unlike core performance issues.

It's also important to note that a CollectionView that supports cell recycling is a much more desired component within the community, it's core mobile control that's the next step after a ListView. Nobody specifically asks for a CollectionView because they don't know what they're looking for but the forums are riddled with problem that could be solved with a CollectionView, alternative names are WrapLayout or Horizontal ListView. The FlexBox really solves no problems that cannot already be done with current layouts, it's just a 'nice to have'.

@DavidOrtinau thanks for the open communication and listening to feedback.

My 2c would be to just park this feature and focus on delivering the current roadmap for Q2 without this feature. This component will be easy to prototype/iterate which you've done, but very very very hard to nail down and deliver with high quality that people want. It's got a good chance to be painful and even annoy people when it's buggy. Just park it.

@DavidOrtinau I can see this was committed a few hours ago, so I would add that if FlexBox is easy/already done and it will be easy to maintain then it would be ok to continue. I'm about to give it a go.

These comments are off topic. If you want to discuss Roadmap, we can do so over there. If you wish to discuss particular bug issues, reach out to me directly.

Please either edit your comment immediately to stay on focus with the proposal, or I'll need to delete it in keeping with our forum policy and guidelines.

@ClintStLaurent much of the work you see on this in GitHub was done in the community space and on personal time before being brought into the Forms team.

Your feedback here IS having a direct impact.

@MichaelRidland stability and performance are important and driving our decisions. I'm working now on how we can improve our communication on that, create more visibility, and of course deliver on that. Recent prereleases have a lot of fixes and performance improvements in 2.3.4 and nightlies.

This isn't the entire story. We have to continue maturing the platform. I think the Roadmap clearly shows this, but perhaps I could improve our communication on that. The Roadmap shows what we are working on with regards to performance and features.

@MichaelRidland said:@DavidOrtinau you've mentioned the community wants 'stability and performance'. This features does not come under that banner so why even consider it before performance is nailed down?

The FlexBox control could be implemented by anyone in the community, it's a higher level component unlike core performance issues.

It's also important to note that a CollectionView that supports cell recycling is a much more desired component within the community, it's core mobile control that's the next step after a ListView. Nobody specifically asks for a CollectionView because they don't know what they're looking for but the forums are riddled with problem that could be solved with a CollectionView, alternative names are WrapLayout or Horizontal ListView. The FlexBox really solves no problems that cannot already be done with current layouts, it's just a 'nice to have'.

I'd welcome a proposal on CollectionView. We don't limit proposals to only things that solve problems. There are many reasons why a proposal might be accepted.

Adding CSS support is awesome. Flexbox is nice, but ensure it has better performance than the current controls.
I don't know why anyone would say that the built in styling in XAML is good, it is simply atrocious and awful at the same time.

@ToniPetrina said:
Adding CSS support is awesome. Flexbox is nice, but ensure it has better performance than the current controls.
I don't know why anyone would say that the built in styling in XAML is good, it is simply atrocious and awful at the same time.

Let me clarify, you say XAMl is awful and that's fine but it's a massive selling point for many of us and the reason many companies are looking at Forms, there's a skills transfer from WPF/Silverlight/UWP developers who are already coding in C#. Also as a Microsoft product, XAML is the main UI description markup of choice, I don't see that changing soon.

The majority are simply saying, please fix the fundamental issues in the core product and then focus on this if they want.

XAML has many fans (including me) but some people don't like it, CSS has fans but also plenty people don't like it it. XAML was in Forms 1st and strategically important I would say to Form's future, CSS isn't at the moment.

I doubt we'll every agree on this one and probably taking the thread of topic so feel free to contact me direct to discuss further if you want.

CSS and XAML are not opposed to each other and one can use both. Heck, one should use both since CSS is much better for writing styles than XML. Funny thing is that long time ago I made a toy project that enabled cascading styles in XAML while still writing styles in XAML itself. Instead of referencing style in control, control would declare styles which would then be merged into a new style that is applied just to that control.

So, the problem is not the choice of formatting or files, it is that the XAML technologies are by design weak in this area.

Also, don't presume which technologies I am using in day to day basis or which technologies I like/dislike, that is besides the point.

@DavidOrtinau
I was kinda rough on David and wanted to apologize just as publicly. The subject of ignored developer reports on Bugzilla is a pet peeve and I let it get under my skin and took it out on him and I shouldn't have. It was very unprofessional of me and I am sorry.

@DavidOrtinau said:
CSS files are in practice just a different way to define a Xamarin.Forms.IStyle.

That's the point! It might be cool to have it. But it should then be an additional library. In my opinion, XF should try to stay as streamlined as possible. Different ways of getting things done will confuse new developers and adds unnecessary maintenance effort to the XF Team. You have to support 4+ different (fast changing platforms). CSS adds no value and it will lack editor support.

Currently we have these options to style:

XAML

Code behind

Effects

Custom Renderers

Native styles (like UIAppearance, style.xml, ...)

Why add another option instead of enhancing the existing options if a feature (e.g. selectors) is missing? It's like buying a new car to get a rear spoiler, because the current one has none.

I read a lot XF code... I believe, the XF team could use the time for better things.

@DavidOrtinau My Two cents ( FYI: I started Xammie coding before there was a Forms option... )

CSS

As a consultant/devops with various involvement in 22 live (5 dead) Xamarin-Based projects (Apple/Google Store and Private/Enterprise) and 5(?) in the works, not once has a development customer ever brought up CSS as an issue or a need.

90% of the clients have full-fledge development groups coding in Java/ObjC/Swift/C# and some have mobile UI designers on-staff or use a mobile design agency to produce the user experience (wireframes, mockups, click-through prototypes). These are 6 and 7 digit budgeted mobile applications with active users ranging from 50k-1M+, not part-time LoB apps within a company of 10 field-based sales reps...well a couple are (but even those had $250,000+ initial budgets and full time DevOps assigned for the life of the app).

Would CSS support be a nice to have? Sure, but I am currently losing nothing today by not having it in some partial form tomorrow.

The actual number of completely different style elements coming out of a professional UI designed App is relatively small. Would my XAML look cleaner with CSS, maybe, but I already consolidate all of my Form styles to match the designer choices as all of theirs are in one electronic design doc and most of their tools consolidate and merge dups and point out similar but slightly different variant styles as a possible design flaw, Sketch is amazing at this...). Would it be "quicker" and save time/$? A little, as I would require the designer to supply the CSS, but I would still have to handle all the selector naming/mapping as most of their tools would not match "C# class name selectors" and having them change design names in their docs typically will not fly, period... Each UI iteration would require me to remap the new CSS, over and over and over...

Note: I handle this today by exporting CSS out of Sketch, but have a CSS-2-XAML/ISTYLE utility that I integrate with SketchTool (Sketch's cmd-line exporter). There are other tools that can provide CSS, like CC Comp, but I have not automated those, I manually do an export and hand-map the conversion in a T4 doc the first time... Again having CSS support would be nice, but I still have to do all the selector mappings myself. Not sure what the dev-cycle time&cost is to develop this feature, but since I already have tooling for Sketch CSS export/conversions, it saves my zero time there, and with tools like CC Comp, maybe 2 hours for the first conversion, but I would still need to write a T4 doc for selector mapping so the next time the conversion for this particular app is needed due to UI design styling changes the time/cost is zero. Next new app and UI Design, this process starts from scratch.

Would some of my "webbie" clients like it yes, BUT, they need the FULL CSS spec, no picking and choosing, support it all, or nothing, ... otherwise those developers might as well just keep using hybrid-apps where they do have access for full CSS and HTML support (personally yuk, but web-based development shops who do mobile, have to have it all, otherwise they are a non- Xamarin customer, there would be zero developer conversion here).

What will I hate about it the CSS option? That is placed on top of a issue laden widget system within a horribly slow layout framework, sorry but that is my experience earn in very hard ways. Is Xamarin.Forms getting better? Yes, everyday a little bit in regards to some of the widget/renderer issues, but there is a long way to go. Are the layout problems getting better, a flat out no (IMHO). As @AdamP stated in an earlier post, "I get paid for building working apps, not filing bug reports" and my list is quite long....

Not one of my clients that called me in to "help" with their Forms issues ended up releasing a Forms-based product in the public App Stores, not one. This is not a venue for the reasons and would require a few adult beverages, but you know there are real issues when you have clients maintaining custom Forms repo/forks to apply their patches on top of the daily commits from MS/Xamarin employees and there are public blog articles on how others are maintaining their own CI servers to do the exact same thing.... Do I use Forms, yes, all the time, a lot of DevOps apps for maintaining the cloud-based services for those non-Form public apps, full professional UI designer-based App Dashboards that include OpenGL graphing, etc.. , and we use it a lot to slap live data prototyping views on MVVM/Viper designs, but we do not ship Forms to the public.

In terms of developers at my clients about 65% are native Java or ObjC/Swift devs, guess what, they do not have a CSS option either and it certainly has not slowed down the number of "native" apps going into the Stores each and every day. The other 35% are XAML/C# devs who get peered to, or mentored from, a "native" mobile dev, these C# devs are not looking for CSS either; cleaner appearance during Forms runtime, faster Forms runtime, consistent x-plat appearance, cleaner/faster ways to write renderers, faster build times, better developer tooling,... yes, CSS, no...

TL;DR CSS is just not on my list or on my ears from any of my clients as a have to have for 2017...

CSS3 Flexible Box:

While a FlexLayout would be a great addition, but implementing this top of the current layout manager would a complete nightmare, again IMHO.... the translation of a typical flexbox that defines a header, sidebar, content, action bar, footer wold be an Android speed/overdraw/paint nightmare in Forms once you add any type of complex view matrix inside that content item, or open a v-keyboard, etc.. , I would need to see some code on how it would be done to avoid the current layout issues before I would even type the first <FlexLayout></FlexLayout>.

Thanks to everyone that took the time to share your input. We as the Forms team need to be able to bring these proposal into the forums and have productive conversations with the community, both about what is important in your sphere of work as well as how we can best implement features/changes.

This discussion has run it's course on the proposed API in its current form. As such, I'm going to close the discussion for now.

Based on your feedback, we are going to treat Flexbox and CSS separately.