Should we create a new top-level classes with namespaces for Honeycrisp Compact?

[ash-rc]

Copied over from #230

From @hartsick, referencing an issue created by overriding the button class in Honeycrisp Compact causing it to lose its focus state:

"I wonder if this is worth rethinking how we are declaring the honeycrisp-compact styles, since I think accidental overrides through specificity might continue to be a problem we run into.

@bengolder and I talked today and I wonder if we should be creating new top-level classes with namespaces (eg .hc-button and .hc-button--small) rather than namespacing classes (.honeycrisp-compact .button, .honeycrisp-compact .button--small). Would like to give some more thought; also invite thoughts from others!

This would allow us to more interchangeably use compact and non-compact styles if we wanted, too."

[hartsick]

I'm not sure where to put this, but I wanted a place to share where teams have been writing their Honeycrisp compact styles in case it's useful to reference:

GYR
CMR / CGLA (as form-card--dense)

Might also be helpful to look at the HTML of different projects to see how .honeycrisp-compact shows up in the markup

[hartsick]

Notes from 2/26/2021 eng camp conversation:

Some things that were thought about when setting up:

• Most styles are not that different than regular Honeycrisp. So, a goal: to lean on existing Honeycrisp styles rather than reimplementing.
• Question mark whether was going to be more convenient for developers? (eg having compact in classes everywhere). Assumed that you'd be using all compact styles or all non-compact styles
• Defaulting to Honeycrisp seemed useful

Discussion:

• By higher-level namespacing the compact styles deviate from our other patterns: BEM notation, component-based scoping of CSS
• Proper specificity becomes difficult, but also nice that we can just be a theme. If intended for expert use tooling, would make sense that it's all or nothing that you pull into certain parts of your application
• Compact isn't just "compactness": also different colors, different look. Is this a different design system, instead? May make it more clear if we consider it as a separate thing.
• Goal is to prevent cascading issues and unintended consequences, which are caused by overrides. Has caused some bugs before.
• Do we need a better definition of what each component is supposed to be and for expected uses? We're not using classes consistently.
• Current GYR painpoint: doing a lot of custom overrides. Not sure if it's Honeycrisp compact or GYR, since not sure what Honeycrisp compact is.
• Need commitment from design org to have shared design system make sense—include Rachel in future discussions.
• GetCalFresh is using Honeycrisp most out-of-the-box. Have track of work to use compact on full screen and admin page.
• What is Honeycrisp? Is it to create consistency within apps, or to create consistent style across CfA? Get alignment with designers. How closely should Honeycrisp provide us everything we need, or building blocks you intend to customize. Answer: Intent is to use as much as possible across teams.