Accept a "className" key in the styles attributes

[jgoux]

Is your feature request related to a problem? Please describe.

I'd love to be able to integrate tailwind ui with stitches. Stitches would be used to compose my variants and obtain a typed component's API. And tailwind as the underlying styling system using its classes utilities.
Currently there is no way to pass raw classNames inside styled().

Describe the solution you'd like

I'd like stitches to accept a "className" key inside the styles properties, like this : https://codesandbox.io/s/naughty-hopper-cy8zh?file=/src/App.tsx

Describe alternatives you've considered

I'm currently trying https://github.com/tw-in-js/twind-react but the TypeScript story isn't as good as with stitches, so I'd prefer stick with stitches. Also this addition would benefit not only for tailwind users but for any utility or css library.

[dylanklohr]

Because I think this group is one that values respectful disagreements 😬 😅

I do not think that supporting custom className in its style object is something that @stitches/core or @stitches/react should be responsible for providing. I'm actually very much opposed to introducing it.

In the case of either library, providing a custom class or className, respectively, is doable at the consumption level

<button class={`tw-class ${button({})}`}

or

<Button className="tw-class" {/* other props */} />

When building something like a design system, wanting to allow consumers to pass through a className is something that is frequently not desired, and even guarded against. In the case of @stitches/react, the css prop that's available on a styled component is capable of accepting the exact same (or nearly the exact same) api as the styled function, meaning that even if a custom Button component (like the one in my example above) does not expose a className prop, there would now be two places that authors have to guard against specifying a custom className, the component itself and the css prop.

As it's already possible to support custom class / className instances via the current api, I don't really think it's the responsibility of the @stitches/core or @stitches/react to expose that additional layer of complexity.

If anything, maybe a macro or something in the future to support it, but I would be very much opposed to offering that behavior by default 😅. I feel like this might also better reflect what I've seen from the TW community as well, meaning many of the custom integration options with TW have been done via a build, compilation, or transpilation step rather than the direct interfacing api, though I could be wrong about that one 😬

[jgoux]

To add more context after we discussed on Discord, this is only something I'd want within the styled function. For me the biggest strength of stitches is its very terse syntax when defining primitives within a design system while being fully typed. So I want this part but also want to benefit from tailwind ecosystem and directly applying classNames to style my variants would be the best of both worlds.

[loicnestler]

I'd love such a feature as well! Currently struggling on how to properly implement a flexible design system based on tailwindcss.
If stitches would provide such feature in their styled function, that'd be a total game-changer!

Or alternatively: what about @stitches/tailwind? Is there any way on how to integrate it into @stitches/react?
I'm currently playing around with both libraries in a codesandbox, however I can't find to make it work.

Maybe @tailwindcss/jit might be a nice starting point for that?

[jonathantneal]

I would be in favor of this functionality, but not necessarily as a property like className for two reasons. And I don’t yet have an answer as to what it should look like.

My first issue with a className property is that it is too broad and would not guide authors to proper usage. See @dylanklohr’s excellent comment, where late offsets could be slipped in at the early composition stage. While this can still be done other ways, say, by wrapping components, at least the added class names would appear in more expected places.

My second issue with a property like className would be that it would not behave like any other property (save for variants). We had a very similar issue in CSS Modules, where one would extend classes using the composes declaration. Unfortunately, when extending multiple classes, or extending classes across multiple rules, you ended up writing multiple composes declarations, defying the cascade (the C in CSS). Here is an example of what that CSS would look like:

.styles-for-a {}
.styles-for-b {}
.styles-for-c {}

.styles-extending-a-and-b {
  composes: styles-for-a;
  composes: styles-for-b; /* intuitively, one should expect this to cancel out the prior declaration, not extend it. */
}

.styles-extending-a-b-and-c {
  composes: styles-extending-a-and-b; /* intuitively, one should expect this to cancel out other declaration, not extend it. */
  composes: styles-for-c; /* and again, one should expect this to cancel out the prior declaration, not extend it. */
}

Hopefully, the comments in that code reveal how confusing a property without overrides ends up being. We resolved to change composes to @composes in CSS Modules, but that change has not yet been made.

I would be hesitant to introduce the @composes at-rule to Stitches because of the syntactical experience. It’s already a little frustrating when camelCased CSS properties live alongside selectors and at-rules that must be wrapped in quotes, but at least it’s obvious to JS authors why they must be wrapped. I’m not against this, necessarily, but hesitant, because Stitches, the native CSSOM, and many other libraries avoid using quotes (which is the reason we all support camelCased CSS properties).

[vaynevayne]

userSystem project import taildcss
tailwindcss.config.js

design system use tailwindcss ，
className =text-red-500

this maybe not work ？