[Enhancement] Add Maximum(Width/Height)Request to VisualElement

[rdaniel0]

Description

It would be nice to have counterparts to the existing Minimum(Width/Height)Request properties.

Maximum(Width/Height) should do the following calculation:
VisualElement.(Width/Height) = Max(Maximum(Width/Height)Request, VisualElement.(Width/Height));

Expected Behaviour

The VisualElement should select the maximum size if it's measure is smaller; otherwise grow as the measure requires.

[PaulVrugt]

Are we really doing this? There is already lots of confusion about the minimum(height/width)request properties. I think it's better to spend time in introducing a min and max width/height which does what people expect it to do (like min/max height/width in css) instead of introducing even more properties that people will misunderstand.

Better yet, this proposal seems to be what people would expect the minimumheightrequest property to do

[rdaniel0]

I agree with you about the expected behavior of the existing property being backwards, and now this one would be as well.
However, the existing confusion has already been talked about in length in the Xamarin forum.

We can't know for certain how many developers have implemented the existing property, knowing the actual effect it has on their layouts. So any breaking change would have to be done through making the existing property obsolete and find a new name for both, and make it clear to devs that this breaking change has happened.

I'm quite happy settling for what I proposed above. However you are more than free to make a new issue about this with your own suggestions. (And would be good to link to this issue from there)

[rraallvv]

I'm stuck trying to make a cell in a grid to have a shrinkable size, this property would be very helpful for that use case. In a grid for instance it would separate two columns by a prefixed space, and only if the size of the elements in other columns is big enough it should shrink all the way down to zero, so that the grid spacing would be the only space left.

[HelenMamalaki]

Any progress on adding a true max/min height property? I don't care what it's called at this point since all discussions seem to end around the 'correct' naming. This features has been requested both directly and indirectly over over again* since 2016, what is the hold up?

*and I mean over and over again:
#2887
#2000
#2536
#2887
https://bugzilla.xamarin.com/show_bug.cgi?id=44738
https://forums.xamarin.com/discussion/84885/obsolete-minimum-width-height-request
https://forums.xamarin.com/discussion/66049/does-minimumheightrequest-work-at-all

https://stackoverflow.com/questions/37662318/set-minimum-button-width-in-xamarin-forms-or-ios
https://stackoverflow.com/questions/64227931/how-to-set-min-width-or-bigger-in-xaml-of-xamarin-forms
https://stackoverflow.com/questions/64685571/xamarin-forms-how-to-set-the-min-width-of-a-label-on-ios

[profexorgeek]

I came across this issue while working on docs for the VisualElement properties. I spent some time digging into the functionality of the minimum request properties and I believe the existing functionality may accomplish what is being asked. Cliff notes:

• If a control does not specify a MinimumWidthRequest the minimum is effectively the actual width (technically it is ignored and the actual width is used). In other words, controls without a MinimumWidthRequest cannot shrink.
• If a control has a MinimumWidthRequest but does not specify a WidthRequest the width may smaller than the minimum and cause undefined behavior. So always specify a WidthRequest when using MinimumWidthRequest
• Some layout options such as "Fill" may override the min/max. Use "Start" or "End" as your layout options.
• The minimum request properties currently do not work within the context of a grid. They are competing relative layout systems. However, this may be fixable and a new issue has been raised to track this here: [Bug] Grid is not correctly using MinimumWidthRequest with calculating Auto Cells #7303

So by my tests and understanding, setting a MinimumWidthRequest and a WidthRequest effectively give you a minimum and a maximum. Updated documentation is here:

https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/controls/common-properties#minimum-request-properties

[MappingSteve]

@profexorgeek

controls without a MinimumWidthRequest cannot shrink.

More precisely, they are the last to shrink: controls with specified minimums will be shrunk first.

always specify a WidthRequest when using MinimumWidthRequest

90%+ of the time, that is what one doesn't want to have to do. The frequent complaint re lack of a "true" Minimum option is a desire to let a control seek its desired size, but to not let it fall below a minimum. This means not setting a fixed Width.

WidthRequest doesn't act like Maximum would. Rather, it forces a control to consume that space (if available), whether it wants that space or not. This is non-adaptive non-responsive behavior.

In summary, it isn't possible to get the desired behavior:
"Let a control seek its desired size, but don't go below Minimum nor above Maximum".

[MappingSteve]

@rdaniel0 The formula for Maximum should be MIN(Calculated, MaximumRequest). That is, it would limit the size. Your MAX formula would always force it to Maximum - a pointless option to have.

@PaulVrugt - almost certainly, what the issue intended, and all the up-voters also mean, is a "true" Maximum option (and a "true" Minimum option to go with it), not another misnamed option.

[PaulVrugt]

@MappingSteve that's exactly what I said I'm my comment. The properties should work the same as they do in css. That's also what I proposed in #2536

[bPoller2810]

are there any news since the last 2 years?
every developer on some point needs some behaviour like this and this is still not a thing in XF?

[nznaza]

Any progress on adding a true max/min height property? I don't care what it's called at this point since all discussions seem to end around the 'correct' naming. This features has been requested both directly and indirectly over over again* since 2016, what is the hold up?

*and I mean over and over again:
#2887
#2000
#2536
#2887
https://bugzilla.xamarin.com/show_bug.cgi?id=44738
https://forums.xamarin.com/discussion/84885/obsolete-minimum-width-height-request
https://forums.xamarin.com/discussion/66049/does-minimumheightrequest-work-at-all

I wonder how many times this has been asked in multiple forums, because apart from the cited list, #1862 (and God knows how many others) makes reference to basically the same idea, and the response pretty much ranges from a flat no (and a very stackoverflow reason of why (Using (Width/Height)Request is not a solution)), to radio silence

The only sparks of real communication are the label/Project updates, but that's not a proper answer and doesn't mean we are getting this functionality.

I know renaming the properties is a breaking change (but a more appropriate naming scheme, should be pretty easy to fix, the only ones affected we should be active project developers), but this option is the next best pick.

Can we get an elaborated answer about the status of this, please? @samhouts @kingces95

[jfversluis]

Hey everyone, thanks for all the engagement here and sorry that this somehow didn't catch our attention. As already pointed out, this is going to change heavily in .NET MAUI. I would suggest you go check out how it works there and if you still would like to see changes, make suggestion on what you would like to see.

With Xamarin.Forms now being in maintenance mode we're not going to change anything about it here. I did put this issue on my list so we can go through all the suggestions and ideas here and see if and how we can address them for .NET MAUI or to which extend we might already have done that.

[jedusei]

Hi everyone! I recently encountered this obstacle and came up with a solution in the form of a custom ContentView class: https://gist.github.com/jedusei/c74df567822c46e70c9e1931be9bfbc1
Just thought I'd share this here for anyone who might need it 😅.