The GuiObject.SizeConstraint property [1] [2] is a simple and convenient way to maintain aspect ratio and equal metrics across both 2D axes when using UDim values with Scale.
I find it useful as it lets me quickly and intuitively create complex layouts exclusively in Scale without needing to resort to things like manually calculating “X to Y” conversions or writing code that achieves equivalent results at runtime. It also lets me avoid using UIAspectRatioConstraints which are less intuitive and involve more work to set up (creating an Instance and setting multiple properties).
Unfortunately, SizeConstraint is only implemented for the GuiObject class’s Size property – not for Position, or for any properties of UIListLayout, UIGridLayout, UIPadding, etc. UIAspectRatioConstraints are more widely supported but still aren’t able to solve all problems.
Padding is one use case which is difficult. There is no way to do equal Scale padding on both axes using UIPadding or the padding properties of Layout Instances. To achieve equal padding without writing code or doing math we have to ditch the constraints/padding properties entirely and just manually use transparent Frames (with UIAspectRatioConstraint or SizeConstraint).
ScrollingFrames are another problematic use case:
The engine applies UDim Scale values to the canvas size of the ScrollingFrame instead of its GuiObject/absolute size, meaning as the ScrollingFrame’s canvas expands (e.g. due to adding new items to a list) the size of anything using UDim Scale along the axis that is expanded will also increase. This makes naively using Scale for UDims within a ScrollingFrame a bad idea.
For GuiObjects, SizeConstraint remedies this problem quite easily: we can just set it to the axis that is not being expanded and now no matter how big the ScrollingFrame gets the GuiObjects will always stay the same size.
e.g. for a vertical ScrollingFrame with a list we can set the SizeConstraint of all the list items to RelativeXX and now they won’t change size vertically when the ScrollingFrame expands or contracts when items are added or removed from the list. But as mentioned above we can’t do this for padding, or for the cell size of UIGridLayouts (unless we want to manually put every unit of these things into the layout ourselves).
So I would find my workflow significantly improved when working with UDim Scale if I were able to apply SizeConstraint in any place where a UDim value is present. I am including both UDim2s and plain UDims in this request, as even single UDims always occur in the context of a particular axis and I would like to be able to choose which axis to “read” from separately from choosing which axis to “write” to.
The solution in engine could just be something like adding an “[…]SizeConstraint” property to complement every UDim/UDim2 property (or perhaps in bulk for certain Instances with many properties such as UIPadding, to avoid unnecessary clutter). Maybe it should be renamed though… like PositionConstraint when it’s applied to Position.
Other solutions to this problem that don’t use SizeConstraint properties might be okay, but I find SizeConstraint to be particularly convenient and easy to use as opposed to the newer constraint Instances, and I want to keep that same level of usability.