[Webkit-unassigned] [Bug 145982] Web Inspector: Style sidebar editing issues

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Jul 25 16:53:50 PDT 2015


https://bugs.webkit.org/show_bug.cgi?id=145982

Chris Chiera <chris at heavymark.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #9 from Chris Chiera <chris at heavymark.com> ---
While Webkit still isn't available on 10.11 so can't test on my own computer, tested on another person's computer who still has 10.10 installed to see the improvements to Webkit mentioned here.

At quick glance I see all the irrelevant :before:after and other styles have been moved to the bottom of the list like Chrome now, which is great. However, at quick glance all of the space issues still appear to exist. 

I'm attaching a screenshot comparison of the Chrome Web Inspector vs the Safari web inspector set to the exact same height to show how Safari shows very little actual data and a lot of UI compared to Chrome which shows very little UI and a lot of actual styles. Once again, Safari's implementation looks much sexier and looks great for screenshots or looking at, just not very helpful for actual dev work compared to Chrome especially on a Laptop where space is so limited.

So ways to improve:
1. Like in Safari's main tab view at the top, the tab bar in the dev panel should disappear if only one tab is open. Perhaps have the "+" next to the search box in the main dev bar.
2. Combine Node, Styles, Layers bar with the Computed Rules Metrics bar. May for instance it would show, "Styles: Computed Rules Metrics" and an arrow next to Styles so in a dropdown you could choose Node or Layers and when you change to one of those the links to right change accordingly.
3. Shorten elements.style section. I think you can remove "No properties - click to edit" since it will be evident there are no properties if there are no properties showing. You could move click to edit to be right aligned, but I think it's also self evident since this is aimed at devs rather than consumers who would need explicit instructions.
4. Reduce Remove Rule. This is probably the biggest space hog other than the double tab bars. It takes up an enormous amount of unnecessary space. Chrome simply has a "+" that takes up no extra vertical space and think you could put the plus in the element.style place on the right like Chrome.
5. Media Queries. I actually like Safari's visual version of these. The only space saving suggestion would be to reduce the top padding to match the bottom padding of that media bar.
6. Styles Padding. In chrome the padding space above/below the styles such as .bs-docs... is a few pixels less which saves a good deal of space in the long run. While the roomier Safari looks nice, I think less padding would be more useful though is a little tougher because Safari has icons which take more vertical space. While I personally don't think the icons are necessary, if left, you could have the top of the icons lined up with the top of the adjacent text (so move the icons down a few pixels.
7. One place where Safari wins space wise is Safari doesn't show the closing } which saves space. Great!
8. For Active, Focus, Hover, Visited, there is a lot of extra top/bottom padding. That bar should be the same height as the computed, rules, metrics bar right above it. While it's great it hides as you scroll it still would be better with a consistent smaller height.
9. Finally the Filter Styles is taller in Safari than Chrome. This is one place where Chrome's version may be just a tad too small. I'd recommend less than Safari but more than Chrome and removing the inner border of the filter styles search box.

Perhaps if a person is on desktop and increases the height of the dev tools to a substantial size, the dev tools could default to a roomier option like it currently is but imagine more than not will be designing on a laptop with the dev window relatively small so they can see the actual content above.

I've attached a quick 1 minute mockup called modified showing all the extra space you could save.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150725/438b9b7e/attachment.html>


More information about the webkit-unassigned mailing list