
Preface
Written 03.05.25
Last week, during an AI meetup with the "Ethereum Localism" group that I have been invited to join (thanks @owocki), I presented a seemingly novel concept called "A Color Standardization Staking Mechanism." This mouthful of a topic is a subject that I have been focused on for years, outlining "Open Source Color Advancement," or as a new colleague rephrased it, "Recoloring The Web." Thanks, Jon.Bo ↗
The point of what I presented outlines the severe lack of color standards being issued, adopted, and used across the web. I explored and outlined why "new" models and alternative approaches to color lead to a wider selection of web safe colors, better color practices, standards, and overall interactions with Designers, for viewers and web users. How these wider color spectrums operate within deeper values (for both the color picker and the color user), explores and unpacks massive areas of growth and opportunities that come to light by issuing more advanced color models, color standardization, and as I've come to learn— Color-As-A Service.
Choosing Color, Today
Color, just like many elements of Design and Web Development, is hyper-relative. Hyper-local. How color presents itself to everyone, is different. We all see, feel, and perceive color relative to us. Planning for this, as a Color Theorist, is a seemingly enormous task. This form of identity (within color) represents itself across many kinds of application— for Local* Agency, we* focus on how color is represented by Brands, Products, Campaigns, and the visual systems that uphold deliberate and lasting impact into things like adoption, usability, accessibility, and ultimately—sales.
The color spaces and spectrums that are available in modern digital tools like Adobe and Figma, for example, vary greatly. Understanding how to choose color for the web versus picking color for print operates, takes skill and a keen eye to discern and express the technical difference between things like CMYK for print—a subtractive sysem(subtracting light), and digital color (commonly sRGB or HEX colors) which is and additive system (adding light from the monitor).
Today, modern Brand Designers are typically tasked with creating color palettes within Brand Identity Systems, that can speak across a multitude of outputs. Choosing color palettes in todays modern color market is a seemingly simple task—today there are color picker tools and palettes a'plenty. The reality is choosing color (and desinging things like Color Systems) takes a massive amount of skill; both from an anthropological study and a study of how colors with shift, shape, and grow over time.
Color presents a unique set of problems and end outputs; whereas an logo or wordmark with an ientity system is a fixed entity in space—color must speak at the same rate across trends, individuals, groups, cultures, and demographics; a tool that can easily be mis-represented if taken for granted. Choosing colors for cross-platform and cross-application use presents another set of challenges; how do Designers ensure that the digital colors they are creating with systemize, correctly, across platforms?
The color spaces and spectrums that are available in modern digital tools like Adobe and Figma, for example, vary greatly. Understanding how to choose color for the web versus picking color for print operates, takes skill and a keen eye to discern and express the technical difference between things like CMYK for print—a subtractive system (subtracting light), and digital color (commonly sRGB or HEX colors) which is and additive system (adding light from the monitor—more akin to oil paint, re: why the Mona Lisa is so luminous, for example). Overall, color is no small subject. And while there are free tools and color palette generators available online, understanding when, where, how and why to apply color systems takes year of practice, application testing, feedback, and management. As technology advances away from print production, for example— Designers understand less and less about how to use color picking outside of prescribed color spaces.
Prescribed Color Spaces
Prescribed color spaces include sRGB (Adobe), and Hex Codes (Figma). Both sRGB and Hex Codes provide users with 256 color options, and 216 web safe options. Within this spectrum of 200+ colors lies deeper challenges and limitations like ensuring AAA compliance is met, how colors change (color contrast) when presented on different backgrounds (a black background versus a white background), or when including A11y Compliance for color blind users.
September of 2000, David Lehn and Hadley Stern discovered that only 22 of the 216 colors in the web-safe palette are reliably displayed without inconsistent remapping on 16-bit computer displays. This ain't exactly a lot of colors to choose from, in fact, it's quite staggering how few colors this is, which leads to our first question — why are we using sRGB and Hex Codes to define color standards? Why are we working with such a limited, pre-scribed, color space?
Challenge 01: Color Value
Working within sRGB and/or Hex Codes color systems presents a big problem. Aside from a limited color set; Designers practice color picking by applying opacities when shifting between color values. This means that color picking is done so by decreasing the lightness and darkness, or the "weight" of colors based on how opaque or transparent each color is. This, as a practice, does not scale. Meaning, for developers working in code this creates a breakdown when a background color is not consistent across apps, pages, and sections because transparency is relative to the background it is placed on. Check out Josef Albers, The Interaction of Color, for reference. This problem is exacerbated as digital color picking does not scale, as a system, into print; opacities simply do not print within standard CMYK printing techniques.
Here, the question becomes, "do we blame Designers for using these tools? Or do we blame the tool for providing opacity as an option?"
Reliant Outcomes - Value Where Value is Met
After working alongside clients for the last 15 years— color outcomes rely on Designers, our tools, and how we interface with clients. If tools are providing simple answers like changing color value based on opacity, blame the tool. If Designers are ill-informed and ill-practiced within Color Spaces, blame the Designer.
Designers (and how they work with tools) present areas of growth and challenge, equally. Design is as much a practice of imagination and creativity as it is standardization and best-practices. Asking questions and challenging norms, familiarizing themselves with trimming fat and challenging perceptions is what differentiates good Designers from great. In this case, standardization of color is a two-way street.
Perceptually Uniform Colors
Color schemes that designed so that equal steps in data values are perceived as equal steps in color, create perceptually uniform colors. In human speak, this means that the perceived change in color is consistent across the entire range of the colormap. This encourages accurate data visualization, as non-uniform colormaps can lead to misinterpretations of data. When a user slides their color picker across the hue and saturation, perceptually uniform color ensure that the color mapping is congruent with the data and its respective value.
The challenge with HSL, is that in order to create a dynamic and consistent color set (for Branding, for ex); HSL is not perceptually uniform. Colors that are not perceptually uniform becomes a bigger crux than perceived and can lead to Hue and Saturation choices that do not appear to be on the same level of light vs dark (value). To better understand what this means in real-time, check out this hsl to hsla color picker, here.
Color value is a far superior system versus color transparency. HSL or Hue, Saturation, and Light are now options within tools like Figma and Webflow, two common web building tools that presents an opportunity to move away from relying on transparencies. Thankfully, tools and organizations like A11y Compliance are working to create better native tools to increase color contrast standards across the web with plugins for Figma like A11y's Color Contrast Checker or in Webflow— a triple AAA rating for color standardization. Here, color value is presented as a way forward, versus a hurdle. Training Designers to become more familiar with a wider color spaces, spectrums, gamuts, and overall models presents an opportunity to grow and expand Color-As-A-Service.
Challenge 02: Color Models & Displays
Web 1, 2, and 3 architectures only provide Designers and Developers with 35% of the total color spectrum available. That's nuts. This means that our website are washed out because CSS and Color Models only represent 1/3 of the total color available. This also means that the current color models being used do not properly represent how humans perceive and see color. It's as though this limitation is presenting a rather limited lens to see through.
Google Chrome's advocate Adam Argyle has laid out updates to a High Definition CSS Color Guide, outlining the severe lack of advancement into other and better color models. Adam shows where color users live, with 49% of the web using #rrggbb, 25% using #rgb, 14% using rgba(), 8% using transparent, 2% using namedColor, and 1% using rgb(). This leaves the best color spectrums (CIELAB, HSL, HSLA) using a whopping 0% of use. How can this be?
The breakdown begins when pairing Color Models with CSS and their displays. CSS is not high-definition ready (the code itself is not ready to accept the advancement of Color Models). New tools like Perceptual Lightness using CSS Color 4 (LCH) have been introduced to Google Chrome, Safari, and Firefox, thereby increasing color availability by 50%. Even still, 400 colors is not a huge increase when 16 million are available.
To put this all into perspective, standard computer monitor hardware has advanced exponentially faster than CSS specs and browser implementation. CIELAB, a fantastic alternative to rsgb or Hex color codes, for example, is a system that was developed in 1976 (to put timing in to context) and is still not widely used by any percentage of Designers and Developers. When opportunities to use 16 million colors are available, the lack of value in these models, gamuts, and corresponding uses of code has quickly moved away from only being a metaphor for adoption and growth and into a much larger conversation about color advancement and color standardization. This leaves massive room for growth for advancements into web-based (browser) re-application and re-rendering of color. The tooling, API's, plugins, and licensed products yet to be made within color models and displays holds room for multi-billion dollar markets; advancing not only how color models and displays are built into the infrastructure of modern web apps, but the value of the delivery mechanisms, themselves.
Below, I will explore and expand these areas of growth, introducing Color-As-A-Service and a revenue model that expands into 12+ streams.
Challenge 03: Color Standardization - Current Mass Adoption
Before we dive into the solution, let's unpack 3 common color models and why these standard models are unfit for Color Standardization:
- sRGB (Standard Red Green Blue) is not perceptually uniform as it is a device-specific color space. While it was designed to match the characteristics of CRT monitors, it doesn't accurately represent how humans perceive color differences, meaning colors that appear equally different to the eye may not be equally spaced in the sRGB color spaces. This is wild because sRGB is used by a whopping 35% of all web users.
- HSL(A) (Hue, Saturation, Light, Alpha) is a useful color mode, but it is not perceptually uniform. Human vision is not linear when it comes to color perception. Equal changes in HSL values don't always translate to equal perceived changes in color. When working with non-perceptually uniform color spaces, it can be difficult to create color schemes that are visually harmonious or that accurately represent the intended relationships between colors.
- Hex Codes (Hexadecimal Color Codes) are useful when creating web applications, however #hex codes are not inherently perceptually uniform. A standard in web dev, Hex codes offer conversions that HSL(A), and sRGB—but this lack of perceptual uniformity can lead to issues when creating color palettes, especially for data visualization, where users want the perceived differences in color to accurately reflect the underlying data.
Let's look at 3 alternative color spectrums that capture inherent Perceptual Uniformity:
- CIELAB Color Space: The perceived differences between colors correspond to their numerical differences within the space. In simpler terms, equal distances between colors in CIELAB should look like equal changes in color to the human eye.
- HSLuv (CEILUV): a human-friendly version of HSL, CIELUV becomes functionally similar to the HSL color space, with the problem that its chroma component doesn't fit into a specific range.
- LCH: These systems allow users to evaluate color attributes, identify inconsistencies, and accurately express their findings to others in numerical terms.
Finally, let's get to the root of the problem:
- What's available (tools)
- How much knowledge we have (education)
- Why aren't CIELAB, HSLuv, or LCH color spaces standardized?
Solution: Color-As-A-Service
Where Local* sees growth is not in the standardization of one tool or color space, rather, quests to eradicate poor color spaces, entirely. Identifying color differences between a sample and the standard encourages users (Designers and Developers) to familiarize themselves with outdated color systems, incentivizing standardization through rewards.
ChromaQuest™ introduces Color-As-A-Service, under these 3 Solutions:
- A Staking-Based Mechanism that incentivizes participation in color validation.
- Open-Source Integrations with leading design platforms (Figma, Webflow, OpenSea).
- A Community-Driven Model that evolves through Creator participation and governance.
Color-As-A-Service offers a locally run and maintained infrastructure delivery model where applications (hosted by the ChromaQuest™ provider) are made available to customers via a web app plugins.
The web is stuck using outdated color standards that don’t reflect the diversity of creative expression. The ChromaQuest™ Staking Mechanism transforms color validation into a dynamic, community-driven process—where users stake tokens on precise color values, refining color standards through engagement, and by earning rewards for contributions. By blending open-source collaboration with incentives, ChromaQuest™ is not just setting new color standards—we’re building a color economy, or Color-As-A-Service. This system benefits Artists, Designers, Brands, and Developers by ensuring accuracy, accessibility, and innovation in cross-platform digital color integration, standardization, and use.
The growth of Color-As-A-Service is vast. Holding magnitudes, ChromaQuest™ is the first step in issuing Color Standardization; Local* is working on a suite of new products that issue similar thinking, application, standardization, and use. Our structure keeps ChromaQuest™ broad enough to scale while making Huebit the first tangible, gamified tool.
Check out the ChromaQuest pitch
To learn more, hit our Local* Principal, neil@local*, up!
Introducing Color-As-A-Service
Color-As-A-Service offers a locally run and maintained infrastructure delivery model where applications (hosted by the ChromaQuest™ provider) are made available to customers via a web app plugins.