WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
44766
Web Inspector: color-code property values in object notation.
https://bugs.webkit.org/show_bug.cgi?id=44766
Summary
Web Inspector: color-code property values in object notation.
Pavel Feldman
Reported
2010-08-27 08:17:14 PDT
See screenshot at
http://code.google.com/p/chromium/issues/detail?id=52905
. We don't color-code property values in object trees.
Attachments
[PATCH] Proposed change.
(1.26 KB, patch)
2010-08-27 08:24 PDT
,
Pavel Feldman
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Pavel Feldman
Comment 1
2010-08-27 08:24:27 PDT
Created
attachment 65716
[details]
[PATCH] Proposed change.
"Cowboy" Ben Alman
Comment 2
2010-08-27 08:47:41 PDT
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
Comment 3
2010-08-27 09:06:04 PDT
(btw thanks for addressing this so quickly)
Pavel Feldman
Comment 4
2010-08-27 09:06:54 PDT
Comment on
attachment 65716
[details]
[PATCH] Proposed change. Clearing flags on attachment: 65716 Committed
r66225
: <
http://trac.webkit.org/changeset/66225
>
Pavel Feldman
Comment 5
2010-08-27 09:07:05 PDT
All reviewed patches have been landed. Closing bug.
Pavel Feldman
Comment 6
2010-08-27 09:07:26 PDT
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
Comment 7
2010-08-27 09:30:35 PDT
(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
Comment 8
2010-08-27 09:39:08 PDT
(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
Comment 9
2010-08-27 09:39:59 PDT
http://trac.webkit.org/changeset/66225
might have broken Qt Linux Release
Joseph Pecoraro
Comment 10
2010-08-27 09:57:52 PDT
> > 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"!
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug