Document and possibly update guidelines for graphs

[RReverser]

Sounds like we might want to update default colors for graphs (cc @tabatkins): https://twitter.com/tabatkins/status/1244695274338971649

We already have some templates for standard colors across the blog (cc @mathiasbynens), but it could be useful to document and update them explicitly in the repo.

Not sure if there is something we could do about existing graphs - is it possible to due color-shifting magic like we do for the dark theme (cc @tomayac) or would they need to be updated in bulk or would we need to just leave existing ones intact?

[mathiasbynens]

I think the graphs that use our standard colors (i.e. the ones we make in Google Sheets) are fine; Tab is talking about the screenshots from chromeperf, e.g. https://v8.dev/blog/pointer-compression#initial-performance. Yep, that's bad. Ideally we'd take the chromeperf data and turn it into a proper SVG using our standard colors.

is it possible to due color-shifting magic like we do for the dark theme (cc @tomayac)

I'd prefer not going this route. We should either fix the source images, or leave the old ones be and be more stringent about using our standard colors for all graphs in the future.

[RReverser]

Yep, that's bad. Ideally we'd take the chromeperf data and turn it into a proper SVG using our standard colors.

Ah, I see, I thought it was about our regular graphs. This certainly reduces the scope of changes then.

[tomayac]

For the image on v8.dev/blog/pointer-compression specifically, tweaking the hue-rotate fixes it:

invert(.862745) hue-rotate(120deg)

This should, however, indeed be fixed at the source.

[tomayac]

Quick drive-by PR to fix /_img/pointer-compression/perf-octane-1.svg is up for merging: https://github.com/v8/v8.dev/pull/364

[tabatkins]

The important bit is just that the lines aren't differentiated purely by hue (my red-green colorblindness is one possibility, but there are others), but also by lightness and/or pattern.

(And note that hsl's notion of lightness is a nonsense number that means nothing; it considers full blue and full yellow to have equal lightness, despite those actually being extremely far apart. You want the lightness used by actual monochrome, or by color spaces based on actual human vision like Lab/LCH. You can get a quick and dirty, but useful, approximation of this by taking the RGB value and computing (4*G + 3*R + B)/8.)

As such, I'm a little concerned about a hue-rotate being used here, as it adjusts the hue in HSL space, which again has absolutely no reasonable conception of "lightness" based on hue.

(It does indeed seem to work fine for this particular example, however; the colors are much more distinguishable to me now.)

[tomayac]

(It does indeed seem to work fine for this particular example, however; the colors are much more distinguishable to me now.)

Happy it works. As a normally sighted developer, I tested my hack with @mathiasbynens' cool new DevTools feature B-) But again, you want to fix this on the source… Using pattern and color differences per line is IMHO the way to go.

[RReverser]

Yep, that's bad. Ideally we'd take the chromeperf data and turn it into a proper SVG using our standard colors.

@mathiasbynens Would it make more sense / be possible to raise this upstream with chromeperf instead? I imagine Chrome might similarly have colorblind contributors who would appreciate more distinguishable graphs.