i’m on Unity 2021.3.2f1 and in UI Builder for UI Toolkit.
Example
lets say you have a Visual Element with 100% height, so it covers full screen size.
Then you have two child visual elements, where one has 50% height. Now set the
second child to 100%.
Outcome
The second child inherits size from the parent, but does not take into account that
already 50% of the space is used by the first child. So the second child will have a
final size of 100 percent screen size again, ignoring and overflowing the first child
element. This also happens when giving top and bottom coordinates for position.
Expected
100% should always relate to the parent element, and take the space of other child
elements of the parent into account, when calculating final size. Applied to the above
example, this should result in child 2 taking up only 50%, which is 100% of he left-
over space in the parent container. This is also how it works in CSS for nested divs.
The UI Builder is already great, but the above is kind of a showstopper that leads
devs into applying unclean workarounds.
Not by default in CSS, divs are by default “display: block” so both child together would have 150%.
If you use flexbox in CSS then child 1 would use 33.33% and child 2 would use 66.66%.
If I remember correctly, unity and CSS have different default values for flex shrink and grow.
Thanks for pointing out that url, i missed this before.
I will file a bug Report for another issue i discovered, but on the initially reported one i have to pull back,
as i have tested what user runner78 said in a PoC and it turns out that he is correct, CSS shows the same behaviour.
You are correct and saved unity devs a false error report, as i tested this in a PoC and was amazed to find out
it also overflows in CSS (due to the reasons you named). I had remembered this incorrectly, even i use CSS
since years now.
It would be nice if the input system is extended with more .CSS properties, currently it is kind of a very light version of CSS (seen in this USS properties list: https://docs.unity3d.com/Manual/UIE-USS-Properties-Reference.html ), with more supported properties, we could fix things like the initial reported behaviour more easily. Alternatively, unity already gone an individual path by choosing .uss instead of .css, so if you go individual, maybe then take individual approaches to make the workflow more userfriendly, like making the ui-builder and its elements react like the user expects to, not like CSS wants to (but with the latter you would then clearly leave the CSS way of doing things). Option one seems the best approach imo, as with more properties, we have more control and can get the GUI Elements to behave like we expect.