Color Naming

2025-10-05T00:00:00+00:00

Naming colors should should be easy right? You'd be surprised how much time and brain-power is spent figuring this out.</p> </blockquote>
While theming might appear simple at first glance a fair bit of complexity can appear once full context is taken into account. Some common challenges include, but are not limited to:</p>

Theme's target changing over time i.e. handling deprecation</li>
Inability to assume theme authors having full context of the software</li>
Accessibility requirements like contrast</a> or color blindness</li> </ul>
As the project grows in scale (and age) I've seen theming going through often predictable stages with Stage 0</strong> being copy-pasting #HEX</code> codes from the design into the codebase.</p>
Stage One</a></h2> Referencing by WHAT</strong> color is used</p> </p> A common practice to ensure consistency is limiting colors to a finite set called palette</strong>. The palette colors often come with a marketing name</em> like Pantone's</a> Seashell Pink</strong> or Ruby Wine</strong>. While these names do a great job at conveying the artisanal color picking and evoke abstract associations, they often fall short at being used as references for few reasons:</p> Having reference that leaks information about the color itself restricts what it can reasonably point to</li> Its easy to "theme yourself into a corner"</em> where you will end up doing a lot of find & replace</code></li> These names carry no information about how they are used</strong> in the project making it trivial to use them in an inconsistent way</li> </ul> Great example of direct palette usage is present in terminal emulators, which allow theming</em> the first 16 ANSI Colors</a>. Some fascinating historical accounts can be found on xterm's FAQ</a> where the maintainers answer questions such as: I don't like that shade of blue</a> with "Nobody Does..." 😀. Additionally, if we look at the wide variety of interpretations of color Yellow</em> over the years,</p> </p> Stage Two</a></h2> Referencing by WHERE</strong> a color is used</em></p> The next logical step to solve Stage 1 issues is to name colors by where they are used instead. Think of references like scrollbar</code>, modalPopoverBackground</code>, loginBorder</code> etc. For smaller projects and/or projects that don't change too much this approach actually works quite well. For large or dynamic projects I have experienced of two main issues:</p> 1. Maintainability</strong></p> Size of the theme grows linearly</strong> with the project which might still be manageable.</li> The time it takes to create a new theme can see a quadratic increase</strong> though, since for every color themes author has to find, where it's used.</li> When adding new features to the software there are now n!</code> 🙀 possible color transitions. This makes it almost impossible not to break existing themes without increasing reference count even further.</li> </ul> 2. Barrier of Entry</strong></p> This tight coupling also means that the theme authors are required to have full</strong> understanding of the software. Let's look at Ableton LIVE</a> - a fairly complex audio workstation, which has a thriving theming community. Creating themes for it is not trivial. Good luck finding where colors like ViewCheckControlDisabledOff</code> is used in the software within 160 other references. To mitigate the issue people have been creating tools like livethemes</a> with an online GUI theme editor, but that is not ideal either as the tool has to be constantly maintained. Looking at their FAQ</a> the issues become more apparent:</p> Will these themes work in Ableton 11?</strong> Early tests show are they do work in Ableton 11 but are not fully optimized for it. As soon as the final version of Ableton 11 gets released we'll get working on a 'Download for Ableton 11' option.</p> </blockquote> I can't find {insert element here} to customize.</strong> There are lots of elements you can customize within a theme, and unfortunately we haven't been able to map all of them to the preview yet...</p> </blockquote> As we can see, this approach starts to fall apart when number of colors approach triple digits due to the non-linear nature of growth in complexity. The tricky part is that the issues only reveal themselves after the project is already large and refactoring has become a significant effort.</p> Stage Three</a></h2> Referencing by HOW</strong> a color relates to other colors</em></p> This approach introduces an abstraction layer between the software and palette. The colors are named by how they are used in relation to other colors</strong>. Like foreground</code> being used to draw text on background</code> or accent</code> being used sparingly to guide user's attention. The color names ideally do not leak any implementation details from the software itself or exact colors used. The format of the theme only defines a set of requirements like minimum contrast or matching perceived luminance. This approach also makes themes portable and enables them to be used across various applications, which is why this approach is often used UI Frameworks and operating systems.</p> Example</a></h3> As an example let's imagine that we are building a CLI application and that we would like to use the existing 16 ANSI colors for compatibility. While we can't anticipate every color palette it would be very helpful to precisely define what our expectations are using a graph. This can be done in few steps:</p> Rename the main colors to reflect their usage like bright-black</code> → primaryBackground</code></li> normal-red</code> → error</code></li> etc...</li> </ul> </li> Create an undirected graph that describes the contrast requirements I've grouped the colors to reduce the number of connections required</li> The connections describe minimum perceived contrast requirement for drawing text</li> </ul> </li> </ol> </p> With this abstraction in place:</p> Graph can now serve as an interface between creators of the theme and software authors.</li> It enables colors to be applied consistently when adding new features.</li> Themes can now also be validated without explicit knowledge of current as well as future software implementations.</li> </ul> Conclusion</a></h1> In this article I outlined three ways of referencing colors:</p> Approach</th> Description</th> Example</th></tr></thead> By WHAT</strong> color is used</td> naive approach</td> burgundyRed</code>, paleBlue</code></td></tr> By WHERE</strong> a color is used</td> works, but has scalability issues</td> buttonTitle</code>, scrollbar</code></td></tr> By HOW</strong> a colors relate</td> recommended</td> background</code>, accent</code></td></tr> </tbody></table> I discussed how theming progresses from basic copy-pasting to more sophisticated approaches with each stage addressing specific challenges, with the ultimate goal of simplifying theme management and ensuring consistency and scalability across projects.</p> Atreus Keyboard 2024-01-01T00:00:00+00:00 </p> A keyboard with 42 key Atreus</a> layout. Uses Kailh Choc</a> low profile switches with hot-swap sockets. Compatible with ProMicro type controllers, but designed to be used with Nice!Nano</a>. Capable of n-key rollover. There is enough spacing between keys to fit all of the commonly available keycaps - transparent, flat and concave. PCB and case exports available in the github repo</a>!</p> Materials</a></h2> Name</th> Part</th> Size</th> Amount</th></tr></thead> Switch</td> CPG135001D0X</a></td> -</td> 42</td></tr> Socket</td> CPG135001S30</a></td> -</td> 42</td></tr> Diode</td> 1N4148</a></td> SOD123</td> 42</td></tr> Controller</td> nice!nano</a></td> -</td> 1</td></tr> Battery</td> XZK 301230</td> 30x12x3.0mm</td> 1</td></tr> Bolt</td> M2 Hex</td> 4mm</td> 8</td></tr> Machine Headers</td> Mill-Max</td> 13p 3mm</td> 2</td></tr> </tbody></table> PCB</a></h2> </p> ⚠️ No power switch for the battery</li> For every switch has a diode, soldered where an backlight LED would normally be located, providing n-key rollover.</li> </ul> Sockets</a></h2> </p> The PCB has 1.5mm wide holes for mounting the controller socket. This allows soldering machine headers flush with the board. The nice!nano controller originally ships with low profile headers, which won't fit the battery underneath the controller, if soldered in this manner. Therefore a pair of 3mm tall headers had to be separately ordered.</p> Case</a></h2> </p> All 3d printing was done with 0.4mm nozzle at 0.2mm layer height from PETG.</li> The bottom case is attached using eight 4mm long M2 bolts.</li> Added feet using 1mm thick rubber tape</li> </ul> Led</a></h2> </p> In the nice!nano's cover there are two openings for the LEDs. They can be filled with a dab of hot-glue before the print is removed form the bed to get a more diffused look ...for science, you monster.</em></a></p>

Product ID</th>	Item Name</th>	Price</th>	Stock Status</th></tr></thead>
#1024</td>	Wireless `Mouse</code></td>`	$25.00</td>	In Stock</td></tr>
#1025</td>	Mechanical Keyboard</td>	$89.99</td>	Low Stock</td></tr>
#1026</td>	USB-C Cable (1m)</td>	$9.50</td>	Out of Stock</td></tr> </tbody></table> Paragraph</a></h2> If you are designing a mobile app or website and want to use Figma’s native Variables feature to automatically flip your UI mockups from light to dark mode with a single click, this is locked behind a paid plan.</p> SPF</a></h2> sender policy framework</p> "Is this server allowed to send for this domain?"</p> </blockquote> Lists valid send servers for the domain</li> Format: `v=spf1 [mechanisms] [qualifier]~all</code></li> </ul>`DKIM</a></h2> domain keys identified mail</p> Is this email authentic and unmodified?</p> </blockquote> Contains sending servers public key, which is used to sign mails</li> Can be pointed to via CNAME record</li> Format: v=DKIM1; k=rsa; p=[base_64_public_key]</code></li> </ul> DMARC</a></h2> domain-based message authentication reporting and conformance</p> What to do, if it fails?</p> </blockquote> Contains policy for handling failures</li> Format: v=DMARC1; p=[none\|quarantine\|reject>; rua=mailto:abuse@example.com</code></li> Forbid user@subdomain.example.com</code> for SPF</em> and DKIM</em> by setting adkim=[s\|r]; aspf=[s\|r]</code> to strict s</code>. Default is r</code> - relaxed</li> </ul> Color Naming 2025-10-05T00:00:00+00:00 Naming colors should should be easy right? You'd be surprised how much time and brain-power is spent figuring this out.</p> </blockquote> While theming might appear simple at first glance a fair bit of complexity can appear once full context is taken into account. Some common challenges include, but are not limited to:</p> Theme's target changing over time i.e. handling deprecation</li> Inability to assume theme authors having full context of the software</li> Accessibility requirements like contrast</a> or color blindness</li> </ul> As the project grows in scale (and age) I've seen theming going through often predictable stages with Stage 0</strong> being copy-pasting #HEX</code> codes from the design into the codebase.</p> Stage One</a></h2> Referencing by WHAT</strong> color is used</p> </p> A common practice to ensure consistency is limiting colors to a finite set called palette</strong>. The palette colors often come with a marketing name</em> like Pantone's</a> Seashell Pink</strong> or Ruby Wine</strong>. While these names do a great job at conveying the artisanal color picking and evoke abstract associations, they often fall short at being used as references for few reasons:</p> Having reference that leaks information about the color itself restricts what it can reasonably point to</li> Its easy to "theme yourself into a corner"</em> where you will end up doing a lot of find & replace</code></li> These names carry no information about how they are used</strong> in the project making it trivial to use them in an inconsistent way</li> </ul> Great example of direct palette usage is present in terminal emulators, which allow theming</em> the first 16 ANSI Colors</a>. Some fascinating historical accounts can be found on xterm's FAQ</a> where the maintainers answer questions such as: I don't like that shade of blue</a> with "Nobody Does..." 😀. Additionally, if we look at the wide variety of interpretations of color Yellow</em> over the years,</p> </p> Stage Two</a></h2> Referencing by WHERE</strong> a color is used</em></p> The next logical step to solve Stage 1 issues is to name colors by where they are used instead. Think of references like scrollbar</code>, modalPopoverBackground</code>, loginBorder</code> etc. For smaller projects and/or projects that don't change too much this approach actually works quite well. For large or dynamic projects I have experienced of two main issues:</p> 1. Maintainability</strong></p> Size of the theme grows linearly</strong> with the project which might still be manageable.</li> The time it takes to create a new theme can see a quadratic increase</strong> though, since for every color themes author has to find, where it's used.</li> When adding new features to the software there are now n!</code> 🙀 possible color transitions. This makes it almost impossible not to break existing themes without increasing reference count even further.</li> </ul> 2. Barrier of Entry</strong></p> This tight coupling also means that the theme authors are required to have full</strong> understanding of the software. Let's look at Ableton LIVE</a> - a fairly complex audio workstation, which has a thriving theming community. Creating themes for it is not trivial. Good luck finding where colors like ViewCheckControlDisabledOff</code> is used in the software within 160 other references. To mitigate the issue people have been creating tools like livethemes</a> with an online GUI theme editor, but that is not ideal either as the tool has to be constantly maintained. Looking at their FAQ</a> the issues become more apparent:</p> Will these themes work in Ableton 11?</strong> Early tests show are they do work in Ableton 11 but are not fully optimized for it. As soon as the final version of Ableton 11 gets released we'll get working on a 'Download for Ableton 11' option.</p> </blockquote> I can't find {insert element here} to customize.</strong> There are lots of elements you can customize within a theme, and unfortunately we haven't been able to map all of them to the preview yet...</p> </blockquote> As we can see, this approach starts to fall apart when number of colors approach triple digits due to the non-linear nature of growth in complexity. The tricky part is that the issues only reveal themselves after the project is already large and refactoring has become a significant effort.</p> Stage Three</a></h2> Referencing by HOW</strong> a color relates to other colors</em></p> This approach introduces an abstraction layer between the software and palette. The colors are named by how they are used in relation to other colors</strong>. Like foreground</code> being used to draw text on background</code> or accent</code> being used sparingly to guide user's attention. The color names ideally do not leak any implementation details from the software itself or exact colors used. The format of the theme only defines a set of requirements like minimum contrast or matching perceived luminance. This approach also makes themes portable and enables them to be used across various applications, which is why this approach is often used UI Frameworks and operating systems.</p> Example</a></h3> As an example let's imagine that we are building a CLI application and that we would like to use the existing 16 ANSI colors for compatibility. While we can't anticipate every color palette it would be very helpful to precisely define what our expectations are using a graph. This can be done in few steps:</p> Rename the main colors to reflect their usage like bright-black</code> → primaryBackground</code></li> normal-red</code> → error</code></li> etc...</li> </ul> </li> Create an undirected graph that describes the contrast requirements I've grouped the colors to reduce the number of connections required</li> The connections describe minimum perceived contrast requirement for drawing text</li> </ul> </li> </ol> </p> With this abstraction in place:</p> Graph can now serve as an interface between creators of the theme and software authors.</li> It enables colors to be applied consistently when adding new features.</li> Themes can now also be validated without explicit knowledge of current as well as future software implementations.</li> </ul> Conclusion</a></h1> In this article I outlined three ways of referencing colors:</p> Approach</th> Description</th> Example</th></tr></thead> By WHAT</strong> color is used</td> naive approach</td> burgundyRed</code>, paleBlue</code></td></tr> By WHERE</strong> a color is used</td> works, but has scalability issues</td> buttonTitle</code>, scrollbar</code></td></tr> By HOW</strong> a colors relate</td> recommended</td> background</code>, accent</code></td></tr> </tbody></table> I discussed how theming progresses from basic copy-pasting to more sophisticated approaches with each stage addressing specific challenges, with the ultimate goal of simplifying theme management and ensuring consistency and scalability across projects.</p> Atreus Keyboard 2024-01-01T00:00:00+00:00 </p> A keyboard with 42 key Atreus</a> layout. Uses Kailh Choc</a> low profile switches with hot-swap sockets. Compatible with ProMicro type controllers, but designed to be used with Nice!Nano</a>. Capable of n-key rollover. There is enough spacing between keys to fit all of the commonly available keycaps - transparent, flat and concave. PCB and case exports available in the github repo</a>!</p> Materials</a></h2> Name</th> Part</th> Size</th> Amount</th></tr></thead> Switch</td> CPG135001D0X</a></td> -</td> 42</td></tr> Socket</td> CPG135001S30</a></td> -</td> 42</td></tr> Diode</td> 1N4148</a></td> SOD123</td> 42</td></tr> Controller</td> nice!nano</a></td> -</td> 1</td></tr> Battery</td> XZK 301230</td> 30x12x3.0mm</td> 1</td></tr> Bolt</td> M2 Hex</td> 4mm</td> 8</td></tr> Machine Headers</td> Mill-Max</td> 13p 3mm</td> 2</td></tr> </tbody></table> PCB</a></h2> </p> ⚠️ No power switch for the battery</li> For every switch has a diode, soldered where an backlight LED would normally be located, providing n-key rollover.</li> </ul> Sockets</a></h2> </p> The PCB has 1.5mm wide holes for mounting the controller socket. This allows soldering machine headers flush with the board. The nice!nano controller originally ships with low profile headers, which won't fit the battery underneath the controller, if soldered in this manner. Therefore a pair of 3mm tall headers had to be separately ordered.</p> Case</a></h2> </p> All 3d printing was done with 0.4mm nozzle at 0.2mm layer height from PETG.</li> The bottom case is attached using eight 4mm long M2 bolts.</li> Added feet using 1mm thick rubber tape</li> </ul> Led</a></h2> </p> In the nice!nano's cover there are two openings for the LEDs. They can be filled with a dab of hot-glue before the print is removed form the bed to get a more diffused look ...for science, you monster.</em></a></p>

I really like Manifold library.

Color Naming

Atreus Keyboard