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
- Texture generator reference image fails despite valid size
- Agent mode can enter infinite execution loop
- AI Gateway responses contain duplicated sentences
- Texture 2D asset is created when promoting a generated Cubemap to a new asset
- Unable to copy multiple paragraphs from Assistant responses
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.