feat: adds colors for current states

[asangma]

Used in these places:

[macandcheese]

Colors look good - maybe "active" vs. "current" since the nomenclature we use on components for active state is "active"? Thanks for adding in.

[macandcheese]

Would this be "brand" themeable?

[paulcpederson]

@bstifle this is the color we should use for the date range selected, yeah? Seems like a very similar thing.

[paulcpederson]

[bstifle]

@asangma

Can we explore getting these to align to colors we are using on Calcite Components? Would also be nice to mirror blue foreground on dark theme, instead of using a darker shade of gray.

For selected icons, we aren't using blue anywhere, but go from

6a6a6a to #151515 on light

9f9f9f to #ffffff on dark

Would like to align our hover states as well.

Would prefer using m-bb-10 instead of h-bb-10 for the current blue (#DFEFFA). Which would be dope on range as well. @paulcpederson

m-bb-090 for dark theme (#214155)

ui-foreground-current": "#c7eaff"
"ui-text-current": "#00619b",

"ui-foreground-current-dark": "#151515",
"ui-text-current-dark": "#59d6ff",

to

ui-foreground-current": "#DFEFFA"
"ui-text-current": "#151515",

"ui-foreground-current-dark": "#214155", 
"ui-text-current-dark": "#ffffff",

just a suggestion for alignment. if not, can we please at least align our blues? e.g. #007AC2 (light theme primary ui-blue) and #00A0FF (dark theme primary ui-blue)

edit: note, we keep the icons gray/white for most things because when fidgeting with background colors it usually starts to fail via contrast AA

[macandcheese]

I like the keeping the icons from turning blue in the above comps - way nicer and stands out quite a bit more, nice @bstifle . Could we change from "current" to "active" to mirror what's happening with component prop / css "active" ?

[bstifle]

oh yeah active sounds a little more hip than current. Alan did you name it that because of aria current?

[asangma]

I originally had "active" but isn't :active a pseudo normally applied to something like pressed.

[asangma]

@bstifle The blue being used is one of our blues.

I'm not sure that the colors you've chosen is an improvement. 😬 Have a look at what we have in production for a better visual reference.

[macandcheese]

I originally had "active" but isn't :active a pseudo normally applied to something like pressed.

Yeah, but "active" as a prop is probably more common for "the thing that's active" - I don't think it's a huge deal one way or the other but current isn't used anywhere else, at least active has the prop.

Regarding color, I'll let you two decide - but not using a dark blue for the icon in Bryan's comps is nice, (IMHO) the two-tone blue for active state isn't super strong. (I think that could happen with either color choice for blue?)

[bstifle]

@asangma Just pushing for consistency. At the minimum, using a shade of gray for dark-active foreground is odd when the light-active foreground is blue. We are needing to use the "faint" blues for Date Range so was hoping to slay 2 birds. (suggest m-bb-090 #214155)

if you think h-bb-10 is better, aight. Just feels a little too candyish.

Also, where are you getting your dark theme primary blue? #59d6ff? since you're using ui-blue-3 on light theme for active icon, why not use ui-blue-3-dark for dark theme active icon?

[bstifle]

@asangma sumpin like dis

[macandcheese]

Between those two... the white icon in light theme / dark icon in dark theme look so much better, less washed out against a blue bg, and especially in the dark one, easier to see. IMO

[asangma]

Tell me again what the issue is with what we currently have?

I think with dark theme, a "current" bg should be darker. Otherwise, it looks like muddy town.

Note: we should use "active". That's already a pseudo for when a link/button is being "pressed".

[bstifle]

Tell me again what the issue is with what we currently have?

I think with dark theme, a "current" bg should be darker. Otherwise, it looks like muddy town.

Note: we should use "active". That's already a pseudo for when a link/button is being "pressed".

@asangma

Problems:

1. Active states aren't following the same visual story:
   • Light theme: blue active background + blue active icon
   • Dark theme: dark gray active background + blue active icon ! Suggest mirroring what light theme does, and utilizing a blue background, recommend m-bb-090 #214155. And then calling that "active/current" for dark theme

2. Dark theme blue is using a strange blue for indicators.. #61d7fd ! Suggest using calcite dark theme blue: ui-blue-1-dark #00A0FF

3. Aligning current or active blue. ! I'm ok with using h-bb-010 which is already whats being used. I'll move stuff over to that

[bstifle]

@asangma worth noting that we aren't going to darker grays than foreground for active/hover/press states for anything on dark theme. Makes it nice when mirroring light theme, less disparities

[asangma]

Understood. re: darker bg. That make sense for any of those pseudo states.

This however is a "current" state.

[bstifle]

This however is a "current" state.

i know....

which is why i'm trying to mirror it to your light theme current state

https://github.com/Esri/calcite-colors/pull/60#issuecomment-715636179

[asangma]

@bstifle Y U KEEP KALIN IT ACTIVE THO 😆

[bstifle]

Tomato, Potato.

[asangma]

Precisely.

[bstifle]

after talking with @asangma

this was the compromise to align for current states:

basically just making the dark theme icon ui-blue-3-dark

[macandcheese]

It's weird one theme uses blue and one doesn't, that's a strange visual story.

[macandcheese]

This seems like a less incongruous story, swapping those used blues for whatever other values:

Why in light theme would it go base -> blue, and in dark theme base -> darker grey?

[julio8a]

I agree, the last post suggestion seems like a more cohesive visual story. I can see this scaling and be applied to more items for light/dark themes moving forward.

What's the reason for having two different active states for light vs dark them? We've been pretty consistent with the light/dark themes when it comes to states.

[asangma]

If we look at Radio, RadioGroup, RadioButton, Tabs, Stepper, etc., we already have a variance in the visual story of current states.

That being said, if you want a consistent story for the proposed update, light and dark themes both do this:

• lower the color value for background (darker)
• increase the saturation of the icon

I think zeroing in on the color blue is not necessary.

Note: retaining the dark gray for the icon in the light theme would diverge from the rest of the platform. It's something that could change, but I wonder if it's worth it.

Note 2: Please be clear about the difference between active and current. We should use "active" to refer to what some are calling "pressed". The reason being the CSS :active selector. ref

[bstifle]

something to consider:

if we were trying to be the most consistent, we would do this for current

[macandcheese]

Note 2: Please be clear about the difference between active and current. We should use "active" to refer to what some are calling "pressed". The reason being the CSS :active selector. ref

I don't think this potential conflation causes issues... We use active as a prop to affect state / style in many components - accordion-item, stepper-item, dropdown-item, tab-nav, etc. in addition to being used to display components like alert, notice, modal. Active seems to be a more commonly used and familiar nomenclature for this across our components.

Additionally, current seems to indicate a single "currently active" selection of something - whereas active can be used in some cases to denote multiple active items and associated styling, like dropdown-items, etc.

[julio8a]

If we look at Radio, RadioGroup, RadioButton, Tabs, Stepper, etc., we already have a variance in the visual story of current states.

I'm not sure what you mean about this. Light and dark follow the same visual story:

Radio-button

Radio-group

Tabs

They use blue for dark theme to match light theme. They don't use a dark gray, which is the original proposal.

same for other components you mentioned.

None of the blue values in the dark theme go dark gray, which seems like the proposal above.

Maybe I misunderstood the point you were trying to get across?

@bstifle, I agree, your last suggestion is the most consistent with the system.

[bstifle]

let's get a meeting going

[macandcheese]

I like the option Bryan posted

Very obvious as to the active item and matches all other active state colors / indicators.

[asangma]

@macandcheese I def tried that out. It looks pretty nice in that isolated view. In a full interface, it's maybe not great. But indeed, let's discuss in a digital television conference phone call meeting.

[bstifle]

this is another option to fit in that same story

[paulcpederson]

It's subtle, but I do like what @bstifle just posted. Consistent with tabs, etc. Allows background color to be used for hover, press, etc.

[macandcheese]

It's subtle, but I do like what @bstifle just posted. Consistent with tabs, etc. Allows background color to be used for hover, press, etc.

Agree, and I think it's a pretty common design pattern across the 'net as well. Consistent as well with Tabs, Stepper, etc., as Paul mentioned. We would need to provide "indicator-position:start/end" for positioning left / right (or top / bottom on horizontal).