Feature Request

Add layer style to styled system objects similarly to how the textstyle is implemented. <styled.div layerStyle='container'></styled.div>

Be able to extend recipes. This is an excellent feature. I used it on tailwind variants. It's a handy property. https://www.tailwind-variants.org/docs/composing-components

A dev server that provides auto-documentation of your tokens, allowing you to preview and test your design tokens in real-time

The ability to define and apply keyframes in a more localized manner, instead of using the config file globally. This feature aims to enhance the developer experience by allowing for more modular and encapsulated animation definitions within individual components. The current approach of defining animations globally can lead to clutter and challenges in maintaining a clean codebase, especially in larger projects. By enabling localized keyframe definitions, developers can create more maintainable, cleaner codebases. This approach aligns with the principles of separation of concerns and component-based architecture, leading to improved code readability and ease of maintenance. I've noticed that CSS modules, Emotion, Linaria, and Vanilla-Extract each provide their approaches to solving this issue. Similarly, I believe PandaCSS could benefit from adopting a similar strategy or, if I may suggest, the following interface could be a valuable addition: ```javascript const className = css({ animation: { keyframe: { "0%": {...}, "100%": {...} }, duration: "1s", ... } })} ```

JSR is a new package manager built for TS projects that delivers an exceedingly better DX than NPM. However, because Panda does not allow a ts output option, users who are building libraries cannot ship to JSR. Likewise, Panda could and should also use JSR which would provide a better DX to all of us users. You can ship both to NPM and JSR easily. https://jsr.io/

Best practice or documentation on how migrate chakra-ui to panda-css (and maybe ark) ?

The atomic class output of Panda is nice for performance reasons, but I often feel it makes it harder for me to experiment with styling in Chrome DevTools. An alternative output mode could give developers the option to generate "regular" CSS classes instead of atomic CSS.

Motivation 1: we want our design team to be able to push styling changes at a component attribute level directly from Figma to our UI library, without developer intervention. Motivation 2: we want to white-label our UI library for various clients. Current limitations: we can define semantic tokens for each component attribute: e.g. _button.color.border.primary . This token would link to a "real" semantic token like color.interactive.border or similar. In both of the scenarios above, the primary button border might need to point at a different semantic token at some point, either when switching to a different brand or in a future redesign. Defining tokens in this way is fine until we roll out the same concept to all the UI library components. We may end up with many thousand semantic tokens, each of which is included in the production runtime and static CSS. The many-to-one relationship results in a lot of duplication. We would like to be able to define component tokens so that they can be resolved to the linked semantic tokens at build time so that they are not included in the shipped code. For more detail please see the Discord discussion: https://discord.com/channels/1118988919804010566/1202629680273031230 Workaround: for now we have worked with our design team to implement real semantic tokens wherever possible and only use "component" tokens in highly unique components, and live with a little more developer intervention where we need to subdivide semantic tokens for better control.

The good thing about generating the patterns is you get a React component directly. The problem though, it's not SEO friendly, sometime you need your Container to be a section or a main tag but it's not possible. by supporting asChild we can do so without using the pattern function

There is a very strong case to have component level tokens, the biggest reason we have found is it allows you to build more robust components when it comes to theming. With this feature we could have a bit more looser with base and semantic level tokens while the component level tokens are much stricter. There are a couple use cases but I find the most compelling is if your semantics slightly change from theme to theme. For example, using the component Alert from Chakra-UI. The original design calls for background color to tie back to their semantic versions, success = green, critical/error = red, info = blue, and warning = yellow. In another world or another brand, the design decisions may call for the background colors all to be the same. In the current implementation of Panda that would require us to add complexity to the recipe or styling to know which theme is loaded which then in turn decreases the flexibility and increases the maintenance time any time a new theme or brand is introduced. Ideally what this looks like today is in plain CSS: /* base.css */ :root { --color-bg-success: #c6f6d5; --color-bg-neutral: #e2e8f0; --Alert-color-bg-success: var(--colors-bg-success); } /* Brand-2.css */ :root { --Alert-color-bg-success: var(--color-bg-neutral); } /* no matter the brand, Alert doesn't care */ .Alert { background-color: var(--Alert-color-bg-success); } ## Today's solution The only way I can think of achieving this type of approach with Panda today is the following, however, I will not this feels a bit anti-pattern to Panda's recommendations today: const theme = { tokens: { colors: { green: { 200: { value: "#9AE6B4" }, }, gray: { 200: { value: "#E2E8F0" }, }, }, }, semanticTokens: { colors: { bg: { success: { value: { base: "{colors.green.200}", }, }, neutral: { value: { base: "{colors.gray.200}", }, }, }, Alert: { success: { bg: { base: "{colors.bg.success}", }, }, }, }, }, themes: { brand2: { semanticTokens: { colors: { Alert: { success: { bg: { base: "{colors.bg.neutral}", }, }, }, }, }, }, }, }; const alert = defineRecipe({ variants: { state: { success: { backgroundColor: "{colors.Alert.bg.success}", }, }, }, }); ## A proposed solution I'm honestly not sure what the correct API might look like but based on established conventions, something might look like the following syntax const theme = { tokens: { colors: { green: { 200: { value: "#9AE6B4" }, }, gray: { 200: { value: "#E2E8F0" }, }, }, }, semanticTokens: { colors: { bg: { success: { value: { base: "{colors.green.200}", }, }, neutral: { value: { base: "{colors.gray.200}", }, }, }, }, }, componentTokens: { Alert: { colors: { success: { bg: { base: "{colors.bg.success}", }, }, }, }, }, themes: { brand2: { componentTokens: { Alert: { colors: { success: { bg: { base: "{colors.bg.neutral}", }, }, }, }, }, }, }, }; const alert = defineRecipe({ variants: { state: { success: { backgroundColor: "{colors.Alert.bg.success}", }, }, }, });