I love this update, I wanted to know if there’s a way to select all descendants of a tag and modify them without specifying a class?
there is a hacky way to do it. you put a surface gui in front of the camera with elements you want to blur and then the blur applies to that too
I haven’t had the chance to play around with this yet, so I’ll be asking this question here: is this available for use in Plugins?
Yes, this is available in plugins, though currently Styling will not apply if the user is not opted into the UI Styling beta feature.
1 Like
Does .TagName >> GuiObject work for your use case?
1 Like
@BackspaceRGB Yes, you can rename the Design folder or nest it in other folders. When creating new StyleSheets through the Style Editor, the logic is to parent the StyleSheet under the same parent as other StyleSheets.
1 Like
This is on our roadmap! I’d like to add something to the “Tags” section for a property if it supports styling
My text-based language for Roblox StyleSheet’s now has a devforum post: Text-Based StyleSheet Language - RSML
3 Likes
I haven’t given my thoughts about this feature yet (because I think my English knowledge is getting worse as my brain/mind does too), but this is a pretty awesome new feature, and I’m impressed by how quickly affected UI elements update as I make changes to stylesheets and create StyleLinks! Unlike some “beta features” and other additions that feel too minor to warrant an announcement topic., this feels like a major new feature that could help developers design UI that can be quickly re-themed for seasonal events and light/dark modes.
Personally, I know this will (or would, if I actually made anything nowadays) help add customization to my Windows-esque windows and their UI elements. If I make a separate stylesheet for each UI element (which references theme tokens) and include a StyleLink in each that points to its stylesheet, they could be recolored by the player like older Windows versions. (
Oh, why did Windows move away from the flexible, very colorful “classic” theme?)
Before I considered moving forward and making the stylesheets, I thought about a potential shortcoming of this feature; Does it account for “nested stylesheet references”, where, say, multiple Frames link to different stylesheets? I opened a second RBXL and made an ugly example GUI that does this, and I can safely say that it does!
Here, I created two
StyleSheets that both modify TextButtons, then linked them to two nested TextButtons. Like I hoped, the inner style sheet took priority, changing its background color. Interestingly, the inner style completely overrides the outer one instead of inheriting its scaled, white text, so if you want to do this with your own GUI, keep in mind nothing’s “inherited” once Roblox reaches an instance with its own StyleLink.
This isn’t a bad thing, and I hope it isn’t actually a bug. I actually prefer having to redefine properties for different UI elements, which could be nested within anything else, which would make its exact appearance unpredictable if an ancestor modified one of the descendant’s properties.
I agree with other developers, though; I think UI styles need support for tweens/basic smooth animations/property edits. At the moment, a developer would have to script any animations themselves, or just accept the instant changes when clicking on or hovering over a button, for example. I think this would complement the recent HapticEffects since neither would require any code.
Also, I wish it was easier to reset multiple instances to their default values so they can be styled. I haven’t started the process yet, but I already know I’m going to have to select each instance and manually right-click some of their properties to reset their values, but there should be a way to reset most properties (other than position/anchor points/rotation/size) in bulk so UI made before this cool feature arrived could be updated faster to use it.
I know I could write Command Bar code to iterate through everything and reset their values, but I still have to know which properties exist for each GUI element before trying to reset them (unless I wrapped each “reset” command in a pcall but that feels “hackish”).
I guess it won’t take that long to do it manually, so it’s okay. I still think this is a great and useful new feature, though; Good job, Roblox staff/developers! 
2 Likes
Another crash here; can replicate it by creating two style sheets (A & B, for example) within a theme:
- Select A as the active theme
- Delete A
- Try and select B as the active sheet
I have to say this is one of the most temperamental new studio betas to be released in quite a while; I’m finding there’s a 100% chance of the Style Editor crashing within an hour of starting work. I get this is a Studio Beta; however, this is really quite surprising.
1 Like
This is simply great. I don’t remember what reply it was that I read exactly, but the idea of this being generalized for non-exclusively UI purposes is exciting. There have been ways to do this, but never before while avoiding a migraine.
After getting to grips with the system I really appreciate how simple it actually is at its core. Of course, now more than ever I’m greedily hoping these kinds of improvements can open the door to more powerful UI modifications like warping, blurring, and masking down the road. Those have been long awaited and have had many, usually somewhat hacky & compromised implementations like UI themes as well.
I had some issues beyond yearning though. Sometimes redo’s and undo’s won’t cooperate properly, and having to put a “.” in the name of the tag threw me for a loop, and in a weird way that I’m still not sure if it’s on me for not getting it right.
If I am correct that this is odd, having one of those “Did you mean to include a leading ‘.’ for a tag” (likely more concise than that) notes would have spared me the headache. While it’s true all of the tags you make come with the leading “.”, and it is in the documentation, I think this is still somewhat valid considering normal tags I’m familiar with don’t have to do this.
Though maybe I’m still missing something else, as seems like I’m the only one that actually had this issue.
1 Like
Thanks for reporting, we will fix this soon!
1 Like
When there is no Selector syntax, such as “.” for tag or “#” for Name, the Selector is interpreted as an Instance class name, such as “Frame” or “ImageLabel”. This is why the error message states that no class exists since it is assuming that you meant to enter an Instance name.
This error message is a bit confusing, so we will take this into consideration to make this more clear.
1 Like
Are you looking into adding support for dynamic token operations in the future? I think this is something I will probably end up wanting, though not 100% sure yet.
1 Like
Yes, this is definitely something we’re interested in supporting!
If you name a StyleSheet a specific name, it will show with a custom icon on the Style Editor. I can’t tell whether this a feature or a bug but due to how some icons don’t make sense such as “Onboarding” and “GridPattern” I am leaning towards something that has been overlooked.
Will be be able to set custom icons for StyleSheets? It seems like a very useful feature but it sucks that you can’t have a StyleSheet named “HighContractFonts” without giving off the cool icon.
2 Likes
Hi,
First, thank you for this amazing update. I have been working with it a bit.
I haven’t read the full thread, so those suggestions might be already somewhere :
- It would be nice if you could drag-and-drop to change the order of the tokens.
- For more complex systems, it would be nice to be able to put the tokens in folders.
- It would be nice to be able to select all instances in Explorer using a Style tag. Right now, I’m using tag : “name”, but it would save time to just have a button to do something similar.
- Be able to change the icons manually
- In Type you should be able to use Enum, so you can change for example the ScaleType in a theme to another.
Thank you ^^
1 Like
Does it already work for client?