Bug 32926 – Styles Inspector: Revert font back to "'Lucida Grande', sans-serif" and "10px"

• Component: Web Inspector (Deprecated)
• Status: RESOLVED WONTFIX

[Chris J. Shull]

The Styles inspector recently began using "font-family: monospace;" and "font-size: 11px" for style properties.

This does not look as nice, and there is no benefit to using a monospaced font. 
In fact, it makes it so less information is visible inside the standard Styles column width.

Please revert back to:

font-family: 'Lucida Grande', sans-serif;
font-size: 10px;

[Chris J. Shull]

One of my favorite things about the WebKit Web Inspector (other than it's functionality) is that it looks so pretty.
Please make it pretty again.

[Pavel Feldman]

(In reply to comment #1)
> One of my favorite things about the WebKit Web Inspector (other than it's
> functionality) is that it looks so pretty.
> Please make it pretty again.

We are in process of changing the styles pane even further. The idea behind the change / series of changes is that we use monospace font for source code and for the parts of the UI that user can actually edit. We hope that you like the final looks, but if you don't, please let us know and we will continue

[Pavel Feldman]

... and we will continue looking for the ultimate solution!

[Chris J. Shull]

I'm getting used to the monospaced font - but I still wish the text were perhaps smaller, so that I didn't need a wider styles pane just to see things.

[Nikita Vasilyev]

Created attachment 53044 [details]
Lucida Grande 11px for Elements pane

I have tested it only on MacOS X Leopard.

[Nikita Vasilyev]

Created attachment 53045 [details]
Elements pane, MacOS X Leopard, Lucida Grande 11px

[Nikita Vasilyev]

Created attachment 53046 [details]
Monospace Monaco for Scripts pane

[Nikita Vasilyev]

Created attachment 53047 [details]
Monospace Monaco for Console pane

[Nikita Vasilyev]

Created attachment 53055 [details]
Lucida Grande 11px for Elements pane

[Joseph Pecoraro]

Hey Nikita! Glad to see you're making patches (I saw you tweeted) =).

-----------

First and foremost, the patch you provided would not be valid to land, as it was not done on WebKit source code! The file you edited was the inspector.css in your system framework, not of a WebKit checkout. The file you patched was:

> /Applications/WebKit.app/Contents/Frameworks/10.5/WebCore.framework/Versions/A/Resources/inspector/inspector.css

If you intend on doing more inspector work I strongly suggest that you checkout the WebKit source. Its easy (just a little time consuming, but something you can run in the background). It might make your patches more accurate (using the latest source instead of the WebKit version you have installed on your system) and if it gets approved you'd be in a much better position to have the patch landed!

  Here is where you could get started:
  - General Info - http://webkit.org/coding/contributing.html
  - SVN - http://webkit.org/building/checkout.html
  - Git - http://trac.webkit.org/wiki/UsingGitWithWebKit

If you are interested and have any questions please don't hesitate to ask here, on twitter, via email, or on IRC (freenode.irc.net #webkit or #webkit-inspector). Plenty of people should be available and willing to help.

------------

Back to this patch. Thanks for attaching images above, that is very helpful! I've seen people argue for monospaced fonts [1] and others [here] argue against it. You can't please everybody, you can only pick a default that you think works best for most cases / users.

[1] http://jayrobinson.org/2009/12/05/webkit-web-inspector-vs-firefox-firebug/

Therefore, I think the ultimate solution would be to let the developer pick the fonts! The challenge would then be coming up with a UI, that doesn't clutter the already overflowing inspector. The ideas (read IDEAS) I have are:

  - the fonts are already trying to be platform specific. Why not actually making them platform "Settings". At this point the platform client could include native font picker tools wherever it is appropriate. For instance in Safari's Preferences under the "Advanced" tab?
  - put a button in the inspector (bottom corner?) to open up its own (shared) preference window.

[Joseph Pecoraro]

Whoops, I messed up Freenode's address. Here are links:
irc://irc.freenode.net/#webkit
irc://irc.freenode.net/#webkit-inspector

[Pavel Feldman]

>   - the fonts are already trying to be platform specific. Why not actually
> making them platform "Settings". At this point the platform client could
> include native font picker tools wherever it is appropriate. For instance in
> Safari's Preferences under the "Advanced" tab?

This seems to be a part of a more general bug / feature related to changing the style and size of the fonts in the inspector.

Still, I am convinced that all the UI fragments that correspond to the user's source code should be rendered as in IDE (i.e. monospace). I think that monospace migration of the DOM itself was received fairly well. And I don't see a big difference between the dom and the styles. Except for styles' UI is cluttered. We have an experiment that we will land shortly that removes some clutter: https://bug-36747-attachments.webkit.org/attachment.cgi?id=51948. We would like to play with it in nightlies / dev channel before it hits the user.

Nikita, it is nice to see you contributing patches! Besides Joe's comments, my friendly advice would be to start with declaring your intentions in the bug comments and see how people react. In this case, it seems to be a significant ui change that needs to be discussed either in the bug or on the IRC (just as the serif -> monospace move was). After that, when everyone is happy, you submit patches and land things. UI is somewhat sensitive area for us!

[Nikita Vasilyev]

Created attachment 53085 [details]
Lucida Grande 11px for Elements pane

Well, I've generated patch via `git format-patch`. I hope it's the right format.


(In reply to comment #12)
> Still, I am convinced that all the UI fragments that correspond to the user's
> source code should be rendered as in IDE (i.e. monospace). I think that
> monospace migration of the DOM itself was received fairly well. And I don't see
> a big difference between the dom and the styles. ...

I just made what Chris proposed in first comment. I'm totally agree with him (except a font size, 10px is too small, 11px looks better for me).

I think monospaced font good:
 1) when you need to move cursor vertically
 2) at rendering 1 l I i, 0 O

(1) doesn't work in DOM and Styles panels. You never move cursor vertically.

A sans serif font is much more readable and more compact.


(In reply to comment #2)
> We are in process of changing the styles pane even further. The idea behind the
> change / series of changes is that we use monospace font for source code and
> for the parts of the UI that user can actually edit.

What exactly do you mean by "parts of the UI that user can actually edit"? User can edit DOM and CSS in the Elements panel. User can write in the console. All those things already have a monospaced font.

[Pavel Feldman]

> What exactly do you mean by "parts of the UI that user can actually edit"? User
> can edit DOM and CSS in the Elements panel. User can write in the console. All
> those things already have a monospaced font.

Well, the point was that things you can edit should be monospace, emphasizing their editable source code nature. DOM, CSS and Console you enumerated are editable and hence monospace. And I think it should remain so.

Now style selectors are also editable, but that is unclear from the way we render them. The screenshot I referenced above addressed it via pulling the selector text into the editable monospace area.

[Joseph Pecoraro]

(In reply to comment #13)
> Well, I've generated patch via `git format-patch`. I hope it's the right
> format.

Great! I think thats fine. Typically the command I use (and it looks like webkit-patch uses) is: `git diff --binary.

The only thing missing now would be a ChangeLog entry:
http://webkit.org/coding/contributing.html#changelogs

But before adding another patch on this bug, focus on on the discussion to try and find a better solution!

[Nikita Vasilyev]

(In reply to comment #10)
> Therefore, I think the ultimate solution would be to let the developer pick the
> fonts! ...

Another idea: UserCSS. What if we give user ability to choose his own CSS for Web Inspector? Maybe someone don't like not just fonts, but colors or even layout.

I steal the idea from Opera. Opera has site-specific stylesheets. You can choose your own stylesheet for site you want. You can choose stylesheet fo Dragonfly (which is pretty the same thing as Inspector) — just set stylesheet for https://dragonfly.opera.com/app/

Alas, WebKit doesn't have site-specific stylesheets. But we can store CSS in localStorage, isn't it? 

What do you think?

[Chris J. Shull]

(In reply to comment #16)
> Another idea: UserCSS. What if we give user ability to choose his own CSS for
> Web Inspector? Maybe someone don't like not just fonts, but colors or even
> layout.
> ...
> Alas, WebKit doesn't have site-specific stylesheets. But we can store CSS in
> localStorage, isn't it? 
> 
> What do you think?

I love this idea. I've been wanting an easy way to tweak the web inspector's look for a long time.
I don't think localstorage is the way to go though. 

Right now Safari has a way to select a user Style sheet (under Advanced in prefs).
However, It seems that this does not get applied to the web inspector. What if either:
   1) it did apply to the web inspector or
   2) there was a place to select an inspector style sheet?

[Nikita Vasilyev]

(In reply to comment #17)

Writing to localStorage doesn't work within Web Inspector.

localStorage['yada'] = 'yada'
"QUOTA_EXCEEDED_ERR: DOM Exception 22"

Error message a little bit misleading, since my localStorage is empty.

> Right now Safari has a way to select a user Style sheet (under Advanced in
> prefs).
> However, It seems that this does not get applied to the web inspector. What if
> either:
>    1) it did apply to the web inspector

Sounds good to me. By the way, I have no idea how to implement it.

[Alexander Pavlov (apavlov)]

The fonts have stabilized, closing the bug.