Hi guys, i t drove mad until I realized the order of the uss class has nothing to do with the one in uxml but with the order of the class in their file as you can see below
Is this intentional or a bug?
Hi guys, i t drove mad until I realized the order of the uss class has nothing to do with the one in uxml but with the order of the class in their file as you can see below
Is this intentional or a bug?
Intentional. See the manual on selector precedence here: https://docs.unity3d.com/Manual/UIE-USS-Selectors.html “If two selectors are equal within the same style sheet, the selector that appears last in the file takes precedence.” (and the selectors are equal in value because they both select on a class)
Thanks so much for the response and help Florian, I’ve should have find myself but as it super contra intuitive (just checked that in html it works in the inverse mode, as I beleived) I thought it was a mistake
I would like to see the rationale after this decission, as it makes almost impossible, as far as I understand, to create reusable frameworks (bootstrap-like for instance) as the user nevers knwows in which order have been created. I’m trying to figure out an utility that substitutes classes before the runtime combining them in the typical order. This wouldn’t be difficult but changing the classes during rutime would be a nightmate to orchestrate this way…
Hi Genom, my pleasure!
It’s the same as in HTML and CSS – see here: Cascade, specificity, and inheritance - Learn web development | MDN “If you have more than one rule, which has exactly the same weight, then the one that comes last in the CSS will win.” As I already work with web technologies, I find it intuitive since it’s mostly a subset of CSS (with a few exceptions as described in the Unity document I linked above).
Are you sure about that? Every HTML spec I’ve seen has also had the order in the CSS file be what determines final resolution. For the example USS you show, assuming it was instead CSS, .yellow would always take precedence over .green if both were applied to an element, regardless of the order they’re specified on the element.
In both CSS and JavaScript land (And, presumably the browser backend), the class list is not an ordered array, but more of a hashmap, with classes acting more like unordered switches on an element - the element has both green and yellow applied, but the order doesn’t matter. This is probably because early engines just read the class attribute as a flat string, and it eases up on JS operations as you can just add a class to the end or delete a class from the middle of this string without having to constantly be aware of the order. The .classList JS property wasn’t always there, early sites did have to just mangle a big string to add and remove classes.
In addition, in CSS (and USS) a selector of .Class1.Class2 { }
and .Class2.Class1 { }
both act the same, and an element must have both .Class1 and .Class2 defined for either rule (and both) to be applied to it, regardless of order.
Just to prove that USS order matches CSS order, drop the below in a .html file and see that all three divs have blue text despite the class order being different each time.
<!DOCTYPE html>
<html>
<head>
<title>Test</title>
<style>
.red {
color: #FF0000;
}
.green {
color: #00FF00;
}
.blue {
color: #0000FF;
}
</style>
</head>
<body>
<div class="red green blue">Blue is defined last.</div>
<div class="green blue red">Red is defined last.</div>
<div class="blue red green">Green is defined last.</div>
</body>
</html>
The UIElements backend runs off of a modified and simplified HTML+CSS engine, so I’d be surprised if it varied from HTML+CSS at such a core level.
Edit:
That’s actually part of the beauty of this particular mechanism. With Bootstrap, you can style a button with
<button class="btn btn-success">Success!</button>
or
<button class="btn-success btn">Success!</button>
and get exactly the same result. The Bootstrap team ensured that .btn-success was below .btn on the CSS style sheet so that all they had to do was change the background and foreground colours. If CSS and classes worked the way you were expecting, having ‘btn’ second in the element would override those colours back to the defaults, making the button look like the default and essentially making btn-success do nothing.
Damn! I really need to check my css concepts, somehow I assumed that last class rules over the first one (in the element like class=“green yellow”) I wonder if this is the same in sass I’ll check it too.
Thanks a lot Florian!
Hi! thanks for your response as well, I checked before and both of your are right (I probably didnt refresh the browser when I was doing the same in html).
About your comment, in c# I’m not used to this behavior, it does not matter where you have the code, the important is the order you call it. As I am not expert in css and normally I just use an existing framework I assumed that the order of the class in the html element was the rule.
Anyway, I was wrong : D I will adapt to that way
thanks again!
Something that made this intensely confusing for me is that reordering the stylesheets in the UI is possible, but it does not seem to reorder them in the UXML, so if you are trying to adjust precedence between files it is very confusing. You will have to reorder them in the UXML file.
I would really rather use @import
!