I’m struggling to identify the source of a blue outline present in all controls (buttons / sliders) after you’ve interacted with them. In the following picture, I’ve clicked Cancel, but then moved the mouse out:
I’m again really struggling by Unity deciding that the runtime stylesheet is a proprietary trade secret, because I simply can’t work out where this is coming from. I’ve now spent all day today trying practically all combinations.
Worse, the buttons don’t even have any classes that show that the blue outline is being added, so even if I fix this for the slider, it doesn’t help me fix the blue outline for all other types of controls.
I’ve also looked around in all settings and in PanelSettings, trying to find a place maybe some accessibility thing is overriding in. No dice anywhere.
I can’t accept that it’s mandatory for all Unity apps that all controls must have a blue outline after you’ve interacted with them. But it appears, for now, as though this is hard-coded.
We are aware of and have a fix for the specific issue with the Runtime Theme were it is not properly being marked as a “Unity” theme. We have a flag we set for all Unity themes that makes all selectors in a Unity theme be overridable by any user selector, regardless of the normal selector precedence rules. This bug will make it seem that the Runtime Theme is harder to override than the Editor themes - but it’s not impossible. It just means you need to make your selectors are higher precedence. USS precedence rules are the same as CSS, but generally more specific selectors are higher in precedence.
Have you tried to use a more specific selector? Something like: #unity-dragger-border.unity-base-slider__dragger-border
You might still need to do this for all pseudo states.
Also, are you using:
The Preview mode in the UI Builder to test pseudo states inside UI Builder?
The Theme selector in the UI Builder to preview the runtime theme in the UI Builder?
The UI Toolkit Debugger to get more details information on which styles are used? You can still use the Debugger on UI inside the UI Builder Canvas by turning on Preview mode.
See my answer in your other thread, but the point is that you don’t actually need the USS text file in order to know where styles are coming from and what selectors to use to override a style. Use the UI Toolkit Debugger.
But I need to understand clearly, is my inability to override it a bug? Because if so, I’d rather not work around it by abusing #ids as .classes, I’d rather wait for a fix.
On the other questions, yes, I’m using the app theme in UI Builder, but the problem doesn’t appear until the app is running – it’s not possible to test all states in UI Builder, you need to interact. It’s either some :focus state or :selected state that’s following you around, highlighting the last object you interacted with with a blue outline, and even if I override it, and the UI Builder inspector says that it’s overridden, it’s not actually possible to select it.
I’m uncomfortable using #ids as .classes, because it precludes me using IDs for actual ID work because I can then no longer have unique IDs for objects, and it’s bad practice according to CSS. This would only be an acceptable hack if it was holding up a release.
What kind of a timeline is the bug-fix on? I do have to release something within a month. If I knew this was in the pipeline, I’d happily do my other work and just upgrade to Preview 15 and make the USS changes as one of the last things.
I should also say that I only use UI Builder for testing. The real app is a combination of C# generated UXML plus USS stylesheets. But I real in another thread that pseudo-selectors can’t be controlled from code, so even if I’m in a position to hard-code styles into every single object, because I’m building the UXML document on the fly, I understand that I still wouldn’t be able to control this :focus (likely) state.
I should also say that the while the blue outline is showing both for buttons and sliders, only the UI Builder inspectors shows this color for the slider. The button doesn’t show any signs that a style is applied that would make the outline blue.
OK. It doesn’t really help because the real UI is built in code. I only use UI builder for testing individual controls.
But I really need to know whether the blue outline is considered a bug and will be overrideable in the future, or if there’s any risk I’ll be stuck with a blue outline on buttons and sliders in the future after you’ve interacted with them.
This is the core question, because this forces me to either dump the Unity-provided controls and literally start implementing controls from scratch, or it forces me to abuse IDs as though they were classes. Both are bad.
But I need to know whether this is intended to be seriously addressed, because it’s such a serious visual blemish that UI Toolkit as a whole cannot be used. I can’t release anything that looks/behaves like that. It’s a very aggressive style choice that’s currently hard-coded. Imagine a game on a blue background. The buttons would disappear after you’ve touched them.
And I want to remind you that the Button control doesn’t present any classes that bring the blue outline, it’s completely proprietary. So don’t forget to also fix it here.
So I desperately need to know whether I will be able to suppress this blue outline in the future.
@perholmes comes a bit late but I have a workaround if anyone is still interested. I also have .unity-buttons with a :focus or :active pseudo-class and want to hide this ugly blue outline/border. It’s a fix for me when I set Button.focusable (Focusable property in UI builder) to false. Blue outline is gone and my pseudo-classes work as intended.
