Search Issue Tracker
Won't Fix
Won't Fix in 2023.3.X
Votes
0
Found in
2022.2.15f1
2023.1.0b12
2023.2.0a9
2023.3.0a3
Issue ID
UUM-33143
Regression
No
The expansion behavior is not the same as in CSS when used with VisualElements
How to reproduce:
1. Open the attached project "UIToolkit Styles Bugs.zip"
2. Open Assets/Expansion.uxml
3. Select "#expand-to-child-size" in the UI Builder Hierarchy
Expected results: VisualElement's size is the same as its child
Actual results: VisualElement's size is not the same as its child
Reproducible with: 2020.3.47f1, 2021.3.23f1, 2022.2.15f1, 2023.1.0b12, 2023.2.0a9
Reproducible on: Windows 10
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- "Shader warning in 'Hidden/Light2D': implicit truncation of vector type" is thrown when building Universal 2D template
- AI Assistant breaks compilation of packages using System.Runtime.CompilerServices.Unsafe via auto-referencing
- Unity Hub checks the "Documentation" module by default on the 6.4 and 6.5 streams despite that it was unchecked with the previous installs
- Shortcut that toggles between Dopesheet and Curves Views in the Animation Window's Timeline is mislabed
- Property List Items Overlap onto the Property List's top edge when scrolling through a long Property List
Resolution Note:
Thanks for the report. While we try to stay as close as possible to CSS, we don't guarantee exact same behavior and defaults.
In this case, there's no bug, other than inconsistency with CSS perhaps. The 50px padding of the parent is forcing the #expand-to-child-size to be 0 height. Without that padding, the #expand-to-child-size would indeed expand. The shrink=0 on #expand-to-child-size only applies when being flex-layouted with other siblings that wish to take up more space than available.
We may address this inconsistency with CSS in the future, but we now also have to contend with potentially breaking existing USS uses in existing projects that now rely on current behavior. It's not a simple as fixing this one bug.
Resolution Note (2023.3.X):
Thanks for the report. While we try to stay as close as possible to CSS, we don't guarantee exact same behavior and defaults.
In this case, there's no bug, other than inconsistency with CSS perhaps. The 50px padding of the parent is forcing the #expand-to-child-size to be 0 height. Without that padding, the #expand-to-child-size would indeed expand. The shrink=0 on #expand-to-child-size only applies when being flex-layouted with other siblings that wish to take up more space than available.
We may address this inconsistency with CSS in the future, but we now also have to contend with potentially breaking existing USS uses in existing projects that now rely on current behavior. It's not a simple as fixing this one bug.