Should the design system include a CSS reset?

[zarahzachz]

Currently, the design system does not include any kind of CSS reset and leaves that responsibility up to product teams. This Discussion is meant to dive into the topic of CSS resets to see if we need to shift gears at all.

• Should the design system ship a CSS reset as part of the system?
• How prescriptive of a reset does the design system need?

Should the design system ship a CSS reset as part of the system?

Pros

There are a few issues that arise when asking that teams provide their own reset (BYOCSSR, or "Bring Your Own Cascading Style Sheets Reset").

1. By not controlling what reset a team is using, there is a risk that the design system UI may differ from product to product
2. By not building UI from a reset, the design system may introduce style bugs that are difficult to reproduce/fix
3. With BYOCSSR, there's a lot of redundant code, which kind of flies in the face of the purpose of this design system

Cons

There are obviously a lot of reasons to include some kind of reset in a design system, but the biggest reason to not include one is the incredible amount of work required to get all products onboard, and to coordinate that effort to happen at the same time.

Other issues that can arise:

1. We don't know what resets product teams have chosen, so for the design system to choose one and expect that to be a one-size-fits-all solution could present some UI issues
   a. This is a moot point if everyone chose identical resets or same kind of reset (e.g., opinionated vs. unopinionated resets)
2. Teams have been building their applications with their chosen reset as the foundation for their styles
   a. Sometimes resets can have custom application styles tacked onto them - if this has happened it'll be hard for a team to switch over
   b. Sometimes teams declare their base font size (I've seen teams use a base font of 10px to make responsive sizing calculations easier, others maintain the browser default of 16px) and if the design system provides a reset that sets the sizing - it can blow up an entire applications UI 💣

How prescriptive of a reset does the design system need?

If we work through these concerns and decide to move forward, how prescriptive of a reset does the design system need?

Opinionated vs. unopinionated resets

Opinionated resets fix the user-agent style differences between browsers and provide sensible defaults instead. Normalize is a good example of an opinionated reset.

Unopinionated resets strip all styles from all elements, creating a blank canvas to build your UI from. Eric Meyer's CSS Reset used this approach (I think it's outdated now), and you can see this strategy used in The New CSS Reset.

And between these two ideologies, you also have the options to go with something familiar or roll your own reset.

Browser support and implementation

With the design system dropping support for IE, I'm fairly certain whatever reset chosen only needs to be compatible with modern browsers (Chrome/Edge, Firefox, Safari), but I don't know if that's the case for product teams consuming the design system.

So far, I've been discussing this reset in terms of "all in" vs. "all out," but a middle ground might be to have a formal reset recommendation on our docs site saying "We only guarantee support for X" and include guides for how teams can use something like the @layers API (if needed) to load their styles correctly.