Opening brace and quotes highlighted inconsistently

[gmnash]

The opening brace of some objects are not highlighted like all closing braces. Also quotes are sometimes highlighted, sometimes not. Not a problem with the CSS as it happens in all of the demo examples. The parser does not tag those structures for presentation.

[isagalaev]

This is a tricky one as there are a few things at play:

• The problem with different colors of curly braces on the first level looks fixed by now, at least I can't reproduce it with latest builds.
• Colors of double quotes are different because some themes apply a different color for "values" which is everything after keys in objects. In your screenshot the default color of the code is white but the default color for values is green which applies to all non-highlighted characters. This is indeed a styling issue and may even be intentional, it's hard to say for every author of every theme. There are many (may be even most) that don't do this.
• The highlighter assigns different class names to key names and strings in values so theme authors could choose if they want to highlight them differently or similarly.
• Finally, not highlighting quotes around key names is also intentional. These mandatory quotes in JSON are godsend for parsing but they don't help readability so I decided to leave them out of the colored key name.

I might reconsider the last point though. So the only thing that should be fixed here in my view is the default color for values that differs from the color of the main text. This is hard to do universally though, it should be made theme by theme, making sure it doesn't break other languages. Could you volunteer to do this?

[Sannis]

Could you volunteer to do this?

I can BTW. We should drop font color overriding for values?

[isagalaev]

@Sannis to summarize my current view:

• the "value" class should not be styled alone, as it is too general
• in certain cases it can be combined with other classes to style values that should be colored but don't have internal structure

[isagalaev]

I think we can close it in favor of #348 as that will most certainly take care of it. Also, this is pretty minor (though surely annoying).

[k-funk]

+1