Themes 1.0

[sebald]

Description

We need to refactor our themes!

Requirements

• Support single and multiple variants of components
• Support components that consist of more than one part (see https://developer.mozilla.org/en-US/docs/Web/CSS/::part)
• Support base styles for components without repeating
• Support state (because we can not use things like :disabled)
• Support sizes in a common way (currently only available to button)

Tasks

• [x] Add theme (variant) debugging #1684
• [x] "Translator" that helps theme-ui select stuff from the theme #1972
• [x] Parse states to pesudo-classes #1979

Theme Spec

const theme = {
  ...tokens,
  root: {},
  components: {
    Button: {
      base: {
        // styles that are applied every time
      },
      size: {
        small: {},
        medium: {},
        large: {},
      },
      variant: {
        primary: {},
        secondary: {},
      },
    },
    Checkbox: {
      base: {
        // Component consists of multiple parts
        container: {},
        icon: {},
        label: {},
      },
      size: {
        small: {
          container: {},
          icon: {},
          label: {},
        },
        medium: {
          container: {},
          icon: {},
          label: {},
        },
        large: {
          container: {},
          icon: {},
          label: {},
        },
      }
    },
  },
};

Context

Our themes became very large and hard to maintain, we need more structure!

Consequences

More to write, but maintainable 🥳

[sebald]

@ti10le we should gather "semantic colors" (error, info, warning, ...) and other value we want to support in createTheme. Do you want to make a list?

[ti10le]

@ti10le we should gather "semantic colors" (error, info, warning, ...) and other value we want to support in createTheme. Do you want to make a list?

Yes I can! But what other values do you mean? Do you mean some values we already have (space, sizes) or more values like from open-props: gradient, animation or s.e.?

[sebald]

@ti10le fonts for example, not sure if there are any others. but the colors are the most important ones, i guess.

[ti10le]

to extend createTheme():

colors: {
    text: ...,
    background: ...,
    primary: ...,
    secondary: ...,
    disabled: ...,
    error: ...,
    warning: ...,
    info: ...,
    success: ...,
    white: // ? like in docs theme,
    black: // ? like in docs theme,
}
fonts: {
    body: ...,
    heading: ...,
}

for the future maybe something like this:

// brand colors
    primaryLight: '$blue200', //  $blue600 on dark mode
    primary: '$blue500',
    primaryDark: '$blue600',
    primaryShadow: '$blue100', // $blue600 on dark mode

    secondaryLight: '$purple200', // $purple600 on dark mode
    secondary: '$purple500',
    secondaryDark: '$purple600',
    secondaryShadow: '$purple100', // $purple600 on dark mode

(https://nextui.org/docs/theme/default-theme)

[sebald]

@ti10le white, black can not be a single value, see @marigold/tokens. Needs hues. When is background used?

[sebald]

Change Proposal: Use regular CSS as much as possible, because recomputing the styles programmatically is expensive and could make apps slow.

• no state in component styles but rather use pseudos :hover, :focus, ...
• should change from error to invalid maybe, since input:invalid is a real selector and differentiate from
• use either utility classes (like MUI) or data attributes (like chakra-ui) for styling state
• pseudo selectors have to be transpiled e.g. :hover -> &:hover, &.mg-hover or &:hover, &[data-hover] (since we do not want to write or own theme-ui, we have to do this inside the <Box> before passing it to emotion)

[ti10le]

@ti10le white, black can not be a single value, see @marigold/tokens. Needs hues. When is background used?

I think background could be useful inside components eg dialog. But sure we could also remove it.

[sebald]

Closing. Will do createTheme updates past 1.0. See #2002