Web Inspector: color-code property values in object notation.

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

[Pavel Feldman]

See screenshot at http://code.google.com/p/chromium/issues/detail?id=52905. We don't color-code property values in object trees.

[Pavel Feldman]

Created attachment 65716 [details]
[PATCH] Proposed change.

["Cowboy" Ben Alman]

It's not just color-coding properties in object notation, but ensuring that values are displayed consistently (colors, surrounding quotes, etc) when either returned or logged (on their own, as an array member or object property).

["Cowboy" Ben Alman]

(btw thanks for addressing this so quickly)

[Pavel Feldman]

Comment on attachment 65716 [details]
[PATCH] Proposed change.

Clearing flags on attachment: 65716

Committed r66225: <http://trac.webkit.org/changeset/66225>

[Pavel Feldman]

All reviewed patches have been landed.  Closing bug.

[Pavel Feldman]

Here is what we do:
- We color-code as follows:
number: rgb(28, 0, 207);
string, regex: rgb(196, 26, 22);
null, undefined: rgb(128, 128, 128);
- We quote strings and, surround regexes with //
- I think we dump them consistently (individually, as array members and now with this change as properties)

What exactly do you think is missing? (I don't think we should color-code functions and booleans).

["Cowboy" Ben Alman]

(In reply to comment #6)

Pavel, in the console.log( "true", true ), the string logged is black and unquoted, making it indistinguishable from the boolean value. Can the string value be colored and quoted there as well?

Also, have you considered a color like green for boolean values? Not that this is in any way critical, but a very quick visual distinction, like numbers, strings, undefined and null already have, could be very helpful for the most commonly logged types (which I'd imagine are string, number, boolean, undefined and null).

[Pavel Feldman]

(In reply to comment #7)
> (In reply to comment #6)
> 
> Pavel, in the console.log( "true", true ), the string logged is black and unquoted, making it indistinguishable from the boolean value. Can the string value be colored and quoted there as well?
> 

This is intentional (there is a special piece of code that handles it). The rationale is that console.log outputs messages for user, not a string values. In 99% of cases these are just service messages, no need to quote them - it clutters ui. As a result, console.log("Something went wrong") and evaluating something with "Something went wrong" string result renders differently.

> Also, have you considered a color like green for boolean values? Not that this is in any way critical, but a very quick visual distinction, like numbers, strings, undefined and null already have, could be very helpful for the most commonly logged types (which I'd imagine are string, number, boolean, undefined and null).

I don't have a strong opinion on this. I think color-coding null, undefined and quoting are critical. Rest is more of FireBug consistency. Too many colors clutter ui too...

[WebKit Review Bot]

http://trac.webkit.org/changeset/66225 might have broken Qt Linux Release

[Joseph Pecoraro]

> > Pavel, in the console.log( "true", true ), the string logged is black and unquoted,
> > making it indistinguishable from the boolean value. Can the string value be colored
> > and quoted there as well?
> > 
> 
> This is intentional [...]

Pavel is correct. console.log() is logging a string to the console. It uses
printf() style format, and for all extra arguments it conveniently prints
them out as objects in the console. For example note the difference between:

  js> console.log("logging some objects %s %s", {a:1,b:2}, [1])
  logging some objects Object Array

  js> console.log("logging some objects", {a:1,b:2}, [1])
  logging some objects (triangle) Object [1]

The first argument, when it is a string, is treated as a "printf" string
allowing formatting for numbers, objects, etc. As Pavel mentions the typical
use case is to just log some text. In those cases we would not want to
print out the log messages formatted as a string. However, if the user has
not provided a string as the first argument, it would not be very useful
to convert that to a string and use it as a printf formatting string, so we
just log the object nicely.

If you want different logs you could do console.info(), console.error(),
console.warn(). If you want to view the formatted version of a string you
could use %o.

  js> console.log("Hello %o!", "World")
  Hello "World"!