Bug Child selector don't work properly

Unity 2021.3 LTS

Style:


Layout




As you can see red background properly applies to direct child

.unity-toggle

BUT at the same time it also applies to the all nested

.unity-toggle

which is wrong.

Web example:
As you can see child selector works properly and change size and border color only on direct childs

.VNLkW 

of

.P1usbc 

 

@uDamian any info about that? Is this fixed in future unity versions, if yes will it be backported to 2021 LTS version?

 

Your other toggle is also matching the accessor:

 

I think the line is marking the #repeat-preserve-points toggle.

 

I think I know why it happens. The foldout toggle is affected because it's a direct child of the foldout. The preserve points toggle is affected because it's inside the foldout's content container. Elements in the the content container are meant to be treated as direct children; after all, if you add other elements to the foldout, they will be added to its container as well.

You may be able to solve your problem by using the .unity-foldout__toggle class instead.

 

They're matched properly they're foldout toggles and colored properly, this is working properly. The issue is simple toggle (not foldout one) which is not direct child.

 

Ok, I looked at the question mark. I think that oscarAbraham has explained the problem correctly.

 

Well, they're childs of

#unity-content

in resulting hierarchy as we can see and not direct

Foldout

children's, as result it's a definitely bug, because it raises child selector inconsistency, as it start to mix UXML hierarchy childs (where all the Foldout utility wrappers invisible) and final hierarchy (where all Foldout wrappers visible). In the end only final hierarchy should be chosen for USS calculations, as it works in HTML\CSS land.

Yep there is many ways to solve that, that's not a problem, but child hierarchy inconsistency is the problem which needs not be solved on Unity side

 

I don't think that's a bug. The contentContainer doc says that "child elements are added to this element", implying that elements inside it are considered children.

Personally, if it were just for my personal use, I'd prefer that it worked the way you say. It'd give me a bit more control over styles; even though, like you said, there are ways around it.

The thing is, I can see why they would make it the way it is now. I'd probably make it that way myself if I worked at Unity. Their product must work for people that are just making stuff on the builder, that only think about UXML and USS. They shouldn't have to know that a foldout uses a separate content-container internally. The manual page for child selectors even uses UXML for its examples.

Even if you remain convinced that it's a bug, there is nothing that can be done now. Unity can't change how it works because it could break a lot of projects that depend on the current behavior.

 

Docs doesn't conflict which situation I've described, Children doesn't mean only direct children, 5 level deep childs - still childs But I understood your point.

Well builder shows you proper hierarchy you see internal toggle, content container etc

Yep that's the sad thing in all of this

 

I'd call 5 level deep children "great-great-great-grandchildren".

 

Yeap, I also think this behaviour is wrong. Selectors (or any rule, because they're rules) should work consistently; even if this will be affect old projects, it should be changed.

 

Still want to hear anything from UI Toolkit team @benoitd_unity maybe?

 

I'm also interested in this, because I think I'm seeing the same issue.



I have one USS file for all my custom controls, in there, there's a section like this:

Code (CSharp):

1. .terrain-toolbar-dropdown-button-item-container .unity-scroll-view__content-container {
2.     flex-direction: row;
3.     flex-wrap: wrap;
4. }
5.  
6. .terrain-toolbar-dropdown-button-item-container .unity-scroll-view__content-container > .tile-type-preview-element {
7.     margin-right: 3px;
8. }

1. This is the terrain-toolbar-dropdown-button-item-container.
2. This is the unity-scroll-view__content-container. In the debugger I can see that the flex-direction and flex-wrap is being applied, so the selector itself works as expected.
3. This is the tile-type-preview-element. However, those elements are not styled, but they should because they are direct children to the unity-scroll-view__content-container.

I'm currently trying to figure out, why they are not being styled.

In addition to @oscarAbraham: In my custom control ToolbarDropdownButtonElement I'm overriding its contentContainer and set it to the Unity ScrollView. So when adding elements, i simply use .Add on the ToolbarDropdownButtonElement so those children's logical parent is. the ToolbarDropdownButtonElement, but in the hierarchy they are children of the ScrollView-ContentContainer.

Could that be the issue here?

If so, it's horrible, because as @eizenhorn said, the final hierarchy must decide if selectors are applied or not. Otherwise it's super hard to guess, which is the "correct parent" for an element.
I was expecting that it works like in HTML/CSS, where the final hierarchy decides about the selectors and not some "logical parenting stuff".

 

Ok, I just tried it out like @oscarAbraham said.
I added a class to my ToolbarDropdownButtonElement and updated my USS to this:

Code (CSharp):

1. .toolbar-dropdown-button-element > .tile-type-preview-element {
2.     margin-right: 3px;
3. }

And... now it works!

This is somewhat super strange, because it really uses the logical relationship and not the final hierarchy for the selectors. This is really not what I'd expect when working with such a system.

In my opinion, I see it like @eizenhorn: It's a bug.

In this case, you always need to know what the logical parent is and not the hierarchy that you use in web development. Also, the UI debugger does not show anything about the logical parent relationship.

 

Sure. Case number with link to this forum thread: IN-24849

 

Does Unity QA actually checked that? Because based on their response - they’re not. If foldout override content container - why USS apply style to foldout first child toggle itself? Isn’t Unty devs just answered that Foldout overrides content container and should apply styles only to that? As result we see it works NOT how it should. It works INCONSISTENT. It works NOT how any developer expects it to work. I’m not even speaking about how any web dev expects it to work, I’ve provided comparison in first post.

 

And this is a big issue and question to Unity - why someone even decided to do that at first place? When UI team using CSS\HTML as reference, when we have example for years how it's working across the world, Unity decided to reinvent their own wheel?

As I said - a wheel

I didn't see any reasonable argument for that. It's like have Angular module for some control like Angular Grid, Select2 etc. which contains own hierarchy and instead of using real hierarchy for styling when user want to change control styles from their wrapper through hierarchy it's applied styles "magically" to some "virtual" hierarchy you should know in advance (of course this is exactly what everyone likes - magic, hidden unexpected stuff. For may years people never blamed unity for hidden, magic, unexpected behaviours ) Anyway after that response I see that Unity wouldn't fix that, and doesn't matter how real users use this solution and how it works in the HTML\CSS that Unity using as reference, thanks for response and have a nice day