More color utilities!

[shawnbot]

This PR adds 140 new utility classes — a foreground and background utility for each shade (10) of every hue (of which there are 7).

There is some redundancy with existing utilities, and GitHub's postcss config combines selectors with the same style (for instance, .text-blue and .fg-blue-5 are combined), but the size difference is not actually pretty insignificant: less than 1K gzipped!

┌─────────────────────┬───────────┬───────┬───────────┬─────────┬──────────┬───────┬──────────────────────────────┐
│ name                │ selectors │     ± │ gzip size │       ± │ raw size │     ± │ path                         │
├─────────────────────┼───────────┼───────┼───────────┼─────────┼──────────┼───────┼──────────────────────────────┤
│ primer              │      3096 │ + 140 │   23.88 K │ + 991 B │ 151.95 K │ + 6 K │ dist/primer.css              │
│ core                │      2139 │ + 140 │   17.12 K │ + 998 B │ 108.09 K │ + 6 K │ dist/core.css                │
│ utilities           │      1292 │ + 140 │    8.23 K │ + 998 B │  62.73 K │ + 6 K │ dist/utilities.css           │

I am swapping out the text- prefix used in our "old" color utilities for fg- color- because we often use utilities to give color to octicons rather than text specifically.

[simurai]

so a 6k increase before gzip

Since these styles are very repetitive, it might not be that big of a difference after gzipping? 🤔

[simurai]

I'm on the fence with the fg- vs color- prefix.

• fg- is short and would make it similar to bg-.
• color- describes better what it does -> changing the color property.

Hmm.. I'm slightly leaning towards color-.

[shawnbot]

Since these styles are very repetitive, it might not be that big of a difference after gzipping? 🤔

You're right! Before: 7.48 kB vs. after: 8.47 kB for dist/utilities.css. I got this with:

git co master
npm run dist
npx gzip-size-cli dist/utilities.css
# 7.48 kB
git co more-color-utilities
npm run dist
npx gzip-size-cli dist/utilities.css
# 8.47 kB

So yeah, maybe not as big of an issue as I thought! 🤗

[shawnbot]

I'm on the fence with the fg- vs color- prefix.

Yeah, I went back and forth on this. The use case that has me leaning toward fg- is that people do and will use these classes to color octicons (and other SVG elements), which has always felt a little awkward/unintuitive to me:

<%= octicon("heart", class: "text-red") %>

...thanks to .octicon { fill: currentColor; }.

Of course, on the other hand, color- matches up with the styled-system props in Primer Components, so that alone might make it preferable. @jonrohan @broccolini @emplums, any thoughts?

[simurai]

On a second thought, because color is something used quite often, how about just a c-. Similar to the m- or p- utilities.

<%= octicon("heart", class: "color-red-8") %>
<%= octicon("heart", class: "fg-red-8") %>
<%= octicon("heart", class: "c-red-8") %>

Not sure how much trouble it would be to also change it for Components?

<StyledOcticon icon={Heart} color="red.8" />
<StyledOcticon icon={Heart} fg="red.8" />
<StyledOcticon icon={Heart} c="red.8" />

[emplums]

Just copying my Slack comments over here!

I could see the benefit of either fg- or color-. I feel like fg is more descriptively correct, but color lines up with our React component API better and I think is more intuitive - not everyone would recognize that fg means foreground or know what that means in the context of CSS. And it's literally changing just the color CSS rule so color does feel better in that sense!

[shawnbot]

Note: I did this by hand, but we're going to eventually automate the generation of this file from primer-colors, as in #761.

[simurai]

On Slack the consensus was to go with color- prefix. Therefore ready to 🚢 👍