Relative units for control sizes

thevortexcloud commented 2 months ago

Is your feature request related to a problem? Please describe.

Currently Avalonia only supports absolute units for control sizes. EG

<Button Width="200"/>

This is fine for simple layouts, but is not very useful for responsive layouts that automatically resize. Currently you instead have to rely on what ever panel the control is in automatically resizing it's children properly to achieve the desired size. However if you want a size that is less/more than what the panel thinks the control should get, you are then stuck using an absolute unit for the width/height/margins. Which does not scale well with various different screen sizes.

Describe the solution you'd like

Avalonia should support multiple different units in XAML. For example:

cw which allows for specifying a percentage of the parent container's width. EG
```
<StackPanel>
  <Button Width="80cw"/>
</StackPanel>
```
Would make the Button 80% of the width of the StackPanel.
ch would be similar to cw except for the container height.

For a root control, the relative size would be relative to the view's size.

The calculated value of the unit can't be known at compile time (as it will vary by several factors, such window/screen size). Instead it would need to be calculated based on the value the unit is relative to at runtime. As such it would also need to be recalculated every time the thing the unit is relative to also changes.

For backwards (XAML) compatibility, it can be assumed if no unit suffix is provided, then it should work exactly how it does today with an absolute unit. I am not clear what mitigations could be done for code behind scenarios.

Once support for this has been added it also opens up the door for alternative absolute units as well. But in my opinion, those are far less important than relative units.

This would more closely align Avalonia with how CSS does layouts and make responsive layouts significantly easier to achieve within the current framework.

Describe alternatives you've considered

I believe(?) it would be possible to achieve a lot of the same functionality by making some special panel to handle all the layout adjustments with an attached property on each child control to specify the relative size. This would be more in line with the typical "XAML way" of doing things. But for a fully responsive UI it would likely result in a lot of nested panels.
You can achieve somewhat similar functionality right now by using a Grid with Auto/* sizing. However you will still run into responsive layout problems if you need something that is not exactly Auto/*.
A converter could also be used that is bound to the parent control bounds to calculate some sort of scaling factor amount/width/height that changes with screen/container. But writing that in XAML on every control that needs the relative sizing would be rather verbose.
Avalonia already has the OnFormFactor markup extension which is used to differentiate between different screen form factors. However it is lacking a lot of information needed to make a responsive UI. EG screen orientation, container size, etc. As such in its current form it is more of a device class indicator rather than anything to do with screen information. To get the functionality required for a proper responsive UI, this markup extension should either be rewritten or a new one should be added that provides more useful information.

Additional context

This is a follow up from the discussion in https://github.com/AvaloniaUI/Avalonia/issues/16949. In the specific scenario outlined in that discussion, dozens of container queries would have to be made to deal with various different screen sizes. Whereas with relative units, that number would significantly decrease as it would be possible for things to automatically adjust on their own without an explicit case being specified by the developer.

timunie commented 2 months ago

I think there may be more CSS units to port. Would be a useful addition to ContainerQueries at some point.

thevortexcloud commented 2 months ago

I don't disagree. But I was also trying to keep the initial features somewhat minimal. But em would also probably be useful.

That said even without container queries this would help a lot. You can get pretty far using the existing layout controls as long as you don't fiddle with any fixed sizes on things. But that's not always an option.

timunie commented 2 months ago

Yeah we may not add all the units at once, but keeping that API in mind would make it more easily to add units later on.

AvaloniaUI / Avalonia