Naming convention of color shades in the Drupal Design System (e.g. for Claro)

To clarify the original intent was to only change the naming convention for lighter darker shades of gray, not the entire system. Several of the design systems I referenced on #3154539 still use named color variables for the majority of their colors, but use decimal system for their shades of gray. I don't see why it makes sense to change the scope of this to affect the entire system, instead of scoping this to just the neutral color palette. The rule is if two colors have the same Hue but a lighter or darker shade/tone (aka, Lightness and Saturation in the HSL colorspace) then it makes sense to name the variables with a simple color name combined with a decimal gradation.

I suppose besides the grays there are (currently) two other colors where the rule above applies in the Design System.

Reds and blues.

So you were correct to change the scope. My apologies.

The rule is if two colors have the same Hue but a lighter or darker shade/tone (aka, Lightness and Saturation in the HSL colorspace) then it makes sense to name the variables with a simple color name combined with a decimal gradation.

FWIW, I agree with doing this for greys and I guess looking at #4, maybe also blues. What would be the benefit of doing it for colors that only have 2 shades as opposed to using names for those like "light" and "dark"?

What would be the benefit of doing it for colors that only have 2 shades as opposed to using names for those like "light" and "dark"?

I guess you're talking about the red there, and I totally agree that there is no benefit to a duodecimal suffix, and could in fact be argued that it would be harmful (for reasons outlined in my next paragraph). However, it is also worth pointing out that a -light and -dark suffix would be way better than trying to give the two shades different proper names. The light and dark suffix serve to provide context that there are other tones that can be used. But I should also point out that in Comment #4 above I didn't screenshot the original red color in the design system. So to clarify, there are actually 3 shades of red, not 2.

This line of thinking brings up the deeper question: what happens when the design needs to be expanded from 2 shades to 3? to 5? to 7? AFAIK, there is no hard & fast rule to convert to a duodecimal system after say 4 tones, but its more just about what feels natural. If you're dealing with a color named --color-blue-300 in the CSS code, it provides contextual information before diving into the color system that there *are* more colors to work with.

Copying point 3 from #3154539-8: Implement new Gray scale on Claro here for more context and the research that was done. I proposed a duodecimal system there for the grayscale and also switching to HSL colors, which would make it more clear that all the colors in a tone group have the same hue.

--color-gray-100
--color-gray-200
--color-gray-300
--color-gray-400
--color-gray-500
--color-gray-600
--color-gray-700
--color-gray-800
--color-gray-900
--color-text

You put the 100 level scale there to allow for future expansion if it were ever needed. This would vastly improve themers experience, maybe designers too.

Of the 11 design systems I checked, 8 of them standardize around a decimal system for their neutral color variables.

• https://material.io/design/color/the-color-system.html#color-usage-and-p...
• https://developer.microsoft.com/en-us/fluentui#/styles/web/colors/neutrals
• https://atlassian.design/guidelines/brand/color
• https://style.helpscout.com/visual-elements/#color
• https://www.carbondesignsystem.com/guidelines/color/overview/#themes
• https://ux.mailchimp.com/patterns/color
• https://getbootstrap.com/docs/4.0/getting-started/theming/#grays
• https://www.lightningdesignsystem.com/design-tokens/#category-color

The 3 design systems that I looked at that broke from this trend were:

• https://brand.uber.com/guide#color-specialty-colors
• https://polaris.shopify.com/design/colors
• https://v1.designsystem.digital.gov/components/colors/

It is clear that the reason these outliers do not use a decimal system is because they don't have a complete grayscale, but only offer a few select neutral tones. Because we're adding several more grays here, it makes sense to switch to a duodecimal system.

what happens when the design needs to be expanded from 2 shades to 3? to 5? to 7?

Looks like Bootstrap has "gray" as an alias for "gray-600" and has "gray-dark" as an alias for "gray-800". Would it feel natural for Drupal's design colors to evolve in a similar way? Such as:

• For colors that begin with 1 shade, just use the color name.
• If at some point a darker shade than the original one gets added, name it "$color-dark".
• If at some point a lighter shade than the original one gets added, name it "$color-light".
• If at some point more shades than the above get added, then move to a decimal system, but retain $color, "$color-light", and "$color-dark", and alias them to the decimal that preserves backwards compatibility.

I like that direction. However, given that red has only two lighter tones and no darker tones, it might make sense to move to decimals later. I'm not entirely sure. What if the transition to decimal factors on more than two additional shades in either direction (lighter/darker) from the original color?

Such as:

• For colors that begin with 1 shade, just use the color name.
• If at some point a dark shade than the original one gets added, name it "$color-dark".
• If at some point a light shade than the original one gets added, name it "$color-light".
• If at some point a darker shade than the dark one gets added, name it "$color-darker".
• If at some point a lighter shade than the light one gets added, name it "$color-lighter".
• If at some point more than 2 shades lighter or darker than the original get added, then move to a decimal system, but retain $color, "$color-light", "$color-lighter", "$color-dark", and "$color-darker", and alias them to the decimal that preserves backwards compatibility.

Some initial analysis comparing the current hex codes, converting them to HSL colorspace, and mapping them to decimals, reveals that the conversion to decimal is not an exact science when there are "holes" between shades.

I ended up basically using my eye to make judgement calls on where to leave space between missing colors for the blues that are currently defined, to leave space for more mid-tones, if they were needed.

The other thing that this process turns up is that there would eventually get to a point where you start adding in swatches and tones, and have inconsistency with the legacy color-light and color-lighter. For example, if the reds were expanded at a future date, you would end up with red, red-light and red-lighter with different levels of white mixture between red and blue.

Then there is the problem of creating -light but then the second color tone you add is actually between original and -light! so you'd break BC to move -light to the new color and -lighter to what -light was originally.

Not sure where this leads us, if anywhere, really. But the problems here suggest an easier path would be to work out the color tones in a numeric gradation scale for all primary and secondary colors beforehand, like several design systems linked above do. Not sure we should do that or not, because it might be bloat and overload. But even if we don't go that far, it may make sense to align all the colors in HSL space and use similar luminosity (brightness) and saturation (flatness) percentages across all hues (if that makes any sense).

Forgot to upload the neutrals, to complete the thought 👆.

Also, here is the code for quick copy/paste.

             gray-100  #F3F4F9  hsl(230, 33%, 96%) White Smoke (new)
             gray-200  #DEDFE4  hsl(230, 10%, 88%) Light Diamond (new, prefix bg)
             gray-300  #D3D4D9  hsl(230,  7%, 84%) Light Gray
             gray-400  #C1C2C7  hsl(230,  5%, 77%) Seashell
             gray-500  #ADAEB3  hsl(230,  4%, 69%) Gravity  (new)
             gray-600  #919297  hsl(230,  3%, 58%) Gray-Blue  (input border color)
             gray-700  #828388  hsl(230,  2%, 52%) Old Silver
             gray-800  #75767B  hsl(230,  3%, 47%) Moiety  (disabled (4.5:1))
             gray-900  #55565B  hsl(230,  3%, 35%) Davy's Gray (additional text)
             text      #232429  hsl(230,  8%, 15%) Text (primary text)

             blue-100  #F0F5FD  hsl(217, 76%, 97%) (BG BLUE HOVER)
blue-lighter blue-200  #E6ECF8  hsl(220, 56%, 94%) (BG BLUE ACTIVE)
blue-light   blue-300  #B3C9F5  hsl(220, 77%, 83%) (focus)
             blue-400
             blue-500
blue         blue-600  #003CC5  hsl(222, 100%, 39%) Absolute Zero
blue-dark    blue-700  #0036B1  hsl(222, 100%, 35%) (hover) 110% Absolute Zero
blue-darker  blue-800  #00339A  hsl(220, 100%, 30%) (active) 120% Absolute Zero

             blue-900

red-lighter   red-100  #FDF5F5  hsl(0, 67%, 98%)  (BG RED HOVER)
red-light     red-200  #FCEDED  hsl(0, 71%, 96%)  (BG RED ACTIVE)
              red-300
              red-400
red           red-500  #d72222  hsl(0, 73%, 49%)
              red-600
              red-700
              red-800
              red-900

            green-100
            green-200
            green-300
            green-400
green       green-500  #26A769  hsl(151, 63%, 40%)
            green-600
            green-700
            green-800
            green-900

Thanks @jwilson3! We've discussed this proposal for a while and we've gone back and forward on this for a while. Basically the problem is that the current Gray scale is not based on a 10% variation from color to color and we couldn't name gray-100 and gray-756, just say grey-700 when it's really 73%. So we either changed the color or we got stuck with a non-percentage naming.

So I'm proposing to change the Gray colors (again, I know sorry!) and try to find a proper color scale for Blue too, and use the naming you're suggesting because it'll make the code easier to use and more scalable. Also, we'll have to come up with a more complete blue scale since we've already seen the need to a more complex scale than the one we already have (like in [#3171729).

So here's what I propose: on the left, the old scale. On the right, the new one:

Obviously this means we'll have to do proper accessibility review to most of the components to be sure we're not introducing any regression.

Any thoughts before we move forward with the blue scale?

Nice work taking this forward @ckrina and core Claro team. In addition to aligning the colors to a 10% +/- gradation (smart!), and the a11y regression testing (very smart!), I will be interested to see how designers end up aligning some of the more drastic color swatch changes.

The ones that stands out the most are Moiety and Light Diamond, which I could envision they'll have to play with a bit manually. For instance, since Light Diamond is kind of in between 100 and 200 in terms of lightness, I can see sending some instances to --gray-100 and others to --gray-200.

Thank you for pulling the trigger on this!

I've just created an issue for the Blue scale that needs some thoughts: any idea welcome. #3251709: Define Blue scale for Claro

What would you think about coming up with a color scale for each secondary color as it has been done in https://designsystem.digital.gov/design-tokens/color/system-tokens/? (Credits to @ana-barcelona that referenced me this, and also referenced by @jwilson3 in a previous comment)

Also, FYI the work for the dark mode/dark regions is going to happen in #3251278: [META] Designs for dark background layers and its color palette, where we should discuss if the color scales should be the same or not.

Just following up here that the point about 10% mapping directly to the Luminosity percentage in the HSL colorspace being directly connected to the 100-point scale, might not be required. I would consider the exact percentage less important than a relationship between the two adjacent colors in the scale. For practical purposes, 100 is lighter than 200, but not necessarily exactly the same lightness difference between 200 and 300.

It might be worthwhile considering help from a tool like https://accessiblepalette.com/ to create consistent luminosity across all base colors in the palette.

Here is a super-quick proof of concept:

https://accessiblepalette.com/?lightness=98.2,93.9,85,76.2,67.4,57.8,48,...

I expect this would require additional manual review and tweaking to take into consideration WCAG against dark mode.