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
- Required SpriteMask class (ID 331) is stripped when "Strip Engine Code" is enabled
- “Maximized serialized file backup not found” error is thrown when minimizing a window in a newly opened project
- Build stack trace contains invalid lines when building with IL2CPP using scripts with delegates containing generic types in the signature
- Entities Systems window has a “Show Full Player Loop” dropdown which does nothing when clicked after enabling “Show Full Player Loop”
- Entities Hierarchy Search “Show/Hide” button’s Lens Icon is blurry when the Editor is on an external monitor
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.