Feedback UI Debugger is horrible

Let me preface this with the fact that I do not use UI Builder at all, as I just copy stuff from figma. As a result, most of my css tinkering ends up being done through the debugger, and so far it has been a dreadful experience full of issues that were solved decades ago in webdev.

Here are some of the biggest issues I faced:
1. I develop a lot of wide UI's (> 2000px) and, as a result, need a lot of viewport space. Unfortunately, the ui debugger does not work well at small widths (or any reasonable width for that matter). Here's a list of bugs I found:
1.1 The stylesheet button in Matching Selectors almost always obscures the selector name (the entire design is awful, more on that later)

This is never an issue in the browser no matter the resolution

1.2 The layout debug text gets cut off even if there is a scrollbar

1.3 Speaking of the scrollbar, the right panel will always overflow when its inner width < 506px

This is caused by the field__specifity label having a min-width of 200px

Removing the min-width and adding white-space: normal; fixes this issue

 

1.4 The final width related issue is also the most important - why can't the right panel be moved to the bottom when the width is too small? The browser automatically moves the panel to the bottom when the viewport is too small, so why can't the debugger do it?

 

Now onto feedback:
2. The Stylesheets panel is useless:

I personally do not at all understand what this is for. If you need to see what stylesheets affect this element then Matching Selectors is literally below this one. What is the purpose of this? Why is this useless thing at the top? Why does the first button list tss files in a column rather than row + wrap? (I have no idea why the default uss file is listed twice, it is only included once btw)

 

3. The Matching Selectors is a useful tool!

until you realize the browser just does it better

You can see which stylesheet the classes came from AND you can edit/create new styles in the same panel! Сrazy, right? Why can't the debugger do the same?
4. The Element Styles tab is not very useful, it should not be at the top, certainly not above the StyleProperties group.
I feel like at some of its functionality could be moved to a separate tab. The only 2 things I've ever used from it is the picking mode and the layout debug text. The latter is only useful because without it you'd have to scroll from the StyleProperties group all the way to the box model just so you could see the width height.

 

5. The classes group:

is completely useless on its own - I rarely need to see if an element has a certain class or not, what I always need to see is what properties this class adds to the element. And even more importantly - what properties were overriden by a class, yknow, just like in the browser.

 

6. And now for the absolute worst part - the StyleProperties group.

6.1. First of all, this is the MOST IMPORTANT part of the debugger, It is almost the whole reason I'm using it in the first place. WHY is it at the bottom??
This group should be at the top, right below the box model and not where it is right now.

6.2. Adding new properties is horrible. You can't "add" a property by typing its name (like in the browser), you have to click "Show all" first, then search for it. You then have to clear the search and click "Show all" again to remove all the useless properties.

6.3. You cannot see which classes add/override which properties, you also can't see if a property was added by a style or class

6.4. You cannot see which stylesheets the properties come from

6.5. You cannot see which styles were inherited from parent elements

6.6. You cannot disable a property

6.7. You cannot add a custom selector and assign it some properties (Useful in case you want to see if child elements affected by the new selector you need to add)

All of the issues above are already solved problems in the browser. Why does the debugger have them then?

 

You have valid points but that does not make the debugger horrible. I find it much easier to use than firefox or chrome's debuggers.

For the layout issues most devs debug css on a second screen, personally I don't but I put it in a tab next to the console messages.

For the "min-width" part, I mostly agree, even in runtime some visual elements have labels with min-width and that gave me a hard time making things look right. Using flex-grow and flex-shrink could fix these issues.

However maybe try to allocate the whole screen width to the debugger and this issue should go away.

The stylesheet panel opens the files in your code editor but it does not always work, the import directives are mentioned between parentheses, it's a bit weird ok.

I agree that the debugger should mention the stylesheet that gave the property.

For the "Show All" part I like it because otherwise I would have no idea that properties like -unity-background-image-tint-color even exist. I think that some of them are not listed in Show All, anyway it's really useful in my opinion.

However you are comparing a relatively new tool with debuggers that have more than 10 years of development behind them, and probably also bigger teams to take care of them. I think that despite the flaws you mentioned it's a great tool and does the job.