esri / calcite-colors Goto Github PK

...catching up to work I did with Carl back in January 2020....

Overview:
add a new v-xx-180 row that's deeper/darker
edit v-vv-160 to be more in line with other colors

Details of new color values:
Modified:
v-vv-160 8129ff

New:
v-yy-180 ebba17
v-oy-180 d17300
v-oo-180 c95100
v-ro-180 c93b00
v-rr-180 b3000f
v-pk-180 c00073
v-vr-180 83009e
v-vv-180 6a0be6
v-bb-180 0089de
v-gb-180 00cfca
v-gg-180 00a118
v-yg-180 7fab00

(this is the first issue I've created so LMK if something should be changed)

There is a new colors palette for all of Esri. The new set has matching or close HEX values compared to the old color set.

Working on getting the new colors into Calcite-Web though this issue. They should be updated here first.

CC'ing @kyle-03674 @CassidyB @paulcpederson

Breakout from discussion in #38

Propose renaming "ui-foreground" which has been used for "text" to "ui-surface", keeping "ui-background", and adding "ui-text" color variables.

ui-background: $blk-005
ui-background-dark: $blk-210

ui-surface: $blk-000
ui-surface-hover: $blk-010
ui-surface-pressed: $blk-020

ui-surface-dark: $blk-200
ui-surface-dark-hover: $blk-210
ui-surface-dark-pressed: $blk-220

ui-text-primary: $blk-160
ui-text-secondary:$blk-180
ui-text-tertiary: $blk-200

ui-text-primary-dark: $blk-060
ui-text-secondary-dark:$blk-040
ui-text-tertiary-dark: $blk-020

Open to more prescriptive text titles like "header", "body", "subheader" (but they may not always be used in that order), and changes to above values, but I think this helps clarify the use case for these a bit more.

@bstifle @julio8a @paulcpederson @kyle-03674

This PR Esri/calcite-design-system#6164 in Calcite Components updates instances of "theme" to "mode". Where applicable, we should do the same in this repo, for mixins, and any other named export where the change is valid. cc @geospatialem for prioritization and assignment.

I have a few questions:

1. Are the various color formats individually and manually updated, or is there a master file of colors that generate all of the various formats in this repository?

2. Just guessing; it looks like the Swatch files (.ase) are the tap, which might be manually updated, as they are slightly differently labelled. And it almost looks like the chief tap is the Adobe RGB (aRGB) swatch, which then gets down-sampled to CMYK (for print) and sRGB (for web) in Adobe. And from there, the sRGB swatch is referenced to obtain the hex values used by the Stylus and SCSS versions, which are rastered to CSS. I haven’t figured out how the patterns_json comment documentation is created. Ideally should this all be an automated process?

3. Related to 2, since I don’t see any build process for these files (and I do see a build process for the tag release), could we make it one? We should be able to automate this process from a Swatch file, if that is, in fact, the tap. Would there be any interest in this?

4. Related to 2 and 3, if the tap is the Swatch file, would it be possible to host the Swatch file in this repository?

5. Can anyone verify whether the colors round differently in Adobe products vs Web? For instance, when I inspect Calcite_Blue_250 from Brand_Supportive_sRGB_DEFAULT__10-2015.ase in Photoshop or Illustrator, the HEX value I see is #57a6d9 (or R: 86, G: 165, B: 216), whereas in the CSS and PDF it lists #56a5d8 (or R: 87, G: 166, B: 217).

Note of geekery: technically, we could generate the CYMK and sRGB Swatch files as well as the various CSS-like formats. Except, in my tests, Adobe has slightly different (better) algorithms for converting these colors (I tested of a conversion of R: 195, G: 222, B: 245 to R: 185, G: 224, B: 247 and instead got R: 184, G: 223, B: 246 using this open algorithm).

UPDATE to 5: I have confirmed with Bryan Stifle that each R, G, and B is improperly rounded down from what designers see. AFAICT, if all 3 change for a branding color, and this impacts every branding color; things will always look slightly different from design and branding to the web. I may open a separate issue for this, as it relates to a similar issue I’m experiencing with font sizes (but that would be too much for this ticket).

Add chart color themes from dashboard to calcite-colors to be shared among other projects.

Issue was discussed in calcite-components general teams channel

cc @subgan82.

Generate the SCSS file from the TS file so there is only one source of truth

Related issue:
Esri/calcite-design-system#2042

The following Sass variables need to be updated for theming in calcite-components. Since the light/dark theme mixins use these vars, I'm thinking we want to update them from the variables themselves (ie., update the vars so the Calcite CSS properties in each mixin pull the new values - Cari):

Mockups:

Light changes:
border-1: NO CHANGE
border-2: blk-040
border-3: blk-030

Dark changes:
border-1: blk-160
border-2: blk-170
border-3: blk-180

It'd be nice to have https://esri.github.io/calcite-colors/ show the calcite vars and their respective hex values. Other repos can reference it directly instead of maintaining a local copy.

#949494 is the lightest possible border color to solve for AA on inputs and other components

https://esri.github.io/calcite-colors/

Might have to do with the recent breaking changes.

@driskull, can you take a look?

Shouldn't the color be #73004c instead of #73004?
Reference:

Decided to make a formal issue for discussion on this issue. I'm seeing Calcite Gray 200 as noticeably and distractingly a pinkish hue. Examining this shows that the HSL value for #feeefe is (300, 3%, 94%). This is squarely in the pink hue, and saturated enough to be noticeable at this lightness.

@CassidyB @kyle-03674 posit this is correct. I would like to submit that this is problematic. Below, I've assembled a table that shows the variables in the grayscale and their HSL values. This is done for comparison of hue. You can see that the hue wanders all over the map. Most of the grays are a cool, bluish hue with the occasional hiccup. Several of the grays have 0 saturation at all, meaning they are true neutral grays.

I suggest unifying the hues of the grayscale to either neutral or cool tones. At the very least, fixing the pinkish gray should be a high priority. If this gray is intentionally pink, I am curios about the reasoning behind that decision.

add calcite-brand-x as a color variable for branding and theming.

A question on process for this repo re: cc04bae

Looks like @CassidyB made a direct push to master fixing bugs. Do we have a formalized process for contributing to this project like fork and pull? While I'm happy Cassidy fixed bugs, the push to master caused merge conflicts with my pull request.

I suggest formalizing in a README.md what model of contribution we want to use.

@julio8a @kyle-03674 @macandcheese

proposing that we change the hex value of ui-blue-hover-dark

from #59D6FF to #67C7FF due to the slight green hue in the prior.

Awesome repo - add a license! :)

[ ] Change name of colors (blue, red, yellow, green) to UI states (success, warning, etc)
[ ] add brand color var
[ ] update dark theme foreground colors

Light:

Dark:

Could we add one of the vibrant blues?
#69dcff

Thanks a millipede!

@paulcpederson @julio8a

Having discovered that calcite colors do not match between Adobe Swatches and actual CSS, it should be decided which colors are the true colors, and any files related to the matter should be updated (swatches, photoshop guides, css files).

This issue may be resolved by or possibly resolve #21.

@kyle-03674 shared a pdf that may also need to be updated.

https://www.npmjs.com/search?q=calcite