DEV Community

Cover image for Marking up colors, revisited with GitHub’s color swatches
Taylor Hunt
Taylor Hunt

Posted on

Marking up colors, revisited with GitHub’s color swatches

I wrote about semantic HTML for colors 5 years ago, for when a color’s appearance is important content, not just style:

  • Design systems’ available color palettes
  • Choosing what color of clothing you would like to buy
  • Preview swatches for sites about paint
  • Probably lots more — colors are pretty important!

My original post suggested a labeled <input type=color readonly>, but since then I’ve thought about how that falls short:

So, my original conclusion’s <svg> is probably a better idea. (I’d use my Edit button on that post… if I had one.)

Now, those issues are important, but the real reason I’m writing this is much pettier: I used Inspect Element on github.com and got mad about it.

GitHub’s hex code swatches

GitHub has a feature where if you type a 6-digit hex code in Markdown files/comments/whatever, it displays a color dot of that hex in RRGGBB format:

Screenshot of GitHub’s rendering the hex code #aa4400. The usual gray box around the &lt;code&gt; element extends to the right to hold a small circle of a dusky brick red.

For example, GitHub’s HTML output if you type `#aa4400` looks like:

<code>#aa4400
  <span
    class="ml-1 d-inline-block border circle color-border-subtle"
    style="background-color: #aa4400; height: 8px; width: 8px;"
  ></span>
</code>
Enter fullscreen mode Exit fullscreen mode

This has problems:

Not exposed accessibly
Forget text alternatives, right now it’s completely nonexistent to assistive technology
Too easily overridden
By Dark/Light Mode browser extensions, builtin Dark Mode browser support, user styles, etc.
Invisible under forced colors
forced-colors is the standardized name for features like Windows High-Contrast Mode, which turn off background-color altogether

We can fix most of those problems with inline SVG:

<code>#aa4400
  <svg width="8" height="8"
    fill="#aa4400"
    class="ml-1 border circle color-border-subtle"
  >
    <rect width="100%" height="100%"/>
  </svg>
</code>
Enter fullscreen mode Exit fullscreen mode

A few notes on the above markup:

  • I haven’t exposed it accessibly yet, because that turned out to be a whole section’s worth of considerations
  • No longer needs the d-inline-block class (<svg> is inline-block by default)
  • No style attribute lets it play nice with strict Content-Security Policies

But why stop there when we could be perfectionist

GitHub’s current implementation also has what I presume is a bug, where it looks silly inside larger text:

Almost like the earlier screenshot, but while the gray box scales proportionally around the text, the color dot stays 8×8 pixels and awkwardly sits near the bottom — it honestly resembles a colorful punctuation mark.

Inside an <h1>, for example.

SVG’s width and height attributes can use ems to scale the dot with the font size:

<code>#aa4400
  <svg width=".667em" height=".667em"
    fill="#aa4400"
    class="ml-1 border circle color-border-subtle"
  >
    <rect width="100%" height="100%"/>
  </svg>
</code>
Enter fullscreen mode Exit fullscreen mode

Heck, you could even replace GitHub Primer’s utility classes with SVG’s builtins:

<code>#aa4400
  <svg width=".667em" height=".667em"
    fill="#aa4400"
    viewBox="-9 -8 17 16" stroke="var(--border-subtle)"
  >
    <circle radius="16"/>
  </svg>
</code>
Enter fullscreen mode Exit fullscreen mode

GitHub probably won’t, since once you choose utility classes for something you need to use them everywhere or their core performance promise falls apart1, but maybe you might?

By the way, GitLab does this too

And as usual, GitLab implemented the feature more thoughtfully than GitHub did2. They support more color syntaxes and transparency, it doesn’t have the font-size scaling bug, and the markup is refreshingly simple:

<code>HSLA(540,70%,50%,0.3)
  <span class="gfm-color_chip">
    <span style="background-color: HSLA(540,70%,50%,0.3);"></span>
  </span>
</code>
Enter fullscreen mode Exit fullscreen mode

It still breaks with forced colors and dark mode, so maybe the GitLab peeps would be interested in this article anyway. (I also refactored theirs to be shorter, simpler, and with one less <span>, because I’m insufferable.)

Speaking of accessibility, there’s something I haven’t addressed…

Accessibly exposing the color

So, that <svg>. What’s its role? Its accessible name? Should it be announced at all?

For this specific case, it has a text equivalent right alongside it, and GitHub’s audience is tech-savvier than usual — I can imagine that GitHub may have decided announcing the color dot separately was superfluous.

…but I disagree. Displaying the color adds information for sighted users, hence why the feature exists at all; for the ideal of information parity across disability boundaries, we should try to be equitable.

Since the hex code is already there, a proper text alternative would be the information equivalent of displaying the color dot. Maybe a color name via something like the ISCC–NBS system?3

Trying to explain colors to people who can’t see them isn’t the goal — but naming a color consistently can be quite useful by itself. Not to mention, blind people may want to know for its own sake!

<code>#aa4400
  <svg role="img" aria-labelledby="_Z5jdHi6">
    <title id="_Z5jdHi6">Color: “firebrick”</title></svg>
</code>
Enter fullscreen mode Exit fullscreen mode

I don’t have a real conclusion but here’s a fun fact

When I first started learning about color accessibility, the explanations of what each colorblindness variety sees instead of the “real” colors bothered me — how could they be so sure? While normally I’m happy to leave “do you and I see the same red” to the philosophers, this was too important for a hand-wavy justification to satisfy me.

Days later, lost and confused from scientific papers about human retinas, the occipital lobe, signal processing, and other complexities around one of the first skills babies learn, I found an answer that was so prosaic it made me laugh: some people are colorblind in only one eye.


  1. Any feature you have to “earn” by adhering to a technology and you shall have no technologies before it is one I distrust. Migrating away from something like Tailwind is suspiciously difficult. (This is my footnote and I can be crankety if I want to.) 

  2. Using GitHub Actions after working in GitLab CI is like disassembling a perfectly good sandwich and making it into sushi. It all eventually goes where you need, but nobody’s happy. 

  3. There’s a bunch of color naming systems and even more color naming NPM packages, and I’m not qualified to recommend any of them. 

Latest comments (0)