Search Issue Tracker
By Design
By Design in 2023.2.X
Votes
0
Found in
2021.3.28f1
2022.3.5f1
2023.1.4f1
2023.2.0a23
Issue ID
UUM-42531
Regression
No
Style of elements doesn’t change when overriding style in UI Toolkit
How to reproduce:
1. Open the user’s attached “UIBug.zip” project
2. Enter Play Mode and observe the square on the right side
Expected result: The square is red
Actual result: The square is white
Reproducible with: 2021.3.28f1, 2022.3.5f1, 2023.1.4f1, 2023.2.0a23
Reproduced on: macOS 13.4.1 (Intel)
Note: reproducible in the Editor and Standalone Player (macOS)
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 Import Warnings are obscured by other Terrain Layer options in the Inspector
- Burst Inspector middle divider is jittering when resized with the Burst Inspector window docked
- JsonConvert conversion fails trying to call GetCallbackMethodsForType when [OnDeserialized] is used in a class
- Different text alignment in the column header in Entities "System" window
- Objects with Universal Render Pipeline/Particles/Lit shader are always lit up when changing their Rendering Layer Mask
Resolution Note:
The USS classes specificity behave similarly to CSS classes. The order of the class list in the element doesn't have any impact on the specificity. However, the order of the classes in the USS file do have an impact, the last class having more specificity (everything else being equal).
In your example, the "make-me-white" class is more specific since it is defined after "make-me-red".
Resolution Note (2023.2.X):
The USS classes specificity behave similarly to CSS classes. The order of the class list in the element doesn't have any impact on the specificity. However, the order of the classes in the USS file do have an impact, the last class having more specificity (everything else being equal).
In your example, the "make-me-white" class is more specific since it is defined after "make-me-red".