Add a `custom_maximum_size` to `Control`

[AdriaandeJongh]

Describe the project you are working on

A multi-platform tower defense game called Rift Riff with a lot of responsive & dynamic UI.

Describe the problem or limitation you are having in your project

Godot's Control and Container system is top-of-class, modular, fantastic to work with, and I have been able to build any layout I and my graphic designer could dream up… except one thing! While there is a way to define a minimum size of a Control, there is no way to define a maximum size of a Control inside a container. We needed this in our game in a few places, all having to do with dynamic (localized) Label and RichTextLabel nodes growing and shrinking the panel it is part of.

To be more specific, there are several places in our project where we want a panel with auto-wrapping text to be as small as possible, wrapping around the text as closely as possible, but up to a certain size. This last thing is currently not possible without a bit of scripting, because text wrapping relies on setting a custom_minimum_size which stops a label to shrink further down, and setting the custom_minimum_size smaller disables growing the label altogether. The hacky fix we applied (which can probably be cleaned up / be improved) is to create a script that derives from label and toggles wrapping and custom_minimum_size depending on it's size:

Hacky fix to give labels a max_width

class_name LabelWithMaxWidth
extends Label

@export var max_width: float


func _ready() -> void:
	resized.connect(_on_label_resized)
	autowrap_mode = TextServer.AUTOWRAP_OFF
	custom_minimum_size = Vector2.ZERO
	_on_label_resized()


func set_text_and_adjust_width(_text: String) -> void:
	text = _text
	autowrap_mode = TextServer.AUTOWRAP_OFF
	custom_minimum_size = Vector2.ZERO


func _on_label_resized() -> void:
	if size.x > max_width:
		autowrap_mode = TextServer.AUTOWRAP_WORD_SMART
		custom_minimum_size = Vector2(max_width, 0.0)

Here's a video of the desired behavior in action that uses a slightly modified version of the above script so it works in the editor:

Screen.Recording.2025-11-01.at.13.13.05.mp4

This use case was just our use case though. Other users have had other use cases related to the ScrollContainer as per this proposal and this PR, both unmerged at the time of writing, but the use case is similar: people want a scroll container to shrink to the smallest possible size, but also grow up to a maximum size.

This proposal also addresses the same issue as this proposal attempted to address.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

This proposal supersedes #8333 and godotengine/godot#94171 with a more general solution that comes in two parts: adding a new property to controls, and a compatibility breaking change. These two parts can and probably should be separate PRs, but they are conceptually tied hence why I am proposing them in one proposal.

Part 1
Add a custom_maximum_size to Control. Much like custom_minimum_size, this property will be taken into account when a container positions and sizes this Control, also taking grow and shrink directions into account. If a minimum and maximum size are set, both will be respected as much as possible. If the maximum size is smaller than the minimum size, the minimum size takes precedent.

Part 2
Change the auto-wrap mode from requiring a custom_minimum_size to requiring a custom_maximum_size. This is a compatibility-breaking change, but makes a lot more conceptual sense for auto-wrapping to use as a cutoff point. A minimum size can still be set, but is not required.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I don't know C++ nor anything about the implementation of Container positioning and sizing, but the above descriptions should be a good starting point.

If this enhancement will not be used often, can it be worked around with a few lines of script?

See the script used above.

Is there a reason why this should be core and not an add-on in the asset library?

It is a conceptual sister to custom_minimum_size which is already part of Control nodes.

[AdriaandeJongh]

Together with #13456, this PR will allow game devs and graphic designers to make the sexiest popups and text panels possible. Panels with text that always has the right amount of padding around it. Love to see it!

[Piyan0]

This feature would be a game changer for Godot UI system, there's a lot of situation where defining custom_max_size is nedeed.

[KoBeWi]

This shouldn't be in the base Control, it can be added only to specific classes that would benefit from it. Also it could be limited to specific axes. Like for Label only max_width is useful, because of autowrapping. If you specify both max width and height, what will happen if the text is too long? Should it be clipped? Overflow the rect? On the other hand, RichtTextLabel can support both max width and height, because it has a scrollbar. So it has to be decided on case-by-case basis.

A pull request exists for ScrollContainer btw:
godotengine/godot#94171

EDIT:
Now that I've actually read the proposal, I see you already mentioned some of these xd
I still think Control does not need it. Only control subtypes that can grow based on their content, and can handle overflow nicely, should have a maximum size.

[AdriaandeJongh]

Only control subtypes that can grow based on their content, and can handle overflow nicely, should have a maximum size.

I'm not sure? The ones that manage overflow outside of the Control's anchor system (FlowContainer, ScrollContainer, GridContainer) suffer the same issue as I described in my proposal, but practically speaking, every container can grow based on its content, so I don't see why only the ones who manage overflow themselves should get this property.

Regardless, as your voice counts so much more in the Godot community, I've created an additional proposal to add an autowrap width specifically to Label and RichTextLabel: #13568

[KoBeWi]

FlowContainer could have max width/height (depending on orientation) and works like autowrap.
ScrollContainer has scrollbars, so it handles overflow the best.
GridContainer can't handle overflow (it doesn't have any built-in wrapping or scrolling behavior), so it should be replaced or paired with something different. Maybe we could add "max columns" to FlowContainer and it would be a replacement.

Again, I'm not sure how do you want to handle max size in e.g. BoxContainer, other than just clipping the content (in which case you can use a max size ScrollContainer as parent).

I've created an additional proposal to add an autowrap width specifically to Label and RichTextLabel: #13568

That's not really necessary, as it can be implemented as part of this proposal, but ok.

[Jesusemora]

A lot of people are having trouble learning the godot UI with the few options it has now, adding another variable would complicate it even more, because there are more ways in which the properties can interact with each other.
That said, I think this would work better as a new node, similar to how margincontainer works, a control node that limits the size of its children.

[StarryWorm]

I personally believe that #8333 would be a better implementation of this idea. This would bring what Jesusemora is talking about.

This proposal would need to either add this max_size to Control, thus enabling it for subtypes that - as KoBeWi said - might not handle it gracefully (if at all), or it would require adding it to every relevant Control subtype which is a non-negligible development burden in terms of both implementation and maintenance. So it has to either be ungraceful or expensive...
On the other hand, #8333 would natively work for all Control nodes placed inside of it. Now, this does mean some of them would look ungraceful within it, but that becomes a design problem for/by the designer, not a built-in problematic capacity for those ungraceful nodes. In doing so we would isolate the behavior of "constraining the maximum size of a UI element" to a dedicated Container, which is good for both UX and development.

There is one issue with #8333 's implementation though, which is that it does not enable behavior as proposed by #13568. This could be solved by separating the max_height and max_width instead of having them as one max_size property (either in UI or in code). But I don't know how user-friendly that would be.

[KoBeWi]

So I checked the SizeContainer and ScrollContainer max_width and turns out the only way to achieve what this proposal ways (i.e. a Label growing up to a size), #13568 is the only way to do that. That's because when Label has enabled autowrap, its size will never grow, so max size on parent container is useless, because it doesn't know how much it should grow.

[StarryWorm]

Ideally once we have a container that supports a maximum width, we can make the minimum size for autowrap optional if it is within one such container, in which case the Label would expand horizontally (or vertically if that is the direction of your text) as much as possible before wrapping.
#13568 could definitely be another way of achieving it though

[AdriaandeJongh]

So I checked the SizeContainer and ScrollContainer max_width and turns out the only way to achieve what this proposal wants (i.e. a Label growing up to a size), #13568 is the only way to do that. That's because when Label has enabled autowrap, its size will never grow, so max size on parent container is useless, because it doesn't know how much it should grow.

Just to be abundantly clear: #13568 is not the only way to achieve this if we also break compatibility and change that autowrap no longer uses custom_minimum_size, which makes a lot of sense conceptually. This is why my proposal has two parts to its implementation.

[StarryWorm]

We could do it in a non-compatibility breaking way by introducing it as a special behavior if and only if it is a direct child of a SizeContainer (or whatever implementation we land on for a container with a max size).
None of the old behavior would be changed, hence compatibility is preserved.

[AdriaandeJongh]

a special behavior if and only if it is a direct child of a SizeContainer

I fear hacks like this won't fly with most contributors 😅 but sure, maybe some sort fallback can be implemented for labels and rich text labels, eg. auto-wrapping first checks the maximum width, then the minimum width, and otherwise simply doesn't work.

I'm still not sold on introducing a new type of node, such as SizeContainer if it can also be part of control in a generalized way, or as a more specialized field such as suggested in #13568. I've also always been annoyed with MarginContainer having to be a separate node. It just adds to the scene tree and makes it less readable. idk.