[Spec] drop AndExpand layout option

[StephaneDelcroix]

Description

The AndExpand suffix on some LayoutOptions is confusing at best, harmful and expensive at its worst.

It only make sense to have a single element (per axis) with AndExpand flag set, and only for a handful of layouts (StackLayout and Grid, mainly).

If a layout contains multiple expandable children per direction:

• it should warn the user
• all but the last one (in the direction) should be ignored

We could also optimize the layouts for these restrictions (reducing the measure for expand items, e.g.).

API

struct LayoutOptions,

Remove or [Obsolete]

class LayoutOptionsConverter

Remove or [Obsolete]

enum LayoutExpandFlag

Remove or [Obsolete]

class View

Properties and BindableProperties

Replace Vertical|HorizontalOptions[Property] by Vertical|HorizontalAlignment[Property]

API	Description
public LayoutAlignment VerticalAlignment	Gets or sets the verticalAlignemnt.
public LayoutAlignment HorizontalAlignment	Gets or sets the verticalAlignemnt.
public static readonly BindableProperty VerticalAlignmentProperty	bp for VerticalAlignemnt
public static readonly BindableProperty HorizontalAlignmentProperty	bp for HorizontalAlignemnt

Add bool Vertical|HorizontalExpand[Property]. An attached BindableProperty would be more suited, as technically the Expand is only valid within some layouts, but the syntax would be harder for the user.

Scenarios

C# Example

var button = new Button();
button.ExpandVertically = true;
button.VerticalAlignment = LayoutAlignment.Center;

XAML Example

<Button x:Name="thing" ExpandVertically="true" VerticalAlignemnt="Center" />

CSS Example

Expansion is not supported in CSS

Backward Compatibility

Minimum API levels: N/A

Breaking changes: this require some modification in user XAML and code. The rule about a single expandable might produce different results than what we actually have.

Difficulty : medium

[dersia]

In general, if we are to introduce breaking changes on xaml like this, shouldn't we take the opportunity with moving to a "new" product and just streamline XAML?

I know, I know, this is sooo much XamlStandard, but here is an opportunity to take. We could also implement the XF-Xaml flavor as aliases with setting those to Obsolete to make the migration easy for net6 and then drop them with net7.

This is just a thought and I am not sure how everyone is thinking about it, but I think it is the right time to do it.

[mattleibow]

Is it not better to use a weight system?

So if I have a stack with 3 items, and each has a VerticalOptions of Fill, then each gets the current height.

If I set them all to be Weight=1, then it overrides the space because it will do a RemainingHeight/3 and then set that to be the height. Even if the first item say requires 90% of the space?

[CarnageMarkus]

@mattleibow Is't that what you describe basically grid ? Grid already supports proportional sizing.
Grid = absolute/proportional/auto sizing
Stack =auto sizing.

[mattleibow]

I was just coming from the Android world. They have stacks with weight and it is pretty cool. However, since stacks are just limited grids, why remove features? Maybe from the sense of simpler calculations - no need to calculate the sizes of all children before laying out?

[jsuarezruiz]

Take a look to the discussion here: #3324