The access to "style props" are way too restricted

[mwskwong]

I get the idea of the component library trying to encapsulate the low-level API as much as possible, but I believe it should also leave room for the user to do "low-level stuff" (not to mention it's not THAT low-level).

Currently, I notice two issues when trying out the library.

1. Some CSS attributes are straight up not available as a prop, even though they are design tokens and make perfect sense to be props, e.g. shadow, border.
2. Some props, though available, are only accessible in a selected few components, e.g. display.

The two combined make things quite inconvenient if I wish to stick to the "Radix Theme" way of making use of design tokens.

Example use case: create a Header component that contains a hamburger button that only shows up in xs breakpoint or below.

1. To add a shadow/border in the Header, a very common design, there is no native way of specifying shadow or border, and I have to resort to using Tailwind class, CSS Module, or other non-Radix ways to achieve that. The ideal case would be the components to have a shadow = "1" | "2" | "3" | "4" prop for example.
2. To make the hamburger button show/hide in certain breakpoints, the easiest way of doing things is to set the display value. Yet, the display prop is only available in layout components, but not IconButton. So yet again, such common design needs the help of 3rd party tools to achieve. Or I have to add a <Box asChild> wrapper, which doesn't make too much sense to me in this case.

Benchmarks

• MUI has implemented sx prop for all components, to allow applying one-off styles. It works similar to the native style prop but allows the user to specify attributes like mt to make use the design token.
• Mantine did something similar, but instead of creating a new prop, they override the style prop
• Chakra UI also has an sx prop, but common style props, like display, m, etc. are available to all components.

[vladmoroz]

It sounds like you are asking for Radix Themes to come with a styling solution. Unlike MUI or Chakra, Radix Themes doesn’t come with any opinionated styling solution itself. You can use whatever styling tech that works for you.

Because of that, there’s no ”non-Radix” way to use the CSS tokens that we provide. Any way to use the CSS tokens that Radix Themes provides is legit. Let’s take your example:

• To add a shadow/border in the Header, a very common design, there is no native way of specifying shadow or border, and I have to resort to using Tailwind class, CSS Module, or other non-Radix ways to achieve that. The ideal case would be the components to have a shadow = "1" | "2" | "3" | "4" prop for example.

Nothing wrong with using Tailwind, CSS Modules, CSS-in-JS, or a straight style prop to set a token like var(--shadow-1) or var(--red-9). That’s exactly the point. When building custom components in a codebase that uses Radix Themes, we prefer vanilla CSS because it’s good enough, but you don’t have to.

• Some CSS attributes are straight up not available as a prop, even though they are design tokens and make perfect sense to be props, e.g. shadow, border.

• If you meant overriding styles on components like buttons, badges, inputs, etc:
  • These have a design to them that visually works well with other components in a certain way. We spend a lot of time on harmonizing the design of the variants together, and changing just one piece of a design will likely call for related changes elsewhere.
• If you meant building custom designs on top of something like Box or Flex:
  • Simple designs can be done with an inline style prop anyway.
  • Complex, interactive designs incur investing in an opinionated styling solution which we are not interested in. If you are building custom components, just do it with any tech you like, but end-to-end with the CSS tokens provided by Radix Themes and/or Radix Primitives as the base.

2. To make the hamburger button show/hide in certain breakpoints, the easiest way of doing things is to set the display value. Yet, the display prop is only available in layout components, but not IconButton. So yet again, such common design needs the help of 3rd party tools to achieve. Or I have to add a <Box asChild> wrapper, which doesn't make too much sense to me in this case.

Yep, that’s by design, you probably want something like this:

<Flex display={{ md: 'none' }}>
  <IconButton>
    <HamburgerMenuIcon />
  </IconButton>
</Flex>

Using only layout components for layout is a bit more verbose, but off-loading layout responsibilities to them makes the UI code easier to read and to maintain in the long run. If this approach is not what you expected and/or is new to you, I’d suggest just to trust it and go along with it for a bit—it “clicks” with most people at some point. I can’t recommend it enough over having a soup of props that control both presentation, functionality, and layout on your buttons, badges, inputs, and so on.

Aside from margin props on each component, we don’t plan to introduce other layout props on non-layout components.

Also, don’t <Box asChild> onto buttons because you might break the display style of the button itself, which is usually inline-flex for centering the children.

[lhguerra]

When building custom components in a codebase that uses Radix Themes, we prefer vanilla CSS because it’s good enough, but you don’t have to.

But how about responsiveness? For instance Box doesn't have a prop for box-shadow, where can I use the breakpoints if not there?

[jonschmidt]

@vladmoroz I was lead to your answer while doing a bit of research on how we can use radix themes, but also while building a component library to accompany it.

When building custom components in a codebase that uses Radix Themes, we prefer vanilla CSS because it’s good enough, but you don’t have to.

This is my feeling as well. We tried tailwind for a while, but realized that getting it to work in harmony with themes + some other styles we were importing was proving more problematic than it was worth. We are now using CSS modules + radix themes.

If you are up for it, just wanted to ask if there are any rules / guidelines you and your team follow around when to use radix themes vs when to use vanilla css? Do you always use radix themes when possible, and only use CSS when themes does not provide what you need (e.g., always use a <Flex> and never display: flex, or does it depend on where the code is being written?

I am about to onboard some new engineers to my solo project and would love to have some guidelines in place for this stuff!