Style Editor and StyleSheets - Unpredictable Styling behaviors based on sibling hierarchies of Selectors

[xnaxgame]

In the new Style Editor BETA feature, which brings CSS-like styling over to UI editing inside studio, I’ve noticed an annoying behavior related to how styles are prioritized.

Here’s an example of the behavior:

In this stylesheet, we have:

• A global tag .Colored, applying an YELLOW background color to all elements with such tag;
• The same tag .Colored, applying only to Frames, a RED background color;
• A nested tag .GreenColored, inside the global tag .Colored, overriding the parent’s background color style to a GREEN background.

HOWEVER, this information is not enough to determine the actual behavior, making it unpredictable.
There are two result possibilities:

*The text is purely for explanation purposes, focus on BackgroundColor of each element
The Nested tags (or Parent-Child tags) have a well-defined hierarchy: On conflicts, the Child will override behavior from the Parent.
However, that does not happen with siblings: since the tag Frame .Colored is not ancestor nor Descendant of the global tag .Colored, the style is unpredictable and it keeps the changes of the newest-created tag. Which means, the order of creation will dictate what the behavior will be, and not nested logic, making this a critical and dangerous bug, where developers cannot assure the result state of their stylesheets.

Expected behavior

The current StyleSheet behavior already follows the oder of precedence: Class > Tags > Modifiers > States > Name, where Class is the least preferred and Name is the most.

However, StyleSheets FAIL to consider the specificity of selectors, which is the preference over the whole selector (example: Frame.Colored over .Colored, Frame.Colored is more specific since only frames with the .Colored tag are affected).

To learn more about specificity in CSS, see: Article about CSS Specificity

Considering that Frame.Colored is more specific than .Colored, the expected behavior to the example given previously would be:

This should be DEFAULT behavior, and always happen despite the order of creation of the specifiers.
This should be default because, if it was not, the specificity Class.Tag would be literally useless, since .Tag would always override it.

With that, implementing Specificity in the same way CSS does is crucial to have actually predictable style sheets.

A private message is associated with this bug report

[xnaxgame]

Note that this happens to any conflict in different selectors, does not need to be the same tag at all, just be two selectors conflicting on the same property(ies).

Example:

vs

In a TextLabel with both the .BorderedBypass and .BypassResult tags, it will conflict between both BackgroundColor3 properties and produce and unpredictable behavior as mentioned in the bug report.

[ThunderBolt5140]

Thank you for reporting! We will look into fixing this so that any newly added global Tag StyleRules under the Tags folder will have lower Priority than more specific UI Element StyleRules.

In the meantime, you can work around this by changing the StyleRule.Priority property in the PropertiesPanel. Make sure that the StyleRules that are global tags have lower Priority values than your UI element StyleRules, so that your UI element rules will always override the tag rules.

Edit: This has now been fixed in the Style Editor, so any newly created global Tag StyleRules will have lower Priority than Class StyleRules. Additionally, global StyleRules that do not fall under Tags or Class StyleRules will have even lower StyleRule Priority. Note that this will not automatically update existing StyleRules.

[xnaxgame]

Thank you for your support and for the work around tip! I’ll start using that until we get an update on StyleSheets.