Increase contrast for EuiCodeBlock colors

[ryankeairns]

Fixes #3243

Summary

The color variables used by EuiCodeBlock produce insufficient color contrast largely due to the slightly darker background color ($euiColorLightestShade vs $euiPageColorBackground).

This PR:

• increases color contrast by adjusting the color variables using the makeHighContrastColor mixin as prescribed in the underlying issue.
• substitutes EUI text colors directly, where possible
• removes a few colors that were not used by any components
• changes the addition/deletion styles from a background color to a left-border. This border approach saves a lot of hassle by not having to adjust the text color again given another bg color variation.

Testing

It's a little cumbersome to test all the color variables. You can do a couple of things to render the less used colors:

1. Use the Chrome inspector to override classes on the existing docs examples (adding/chaning to hljs-meta, hljs-title, hljs-section, hljs-addition, hljs-deletion, etc.) See the _code_block.scss file for the full set; many of these render in the existing examples already.
2. Change the docs examples. For example, I sued this c++ example from the hljs docs to render several of the aforementioned classes:

Renders as... (and all passed 4.5):

Checklist

• Check against all themes for compatibility in both light and dark modes
• Checked in mobile
• Checked in IE11 and Firefox
• Props have proper autodocs
• Added documentation examples
• Added or updated jest tests
• Checked for breaking changes and labeled appropriately
• Checked for accessibility including keyboard-only and screenreader modes
• A changelog entry exists and is marked appropriately

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_3309/

[ryankeairns]

Need to merge master...

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_3309/

[cchaos]

Thanks for taking this one on. 🎨 Color!!! 👨‍🎨

Just had a few comments on ways to improve the code and possibly dark theme.

Eventually we'll want to follow up with some actual thinking of the different selectors. For instance here is our (pretty simple) color scheme for CSS vs Github's.

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_3309/

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_3309/

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_3309/

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_3309/

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_3309/

[elizabetdev]

@cchaos and @ryankeairns,

Here are a few design decisions that I took to complete this PR:

• I tried to maintain the same hue as suggested by @cchaos. Both dark and light themes now have similar colors.
• I'm using the makeHighContrastColor() function for all colors.
• I removed the bold of the .hljs-keyword. I researched other similar code highlighters and none of them had the keywords with bold. This class was using the same color as the normal text and I changed it to purple. I think it looks better to have a different color.
• The .hljs-addition and .hljs-deletion are now using a box-shadow instead of a border. But I'm not sure consumers are able to use it. Just passing one of these classes to the EuiCodeBlock component doesn't do anything because the class is added to the wrapper div instead of the <code> tag. We can address this issue in a different PR.
• Added an orange to highlight the symbols. In the past, the symbols had the same colors as the text. I think it looks better if they are highlighted in a different color.
• Added a SQL example in the docs.

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_3309/

[snide]

I love it! This looks soooooo much better. Small comment about a couple of your additional variable names. Also for the addition / deletion stuff there's no rendering in the actual docs, but I'm guessing that's what you meant by making a separate issue for it?

[snide]

I would name these not by their color but by their purpose.

[snide]

Ugh. Github ate my full comment. This one is tricky. On one hand these are being used how we'd normally use a core value like $euiPrimary, or they are just one offs for use in the code blocks alone. It's hard to make a name for these things without writing the descriptive name like euiCodeBlockKeywordColor over again. Whichever direction we go, I think it's safe to say it should be the name of the color. Even something like $euiColorCodeBlock01 and $euiColorCodeBlock02 feels more flexible.

I'm sure @cchaos has opinions.

[cchaos]

Related yet tangental thought to this. Maybe we should be using the color blind palette instead of our primary, secondary, etc... colors which are more specific to our brand whereas the code block coloring is more specific to visually distinguishing between elements of code. We even have purple and orange colors in there where we then won't have to redefine new hexes for those.

[elizabetdev]

@cchaos and @snide,

Here are the new updates:

• As suggested, I replaced the colors with the color blind palette.
• The colors $euiTextSubduedColor and $euiTextColor were not replaced because the color blind palette doesn't have colors for texts.
• I didn't replace the $euiColorDanger because we don't have a red in the color blind palette.
• I checked the contrast levels and all of them passed 4.5.

Let me know what you think of this new version:

[ryankeairns]

Thanks @miukimiu , the color contrast levels check out and it looks much better!

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_3309/

[cchaos]

It is too bad that we do loose some saturation in the colors, but I think it's really only noticeable when doing a directly comparison. In the long run, it's a much better correlation to use the vis colors instead of the brand colors.

👍 LGTM!